Riconoscere i cron job nascosti come backdoor

In breve: un cron job nascosto è una delle backdoor più frequenti sui server Linux: scarica regolarmente codice dannoso o riavvia processi, anche dopo un aggiornamento di PHP. Verifichi tutti i luoghi delle attività pianificate, non solo crontab -l: crontab di tutti gli utenti, /etc/crontab, /etc/cron.d, le cartelle cron, i timer systemd e i job at. Conservi i ritrovamenti prima di rimuoverli.

Perché i cron job sono così amati come backdoor

Dopo un'intrusione riuscita un aggressore ha un problema: il suo accesso è fragile. Un aggiornamento chiude la vulnerabilità, un amministratore cancella la webshell, un riavvio termina il processo. Un cron job risolve questo problema. Avvia comandi a orari fissi, senza che nessuno intervenga, e ripristina così gli accessi perduti.

Per PHP2Shell non esistono Indicators of Compromise confermati. I nuovi cron job rientrano però, secondo i rapporti di cui disponiamo, tra i segnali d'allarme generali dopo intrusioni tramite applicazioni web. Chi ha già cercato webshell dovrebbe verificare subito anche le attività pianificate. Gli altri passi di una fase successiva li elenca la checklist dopo un attacco.

Dove possono nascondersi le attività pianificate

Linux conosce più meccanismi per le attività pianificate. Molte verifiche falliscono perché se ne guarda uno solo.

Importante per i server web: l'utente del server web di norma può creare la propria crontab senza diritti di root. Un aggressore con i diritti di www-data non ha quindi bisogno di un'altra vulnerabilità. Voci in /etc/cron.d o unit systemd indicano invece che ha ottenuto diritti di root.

I pannelli di hosting come Plesk o cPanel offrono un'interfaccia propria per le attività pianificate. Dietro di essa ci sono di norma anch'esse le crontab dei rispettivi utenti di sistema. Chi guarda solo nell'interfaccia non riconosce quindi ogni voce creata direttamente sul server. Nel dubbio verifichi entrambe.

Come verificare tutti i luoghi per intero

I comandi seguenti leggono soltanto. Li esegua come root e conservi gli output con la data.

# Mostrare le crontab di tutti gli utenti
for u in $(cut -d: -f1 /etc/passwd); do
  out=$(crontab -l -u "$u" 2>/dev/null) && printf '### %s\n%s\n' "$u" "$out"
done

# Voci di sistema e date di modifica
cat /etc/crontab
ls -la --time-style=full-iso /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

# Timer systemd e job at
systemctl list-timers --all
atq 2>/dev/null

# Cercare modelli tipici in tutti i file cron
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null

Due trucchi meritano particolare attenzione. Alcune voci nascondono i comandi dietro molti spazi, così che nell'editor escano dallo schermo a destra. Altre usano caratteri di controllo che durante la visualizzazione sovrascrivono il testo. Con cat -A tali caratteri diventano visibili:

cat -A /var/spool/cron/crontabs/www-data 2>/dev/null | less

Un secondo punto di vista sono i log del servizio cron. Su molti sistemi cron annota ogni esecuzione con utente e comando. Così vede anche voci che un aggressore nel frattempo ha rimosso e riconosce da quando giri un comando sospetto:

# Comandi cron eseguiti dall'utente del server web (Debian/Ubuntu o journal di systemd)
grep -h "CRON" /var/log/syslog* 2>/dev/null | grep -E "\((www-data|apache|nginx)\) CMD"
journalctl -u cron -u crond --since "2026-10-17" --no-pager 2>/dev/null | grep CMD | head -100

Da cosa riconosce una backdoor in un cron job

1. Download da Internet: un download il cui risultato viene passato direttamente a una shell.
2. Contenuti codificati: lunghe stringhe che vengono decodificate solo in fase di esecuzione.
3. Percorsi insoliti: programmi in /tmp, /dev/shm, cartelle nascoste o directory di upload.
4. Utente sbagliato: attività sotto l'utente del server web, anche se l'applicazione non ne richiede.
5. Cadenza anomala: esecuzione ogni minuto o a ogni riavvio tramite @reboot.
6. Marcature temporali incongruenti: file modificato in un periodo in cui nessuno lavorava sul server, ad esempio dopo il 17 ottobre.

Da non dimenticare: anche le applicazioni hanno pianificazioni proprie. WordPress, ad esempio, gestisce le attività pianificate nel database. Come verificare lì lo descrive Trovare backdoor in WordPress.

Conservare il ritrovamento, capirlo, poi rimuoverlo

Un cron job dannoso è una prova preziosa. Mostra l'indirizzo di download, il momento della sua creazione e spesso l'utente attraverso il quale l'aggressore è entrato. Conservi il file con somma di controllo e marcature temporali prima di rimuoverlo. La marcatura temporale aiuta in seguito a ricostruire lo svolgimento; come si fa lo mostra Creare la cronologia di un incidente. Anche per un'eventuale notifica all'autorità di controllo per la protezione dei dati o per l'assicuratore il ritrovamento è una prova importante di da quando un aggressore avesse accesso.

Rimuovere non basta. Se gira ancora un processo che riscrive la voce, dopo il minuto successivo è di nuovo lì. E finché la vulnerabilità originaria è aperta, l'aggressore può ripartire in qualsiasi momento. L'ordine è quindi: conservare, chiudere la causa, rimuovere tutti i componenti, cambiare gli accessi, monitorare.

Mettere in sicurezza i cron job in via preventiva

Perché una backdoor in un cron job non possa nemmeno nascere o salti subito all'occhio, aiutano tre misure. Primo, si può stabilire quali utenti possano creare una crontab. Se esiste il file /etc/cron.allow, solo gli utenti ivi indicati possono usare crontab. Se la Sua applicazione non richiede un cron job sotto l'utente del server web, questo utente non va nell'elenco. Verifichi prima quali attività l'applicazione richieda davvero e le crei consapevolmente sotto un utente proprio.

Secondo, vale la pena monitorare i file. Uno strumento di controllo dell'integrità segnala non appena un file cambia nelle directory cron o sotto /var/spool/cron. Terzo, le attività pianificate appartengono alla documentazione del server: chi sa quali voci debbano esserci riconosce subito una estranea.

Come aiuta concretamente PHP SOS?

• Verificare per intero: esaminiamo tutti i meccanismi per le attività pianificate, anche timer systemd, job at e pianificazioni delle applicazioni.
• Inquadrare i ritrovamenti: analizziamo le voci sospette senza eseguirle e ne ricaviamo altre tracce.
• Bonificare in modo pulito: con la rimozione del malware rimuoviamo tutti i componenti e chiudiamo la causa.
• Riconoscere il ritorno: configuriamo un monitoraggio che segnala attività pianificate nuove o modificate.

Domande frequenti

Fonti

• BSI: Ufficio federale tedesco per la sicurezza informatica
• BSI IT-Grundschutz
• OWASP Cheat Sheet Series