Persistenza Silenziosa: Scheduled Task/Job: Cron (T1053.003)

Durante un penetration test, l'implementazione di persistenza tramite cron richiede attenzione ai dettagli per evitare detection immediata. Il primo passo consiste nell'identificare la configurazione corrente del sistema target.

Verifica innanzitutto le restrizioni di accesso con cat /etc/cron.allow e cat /etc/cron.deny. Se nessuno dei due file esiste, solo l'utente root può schedulare job, altrimenti gli utenti listati in cron.allow hanno i permessi necessari.

Per installare un job persistente su Linux, utilizza: echo "/5 * * * * /tmp/.hidden/backdoor.sh >/dev/null 2>&1" | crontab -*

Questa entry esegue lo script ogni 5 minuti redirigendo l'output per evitare log verbosi. APT5 ha dimostrato l'efficacia di modifiche dirette ai file in /var/cron/tabs/, bypassando il comando crontab standard che potrebbe essere monitorato.

Su sistemi ESXi, la tecnica richiede editing diretto del file: echo "@reboot /bin/sh /tmp/.persist.sh" >> /var/spool/cron/crontabs/root

Il malware GoldMax ha utilizzato proprio la direttiva @reboot per garantire esecuzione ad ogni riavvio del sistema. Per verificare l'installazione corretta, controlla i log di cron in /var/log/cron o la posizione definita in /etc/rsyslog.conf.

Durante Operation MidnightEclipse, gli attaccanti hanno dimostrato una variante sofisticata: job che scaricavano payload da infrastrutture C2 solo in determinati orari per evitare detection basata su analisi del traffico di rete.

La detection efficace di abusi cron richiede un approccio multilivello che consideri sia le modifiche ai file di configurazione che l'esecuzione anomala di processi schedulati.

Implementa monitoring su auditd per catturare syscall relative a modifiche crontab. La regola base dovrebbe triggare su: -w /var/spool/cron/ -p wa -k cron_changes

Questo cattura scritture e modifiche di attributi nella directory cron. Kinsing è noto per installare job che eseguono script ogni minuto, un pattern facilmente identificabile analizzando la frequenza di esecuzione.

Per macOS, l'analisi dei unified log risulta cruciale. Cerca pattern di crontab utility eseguita da shell interattive, specialmente se seguite da esecuzione di binari nascosti o rinominati. Il malware Janicab utilizzava proprio questa tecnica per mantenere persistenza su dispositivi Mac.

Su sistemi ESXi, monitora modifiche dirette a /var/spool/cron/crontabs/root e /etc/rc.local.d/local.sh. La detection DET0290 suggerisce di flaggare job con sintassi wildcard eccessiva o intervalli di esecuzione troppo frequenti.

Un indicatore chiave è l'esecuzione di binari da path non standard schedulati via cron. Rocke installava job che scaricavano ed eseguivano file dal C2, pattern rilevabile correlando eventi di rete con nuove entry crontab.

Per ridurre falsi positivi, mantieni una baseline di job legittimi per sistema e alerta solo su deviazioni significative, considerando contesto utente e frequenza di esecuzione.

L'analisi forense di attività cron malevole richiede la ricostruzione precisa della sequenza di eventi dalla compromissione iniziale alla persistenza stabilita.

Inizia esaminando /var/log/cron o la posizione definita in syslog config. Questi log mostrano quando i job sono stati eseguiti ma non sempre quando sono stati creati. Per questo, analizza i timestamp di modifica dei file crontab con *stat /var/spool/cron/crontabs/**.

APT38 ha dimostrato l'uso di job pre-schedulati che si attivavano solo in determinati momenti. Cerca pattern di esecuzione che coincidono con altri indicatori di compromissione nella timeline. Il malware Exaramel for Linux installa cron job solo quando non ha privilegi root, quindi correla la presenza di job utente con tentativi falliti di privilege escalation.

Su sistemi compromessi da Xbash, noterai che il malware verifica prima il sistema operativo tramite uname prima di creare cronjob. Cerca questi check preliminari nei log di sistema o nella memoria del processo.

Per ESXi, esamina modifiche a /var/spool/cron/crontabs/root correlando con log vmkernel per identificare processi anomali lanciati post-modifica. SpeakUp utilizzava cron per garantire che il processo principale rimanesse attivo, pattern visibile analizzando processi figli ricorrenti.

Documenta ogni modifica crontab trovata, includendo timestamp, contenuto del job, e correlazione con altri artefatti forensi per costruire una timeline completa dell'intrusione.

L'analisi dei gruppi APT che utilizzano cron rivela pattern operativi distintivi utili per attribuzione e previsione di future campagne.

APT38, affiliato nordcoreano, implementa job cron per mantenere accesso a sistemi finanziari Linux. Il gruppo schedula task in background che si attivano durante orari lavorativi locali per mimetizzarsi con attività legittime. La loro preferenza per job periodici piuttosto che @reboot suggerisce focus su persistenza a lungo termine.

APT5, attore cinese, modifica direttamente i file in /var/cron/tabs/ invece di usare il comando crontab. Questa tecnica bypassa alcuni meccanismi di logging, indicando sofisticazione operativa e conoscenza approfondita dei sistemi target.

Rocke, gruppo cryptomining, installa job che scaricano payload da C2 ogni pochi minuti. Il pattern ad alta frequenza riflette il loro modello di business: massimizzare tempo di mining prima della detection. I loro job includono sempre meccanismi di auto-aggiornamento del malware.

L'overlap nei tool mostra che NETWIRE, Anchor e Penquin condividono codice per installazione cron, suggerendo possibili marketplace underground dove questi moduli vengono scambiati. Operation MidnightEclipse ha dimostrato l'evoluzione tattica: job che recuperano payload solo in specifiche finestre temporali per evadere sandbox analysis.

Il trend emergente mostra spostamento verso job con logica condizionale embedded, eseguendo azioni diverse basate su fattori ambientali come presenza di specifici processi o connettività di rete.

Framework MITRE ATT&CK documenta questa tecnica come T1053.003. Operation MidnightEclipse (C0048) dimostra uso recente in campagne sofisticate. Risorse detection includono DET0290 per monitoring cross-platform e configurazioni auditd specifiche per Linux.