Systemd Timers: Task Scheduling via Systemd Timer Units (T1053.006)

In un ingaggio red team su Linux, l'impianto di un systemd timer è una routine di persistenza pulita e riproducibile in laboratorio. Il presupposto è avere ottenuto una shell con privilegi adeguati: root per la persistenza system-wide, utente standard per quella user-level.

Per la variante privilegiata si creano due file. Il primo è il service unit in /etc/systemd/system/backdoor.service, che dichiara Type=simple e imposta ExecStart= verso il payload (ad esempio una reverse shell in Python o un binario compilato). Il secondo è il timer in /etc/systemd/system/backdoor.timer, con una sezione [Timer] che definisce OnBootSec= e OnUnitActiveSec= per riattivare il servizio a intervalli regolari, e una sezione [Install] con WantedBy=timers.target. L'attivazione avviene con:

systemctl daemon-reload

systemctl enable --now backdoor.timer

La verifica dello stato si ottiene con systemctl list-timers --all, che elenca tutti i timer con prossima attivazione e ultimo trigger.

Per la persistenza user-level, il red teamer scrive i file in ~/.config/systemd/user/ e li abilita con systemctl --user enable --now backdoor.timer. Va notato che i timer utente richiedono una sessione attiva o l'abilitazione di loginctl enable-linger per l'account, così da mantenere il manager utente residente anche senza login interattivo — un dettaglio che spesso passa inosservato ai difensori.

Sul piano dell'offuscamento, i nomi delle unit vengono scelti per mimare servizi legittimi (ad esempio systemd-resolved-helper.timer o dbus-monitor.timer) e i payload vengono spostati in path plausibili come /usr/local/lib/ o /var/lib/. La calendarizzazione con OnCalendar= permette schedule realistiche (settimanali, notturne) meno rumorose degli intervalli brevi.

Sul fronte tooling, framework come Metasploit (open source) espongono moduli di persistenza Linux che possono essere adattati, mentre Empire nella sua fork mantenuta BC-Security (open source) e Sliver di Bishop Fox (open source) permettono di orchestrare l'impianto e la gestione dell'implant. Per la fase di ricognizione locale prima dell'impianto, LinPEAS dal progetto PEASS-ng (open source) enumera timer esistenti, permessi sulle directory systemd e configurazioni sospette, aiutando a scegliere il vettore meno rilevabile. In laboratorio è utile validare la detection con Atomic Red Team di Red Canary (open source), che include test dedicati a T1053.006.

La detection dell'abuso di systemd timer si costruisce correlando tre segnali: la creazione o modifica di unit file, l'invocazione di systemctl in contesti anomali e l'esecuzione di processi figli di PID 1 (systemd) con caratteristiche sospette. La regola comportamentale AN0645 riassume questo approccio, focalizzandosi su Linux e sfruttando come log source principali auditd via SYSCALL e osquery.

La telemetria centrale è auditd. Regole mirate su execve catturano l'esecuzione di systemctl enable, systemctl start e daemon-reload, mentre watch su open, openat e write verso /etc/systemd/system/, /usr/lib/systemd/system/ e ~/.config/systemd/user/ intercettano la scrittura di file .timer e .service. Una regola tipica è del tipo -w /etc/systemd/system/ -p wa -k systemd_persist, con chiave dedicata per facilitare la ricerca nel SIEM.

Su osquery (open source) la tabella startup_items e query personalizzate su file con pattern %.timer in path systemd forniscono uno snapshot periodico. Confrontare gli snapshot tra host omogenei del parco macchine consente di identificare unit anomale presenti solo su singoli endpoint.

Le dimensioni di tuning suggerite da AN0645 vanno recepite in regole di correlazione. Il TimerIntervalThreshold (ad esempio inferiore a cinque minuti) segnala schedule aggressive tipiche di beaconing C2. Il ParentProcessID pari a 1 conferma che il processo figlio è stato realmente invocato da systemd, escludendo esecuzioni manuali. Lo UserContext distingue tra timer di root e di utenti non privilegiati, mentre il TimerCreationPath discrimina tra persistenza system-wide e user-level.

Come tecniche difensive di detection, il monitoraggio di file creation e process spawning analysis sono i due pilastri. Un alert ad alta confidenza si costruisce combinando: creazione recente di un .timer in directory systemd, corrispondente .service con ExecStart= che punta a binari fuori dai path di pacchetti gestiti (/tmp, /var/tmp, /home, /dev/shm), e successiva esecuzione di quel binario con PPID 1.

I falsi positivi principali derivano da attività di configuration management (Ansible, Puppet, Chef) e da pacchetti che installano timer legittimi (logrotate.timer, fstrim.timer, apt-daily.timer). Il tuning prevede allowlist per gli utenti di automation e per i package manager, oltre alla correlazione con finestre di manutenzione. Sul fronte hardening, applicare M1022 con permessi restrittivi sulle directory systemd, M1026 limitando l'accesso a root e M1018 riducendo l'uso di systemctl e systemd-run ai soli account autorizzati chiude gran parte della superficie.

L'analisi forense di un sospetto abuso di systemd timer parte dalla raccolta degli unit file e dalla ricostruzione della timeline di installazione. Gli artefatti primari sono i file .timer e .service nelle tre directory canoniche: /etc/systemd/system/ per configurazioni amministrative, /usr/lib/systemd/system/ per unit installate da pacchetti, e ~/.config/systemd/user/ per la persistenza user-level. Anche /run/systemd/system/ va esaminata perché ospita unit generate dinamicamente.

