Task Pianificati: Scheduled Task/Job (T1053)

In un red team engagement la pianificazione dei task è uno degli strumenti più affidabili per garantirsi persistenza silenziosa. Su Windows il vettore classico resta schtasks.exe, che accetta creazione locale e remota tramite il flag /S:

schtasks /Create /TN "UpdateCheck" /TR "powershell.exe -w hidden -enc " /SC HOURLY /RU SYSTEM /F

L'opzione /RU SYSTEM richiede privilegi elevati e produce un task che gira nel contesto più privilegiato disponibile. Un'alternativa meno rumorosa passa per l'API COM ITaskService, invocabile da PowerShell tramite New-ScheduledTask e Register-ScheduledTask, che non genera invocazioni a schtasks.exe e riduce la telemetria da linea di comando. Per operazioni completamente in-memory, framework come Impacket (open source) offrono atexec.py per creare task remoti via RPC senza toccare il disco del target.

Su Linux il vettore preferito è crontab -e per l'utente corrente oppure la scrittura diretta in /etc/cron.d/, /etc/cron.hourly/ o /var/spool/cron/crontabs/. Un'entry come @reboot /tmp/.cache/beacon garantisce riavvio automatico del payload. I systemd timer rappresentano un'alternativa più moderna e spesso meno monitorata: si crea una coppia .service + .timer in /etc/systemd/system/ e si attiva con systemctl enable --now backdoor.timer.

Su macOS si scrive un file plist in /Library/LaunchDaemons/ (persistenza a livello di sistema) o ~/Library/LaunchAgents/ (a livello utente), poi si carica con launchctl load. La chiave RunAtLoad combinata con StartInterval replica il comportamento di un job ricorrente.

Su ESXi la persistenza sfrutta /etc/rc.local.d/local.sh oppure entry cron in /var/spool/cron/crontabs/root; è una tecnica documentata in intrusioni ransomware contro infrastrutture di virtualizzazione.

Per la fase di ricognizione dei privilegi, il modulo PowerUp incluso in PowerSploit (open source) contiene la funzione Get-ScheduledTaskComment e controlli su permessi deboli su task esistenti, utili per identificare vettori di privilege escalation quando un task privilegiato punta a un binario scrivibile dall'utente corrente. Analogamente winPEAS e linPEAS (open source) enumerano task e cron job vulnerabili in fase di post-exploitation.

In ambienti containerizzati un attaccante può abusare di sleep loop in entrypoint script o installare cron dentro l'immagine per mantenere esecuzione ricorrente in workload effimeri.

La detection di T1053 richiede correlazione tra registrazione del task ed esecuzione del payload, perché il solo evento di creazione produce troppo rumore. Su Windows le fonti primarie sono il Security log con EventCode 4698 (task creato), 4699 (task eliminato), 4702 (task aggiornato), integrate dal canale dedicato Microsoft-Windows-TaskScheduler/Operational che registra EventCode 106 per la registrazione, 140/141 per modifiche e 200/201 per l'esecuzione effettiva. Sysmon (gratuito) fornisce il complemento essenziale con EventID 1 per i processi generati e EventID 11/13 per la scrittura del file XML del task in *C:\Windows\System32\Tasks*.

La regola comportamentale efficace correla la registrazione di un task con l'autore (campo TaskAuthor dell'XML) e il binario invocato: un task creato da un utente non amministrativo che punta a powershell.exe, rundll32.exe, mshta.exe o binari in directory scrivibili (%TEMP%, %APPDATA%, C:\Users\Public) merita alta priorità. Una seconda regola cerca la finestra temporale tra creazione ed esecuzione: un task registrato e triggerato entro pochi minuti è comportamento anomalo rispetto a pacchetti software legittimi che tipicamente pianificano attività quotidiane o settimanali.

Su Linux il monitoraggio avviene tramite auditd con regole watch su /etc/crontab, /etc/cron.d/, /var/spool/cron/ e /etc/systemd/system/.timer*. Un esempio di regola: -w /etc/cron.d/ -p wa -k cron_mod. Utenti di servizio come www-data o nobody che scrivono cron entry sono outlier ad alto valore, così come pattern di schedulazione insoliti (esecuzione ogni minuto, orari notturni fuori dalle finestre di manutenzione).

