Persistenza via Cron: Scheduled Task/Job — Cron (T1053.003)
La tecnica T1053.003 descrive l'abuso del demone cron, lo scheduler temporale nativo dei sistemi Unix-like, per ottenere esecuzione ricorrente o differita di codice ostile. Un avversario che scriva una voce in un file crontab può innescare payload al reboot, a intervalli regolari o in orari studiati per evadere le finestre di monitoraggio, coprendo simultaneamente tre tattiche MITRE ATT&CK.
Sul piano tattico la tecnica tocca TA0002 (Execution) perché consente di lanciare binari o script arbitrari, TA0003 (Persistence) perché sopravvive a riavvii e chiusure di sessione, e TA0004 (Privilege Escalation) quando il job gira in contesto root o eredita permessi da SUID mal configurati. Nella kill chain si colloca tipicamente subito dopo l'Initial Access, come primo appiglio stabile sull'endpoint compromesso.
I dati MITRE censiscono 3 gruppi APT che vi ricorrono attivamente (fra cui APT38 e APT5), 12 famiglie malware con implementazione nativa di persistenza cron (da NETWIRE a Kinsing, da GoldMax a NKAbuse) e la campagna Operation MidnightEclipse del 2024, che ha sfruttato CVE-2024-3400 su PAN-OS. La superficie si estende oggi anche agli hypervisor ESXi, dove i crontab risiedono in /var/spool/cron/crontabs/root e sono diventati vettore prediletto per persistenza pre-ransomware.
In un ingaggio red team la persistenza cron è spesso il primo tassello dopo aver ottenuto una shell su un host Linux o macOS. La procedura operativa più semplice sfrutta direttamente l'utility crontab dell'utente compromesso, evitando di toccare file di sistema che generano più rumore.
Un payload minimale a livello utente si installa con (crontab -l 2>/dev/null; echo " * * * * /tmp/.beacon.sh") | crontab -*, che accoda una entry senza sovrascrivere quelle esistenti. Per persistenza al boot in stile GoldMax si usa la sintassi estesa GNU/Vixie cron: @reboot /usr/local/bin/updater --daemon. Se si dispone di root, la scrittura diretta in /etc/cron.d/ con un file dal nome mimetico (es. sysstat-collector) risulta meno visibile di una modifica al crontab dell'utente, perché quei file sono normalmente popolati da package manager.
Su ESXi il flusso cambia: la shell è BusyBox e crontab non è persistente al riavvio dell'hypervisor se non si modifica sia /var/spool/cron/crontabs/root sia /etc/rc.local.d/local.sh, dato che ESXi rigenera i crontab dal filesystem read-only. La tecnica documentata nei ransomware ESXi è: echo "/5 * * * * /store/payload" >> /var/spool/cron/crontabs/root && /bin/kill $(cat /var/run/crond.pid) && crond*, seguita da un'aggiunta in local.sh per sopravvivere al reboot.
Su macOS cron è deprecato in favore di launchd ma resta funzionante; l'invocazione di crontab -e da un utente interattivo produce un file in /var/at/tabs/<username> ed è la strada scelta da Janicab.
Per emulare l'attività di gruppi come APT38 o Rocke in ambiente controllato conviene affidarsi a framework di adversary emulation. Atomic Red Team (open source) include il test T1053.003 con payload pronti; Caldera (open source) di MITRE consente di orchestrare la catena completa incluso il download secondario del secondo stadio, replicando il pattern di Kinsing che scarica shell script ogni minuto dal C2. Sliver (open source) e Mythic (open source) offrono moduli di persistence dedicati.
Per verificare la stealth della propria entry si può usare pspy (open source), che monitora l'esecuzione dei processi senza necessità di root e rivela immediatamente ogni job cron che parte, dando al red team la stessa visibilità che avrebbe un difensore attento. Chiudete sempre la fase di cleanup rimuovendo l'entry con crontab -r o editando i file di sistema toccati, e loggate l'operazione nel report.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo
2 minuti · 7 domande
Che professionista cyber sei?
Scopri il profilo più vicino al tuo modo di pensare e inizia dal percorso giusto.