Per ogni file rilevante l'analista estrae timestamp MAC (mtime, atime, ctime) con stat, e li correla con l'attività degli utenti nei log di autenticazione (/var/log/auth.log su Debian, /var/log/secure su RHEL) e con i comandi in .bash_history o .zsh_history degli utenti amministrativi. La discrepanza tra ctime di un unit file e l'assenza di corrispondenti transazioni in dpkg.log o yum.log/dnf.log è un indicatore forte di installazione manuale, quindi potenzialmente malevola.

Il journal di systemd è la seconda miniera di dati. Il comando journalctl --list-boots fornisce l'elenco delle sessioni di boot, mentre journalctl -u nome.timer e journalctl -u nome.service ricostruiscono attivazioni, esiti e messaggi di errore. Filtri per intervallo temporale (--since, --until) permettono di isolare la finestra di compromissione. L'output di systemctl list-timers --all fotografa lo stato corrente con next elapse, last trigger e unit associata.

Per verificare l'integrità dei file di sistema, il confronto con i database dei pacchetti tramite dpkg --verify su distribuzioni Debian-based o rpm -Va su Red Hat evidenzia modifiche a service unit legittimi. File in /etc/systemd/system/ che non appartengono ad alcun pacchetto meritano triage prioritario. La sezione [Service] va ispezionata cercando ExecStart=, ExecStartPre= ed ExecStartPost= che puntino a script in /tmp, /var/tmp, /dev/shm, /home o a interpreti (bash, python, perl) con argomenti codificati in base64.

Per la variante user-level, oltre agli unit file nella home, va verificato lo stato di linger in /var/lib/systemd/linger/: la presenza di un file con il nome dell'account indica che il manager utente resta attivo senza sessione, requisito operativo per la persistenza silenziosa.

Strumenti utili includono auditd (open source) per la ricostruzione degli eventi SYSCALL, Velociraptor di Rapid7 (open source) con artefatti Linux dedicati a systemd, e The Sleuth Kit (open source) per timeline filesystem complete. Wazuh (open source) integra File Integrity Monitoring nativo sulle directory systemd, generando eventi consultabili in fase di incident response. L'esportazione della timeline in formato bodyfile e l'analisi con plaso/log2timeline (open source) consente di intrecciare eventi filesystem, journal e log applicativi in un'unica vista cronologica.

I dati MITRE ATT&CK per T1053.006 non riportano al momento gruppi APT, software o campagne pubblicamente associati a questa specifica sotto-tecnica. Questa assenza di attribuzione formale non deve essere interpretata come scarsa rilevanza operativa, ma piuttosto come un'area in cui la telemetria pubblica e le pubblicazioni di threat intelligence sono ancora in fase di consolidamento rispetto alle sotto-tecniche più mature come T1053.003 (Cron) o T1053.005 (Scheduled Task).

Dal punto di vista dell'analisi strategica, il valore intelligence di questa tecnica risiede in tre osservazioni. La prima è la superficie di adozione: systemd è il gestore di init predefinito su Debian, Ubuntu, RHEL, CentOS Stream, Fedora, SUSE e le loro derivate enterprise, coprendo la maggioranza dei server Linux in ambienti cloud e on-premise. Un attaccante che investe in tooling per systemd timer massimizza il rendimento su un parco macchine ampio e omogeneo.

La seconda è la convergenza tra Execution, Persistence e Privilege Escalation nella stessa primitiva. Rispetto a cron, i systemd timer offrono granularità di calendarizzazione più ricca, integrazione con cgroup e namespace per isolare i processi, e la possibilità di legare l'attivazione a eventi (boot, avvio di altre unit, cambiamenti di stato). Per un threat actor questa flessibilità si traduce in schedule realistiche difficili da distinguere dal traffico legittimo di manutenzione.

La terza è il profilo dei target. Attori interessati a persistenza in ambienti server-side — operatori di ransomware con capacità Linux (Hive, ALPHV/BlackCat storicamente, LockBit Linux variant), gruppi focalizzati su cloud e container, e attori state-sponsored orientati a supply chain e infrastruttura critica — hanno un incentivo diretto a includere systemd timer nel proprio arsenale, anche in assenza di attribuzioni pubbliche codificate in MITRE.

Per un threat intelligence officer il consiglio operativo è duplice. Sul piano tattico, monitorare i feed di reportistica su intrusioni Linux (advisory CISA, report Mandiant, CrowdStrike, ESET, Kaspersky su campagne cloud e Linux) prestando attenzione a IOC che includano path in /etc/systemd/system/ o nomi di unit anomale. Sul piano strategico, alimentare il proprio programma di detection engineering con ipotesi di threat hunting focalizzate su T1053.006 anche in assenza di attribuzione, dato che l'assenza di dati pubblici non implica assenza di sfruttamento in the wild. La priorità va data ad asset Linux con esposizione internet, host di CI/CD e nodi Kubernetes, dove la persistenza post-compromise ha impatto operativo elevato.

MITRE ATT&CK T1053.006 (Scheduled Task/Job: Systemd Timers), tattiche TA0002, TA0003, TA0004. Mitigazioni M1018, M1022, M1026. Detection DET0231 con analytic AN0645 su log auditd SYSCALL e osquery. MITRE D3FEND per file creation analysis e process spawning analysis. Documentazione ufficiale systemd (systemd.timer, systemd.service, systemctl). Per comandi operativi, tool di detection e artefatti forensi è stata integrata conoscenza professionale verificata di cybersecurity Linux.