Su macOS l'unified log di Apple registra le operazioni di launchd; il subsystem com.apple.xpc.launchd permette di isolare eventi di caricamento plist. Label che non corrispondono a bundle identifier di vendor noti (formato com.vendor.product) e path di esecuzione fuori da /Applications, /usr/bin o /usr/local/bin sono indicatori solidi.

Sul fronte D3FEND le tecniche difensive rilevanti sono Scheduled Job Analysis e Process Spawn Analysis: la prima esamina metadati e comandi dei job pianificati per anomalie, la seconda correla i processi generati dal servizio scheduler con la loro reputazione. I falsi positivi principali derivano da suite di aggiornamento software (Adobe, Google, produttori hardware) e da agent di endpoint management; una baseline whitelist per TaskName + hash del binario invocato riduce drasticamente il rumore.

In ambienti containerizzati e ESXi il monitoraggio delle syscall execve generate dal PID di cron o dallo scheduler nativo permette di identificare esecuzioni ricorrenti anomale nella breve vita di un container.

L'analisi forense di T1053 parte da artefatti persistenti che sopravvivono a reboot e cleanup superficiali, il che rende questa tecnica particolarmente favorevole al forense retrospettivo.

Su Windows la fonte primaria è la directory *C:\Windows\System32\Tasks*, che contiene un file XML per ogni task registrato con metadata completi: Author, Date di creazione, URI, Triggers, Actions con il comando esatto e argomenti, Principal con il contesto di esecuzione. Il timestamp del filesystem NTFS ($MFT) fornisce il momento esatto di scrittura del task; correlare questa data con l'attività dell'utente autore permette di ricostruire la sessione di compromissione. Un secondo repository è il registro in *HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree* e *\Tasks*, che duplica le informazioni e conserva il SID dell'autore. Il log evento Microsoft-Windows-TaskScheduler%4Operational.evtx mantiene la storia di registrazioni ed esecuzioni con EventID 106, 200, 201, 140, 141; su sistemi con retention adeguata copre settimane di attività.

Strumenti come Autoruns (gratuito, Sysinternals) enumerano tutti i task registrati con indicatore di firma digitale del binario invocato, mentre KAPE (gratuito per uso non commerciale) automatizza la raccolta dei file in System32\Tasks e del registro TaskCache. Eric Zimmerman's Tools (open source) include parser dedicati per l'analisi offline degli XML.

Su Linux la timeline forense si costruisce dai file crontab per utente in /var/spool/cron/crontabs/, dalle directory di sistema /etc/cron.hourly/, daily/, weekly/, monthly/ e da /etc/cron.d/. I timestamp mtime e ctime di questi file identificano il momento di installazione della persistenza. Per systemd, i file unit in /etc/systemd/system/.timer* e i corrispondenti .service vanno confrontati con quelli distribuiti dai pacchetti (verifica tramite dpkg -V su Debian/Ubuntu o rpm -Va su RHEL/Fedora): qualsiasi unit non tracciato dal package manager è sospetto. Il log /var/log/syslog o journalctl con filtro _SYSTEMD_UNIT=cron.service traccia le esecuzioni effettive.

Su macOS gli artefatti chiave sono i plist in /Library/LaunchDaemons/, /Library/LaunchAgents/, ~/Library/LaunchAgents/ e le corrispondenti directory di sistema /System/Library/. L'unified log accessibile via log show --predicate 'subsystem == "com.apple.xpc.launchd"' ricostruisce load e run dei job.

Su ESXi vanno esaminati /etc/rc.local.d/local.sh, /var/spool/cron/crontabs/root e i log hostd.log e shell.log per identificare sessioni SSH che hanno modificato questi file.

Dal punto di vista D3FEND gli artefatti rilevanti sono Scheduled Job e Process con le loro relazioni: la timeline che collega creazione del job, prima esecuzione, processo figlio e attività di rete costituisce l'evidenza principale in un report di incident response. La correlazione con Lokibot (S0447), che secondo la telemetria MITRE utilizza timeSetEvent per schedulare la propria seconda fase, mostra come anche timer intra-processo (non solo scheduler OS) rientrino nell'analisi.

La tecnica T1053 è tra le più universalmente adottate nel panorama offensivo perché sfrutta funzionalità legittime presenti ovunque, richiede competenze modeste e produce persistenza affidabile. I dati MITRE forniti associano direttamente alla tecnica un solo elemento software: Lokibot (S0447), un information stealer commodity distribuito prevalentemente via phishing con allegati Office armati o loader intermedi. La particolarità documentata di Lokibot è l'uso della API multimediale timeSetEvent nella DLL di seconda fase per pianificare la propria esecuzione ricorrente: si tratta di una variante intra-processo della pianificazione, che evita la scrittura di task nel Task Scheduler e riduce quindi la visibilità dei classici EventID 4698. Questa scelta implementativa mostra come attori financially-motivated preferiscano meccanismi di pianificazione a bassa visibilità pur di prolungare la finestra di raccolta credenziali prima del takedown.

A livello di trend, l'uso di schtasks.exe con opzioni /RU SYSTEM e /S è documentato in una vasta gamma di intrusioni: ransomware operator lo utilizzano per distribuire payload finali su interi domini una volta ottenute credenziali privilegiate, sfruttando la capacità di creazione remota per parallelizzare l'esecuzione. Il ricorso a systemd timer su Linux è invece indicatore di attori più sofisticati o consapevoli della migrazione progressiva delle distribuzioni enterprise verso systemd: la telemetria tradizionalmente centrata su cron può mancare completamente questi vettori se le regole di audit non coprono /etc/systemd/system/.

Su macOS l'abuso di LaunchAgent/LaunchDaemon è ricorrente in famiglie di malware nordcoreano documentate contro settore finanziario e cripto, oltre che in adware commerciale. Il pattern comune è la creazione di plist con label che imitano vendor legittimi (es. com.apple.updater invece del formato canonico com.apple.) o versioni scritte in cartelle utente per evitare richieste di privilegi.

Su ESXi la pianificazione tramite cron o modifica di local.sh è emersa come tecnica di persistenza in campagne ransomware contro infrastrutture di virtualizzazione, dove un attaccante che ottenga accesso all'hypervisor può mantenere una backdoor che sopravvive a reinstallazioni dei singoli guest.

Sul fronte difensivo il mapping di mitigazioni MITRE richiama cinque controlli: M1018 (User Account Management) per limitare chi può creare task remoti, M1022 (Restrict File and Directory Permissions) per proteggere directory di scheduler da scritture non privilegiate, M1026 (Privileged Account Management) per configurare Increase Scheduling Priority solo per Administrators, M1028 (Operating System Configuration) per forzare i task a girare nel contesto dell'utente autenticato invece che come SYSTEM tramite la chiave HKLM\SYSTEM\CurrentControlSet\Control\Lsa\SubmitControl, e M1047 (Audit) per identificare tramite tool come PowerSploit/PowerUp le debolezze di permessi su task esistenti che consentirebbero privilege escalation. La combinazione di questi controlli, unita a detection comportamentale su registrazione ed esecuzione, costituisce la baseline minima per un programma di difesa maturo contro T1053.

MITRE ATT&CK: tecnica T1053 (Scheduled Task/Job), tattiche TA0002/TA0003/TA0004, software S0447 (Lokibot), mitigazioni M1018, M1022, M1026, M1028, M1047, analytics DET0094 (AN0258-AN0262). MITRE D3FEND: Scheduled Job Analysis, Process Spawn Analysis. Parte del contenuto operativo (comandi schtasks, systemd timer, launchctl, tool Impacket, PowerSploit, Autoruns, KAPE, Sysmon) deriva da conoscenza professionale di cybersecurity basata su documentazione ufficiale dei tool e delle piattaforme OS.