Servizi Systemd Malevoli: Systemd Service (T1543.002)

Per simulare questa tecnica in un laboratorio red team è necessario un sistema Linux con systemd attivo — qualsiasi distribuzione recente va bene. L'obiettivo è dimostrare come un attaccante possa ottenere persistenza creando un servizio malevolo e, facoltativamente, scalare i privilegi attraverso la direttiva User.

Il primo scenario, il più diretto, replica il pattern usato da malware come Gomir, che crea un servizio denominato syslogd. Si crea un unit file nella directory di sistema e lo si abilita:

sudo tee /etc/systemd/system/syslogd.service <<EOF [Unit] Description=System Logger Daemon [Service] Type=simple ExecStart=/tmp/payload.sh Restart=on-failure [Install] WantedBy=multi-user.target EOF

sudo systemctl daemon-reload sudo systemctl enable --now syslogd.service

La clausola WantedBy=multi-user.target garantisce l'avvio automatico quando il sistema entra nel runlevel multiutente — lo stesso pattern usato durante la campagna 2022 Ukraine Electric Power Attack (C0034) per mantenere la persistenza di GOGETTER.

Il secondo scenario simula la privilege escalation attraverso la direttiva User. Se l'attaccante ha accesso in scrittura alla directory /etc/systemd/system/ ma opera come utente non privilegiato, può specificare User=root nel unit file, facendo eseguire il payload con permessi di root al prossimo avvio del servizio.

Il terzo scenario sfrutta i symlink, come documentato per SysUpdate: si posiziona il payload in una directory utente e si crea un link simbolico nella directory di sistema.

ln -s /home/user/.local/bin/implant /etc/systemd/system/update-helper.service

Per simulare la persistenza a livello utente — utile quando non si dispone di root — si opera nella directory $HOME/.config/systemd/user/ e si usa:

systemctl --user enable --now nome-servizio.service

Il tool Pupy (open source) include un modulo dedicato che automatizza la creazione del servizio systemd per la persistenza. In un esercizio red team, usare Pupy permette di verificare se le detection del blue team intercettano la catena completa: creazione file, daemon-reload, enable, start.

Per la fase di cleanup, rimuovere il servizio con:

sudo systemctl disable --now syslogd.service sudo rm /etc/systemd/system/syslogd.service sudo systemctl daemon-reload

La detection di questa tecnica si basa su due pilastri: il monitoraggio delle operazioni sul filesystem nelle directory systemd e l'osservazione dei comandi systemctl. L'analytic AN0701 fornisce un framework solido, ma richiede tuning attento per evitare un diluvio di falsi positivi in ambienti con frequenti deployment automatizzati.

La prima sorgente di log è auditd (open source), che va configurato per intercettare le scritture nelle directory critiche. Le regole da aggiungere al file di configurazione di auditd sono:

-w /etc/systemd/system/ -p wa -k systemd_persist -w /lib/systemd/system/ -p wa -k systemd_persist -w /usr/lib/systemd/system/ -p wa -k systemd_persist -w /run/systemd/generator/ -p wa -k systemd_generators

Queste regole generano eventi SYSCALL ogni volta che un file viene creato o modificato in quelle directory. L'evento include il processo responsabile, l'utente e il path completo — tutte informazioni essenziali per il triage.

La seconda sorgente è osquery (open source), che consente query periodiche sulla tabella systemd_units per individuare servizi anomali. Una query utile è:

SELECT name, source_path, sub_status, fragment_path FROM systemd_units WHERE fragment_path LIKE '/etc/systemd/system/%' AND source_path NOT IN (SELECT path FROM rpm_packages UNION SELECT path FROM deb_packages);

Questa query identifica unit file che non appartengono a nessun pacchetto installato — un indicatore forte di persistenza illegittima.

Per il tuning, l'analytic suggerisce cinque parametri chiave da calibrare. Il ServicePathRegex filtra le directory monitorate, evitando rumore da path non rilevanti. L'ExecStartPathAllowlist è probabilmente il più efficace: costruendo una allowlist di binary path legittimi (tipicamente /usr/bin/, /usr/sbin/, /bin/), ogni servizio il cui ExecStart punta a /tmp, /dev/shm o directory utente genera un alert ad alta priorità. Il FileEntropyThreshold aggiunge un livello di analisi: binari con entropia elevata referenziati da ExecStart sono spesso payload offuscati o packed.

Il parametro SystemctlOperationSet merita attenzione particolare. La sequenza systemctl enable seguita da systemctl start entro un intervallo breve (ad esempio 30 secondi) è un pattern tipico dell'attaccante che vuole attivare immediatamente il servizio e garantirne la persistenza. In un ambiente operativo normale, i deployment automatizzati tendono a usare un singolo comando systemctl enable --now, rendendo la sequenza separata un indicatore più affidabile.

Per la gestione dei falsi positivi, escludere gli account di servizio usati da tool di configuration management come Ansible, Puppet o Chef, e correlare con il contesto: un nuovo .service creato da un processo python o bash lanciato da una sessione SSH interattiva ha una priorità di indagine molto più alta rispetto a uno creato dal package manager.

L'analisi forense di una persistenza via systemd service si sviluppa su tre assi: i file .service stessi, i log di sistema e gli artefatti del filesystem che documentano la catena temporale dell'installazione.

Il punto di partenza è l'enumerazione di tutti i unit file presenti nelle directory critiche. I timestamp del filesystem — in particolare il change time (ctime) che non può essere facilmente falsificato — forniscono il primo ancoraggio temporale. Utilizzando stat su ogni file sospetto:

stat /etc/systemd/system/syslogd.service

Si ottengono access time, modify time e change time. Il ctime indica quando i metadati del file sono stati modificati per l'ultima volta, inclusa la creazione stessa. Confrontando questo timestamp con i log di autenticazione in /var/log/auth.log o nel journal di systemd, è possibile correlare la creazione del servizio con una sessione SSH o un'escalation sudo specifica.

Il journal di systemd è una fonte forense ricchissima. Interrogandolo con:

journalctl -u syslogd.service --no-pager --output=json-pretty

Si ottiene la cronologia completa di avvii, arresti, errori e output del servizio. Per ricostruire cosa è stato eseguito al primo avvio, cercare le righe con il campo _SYSTEMD_UNIT corrispondente. Se il malware ha prodotto output su stdout o stderr, journald lo avrà catturato.

I symlink meritano verifica dedicata, poiché malware come SysUpdate li usa per disaccoppiare la posizione apparente del servizio dalla posizione reale del payload. Il comando:

find /etc/systemd/system /lib/systemd/system /usr/lib/systemd/system -type l -ls

Elenca tutti i link simbolici nelle directory systemd, rivelando se un servizio apparentemente legittimo punta a un binario in una posizione inusuale. La campagna 2022 Ukraine Electric Power Attack (C0034) ha dimostrato come la persistenza systemd possa essere configurata in modo sottile, usando la direttiva WantedBy=multi-user.target per mimetizzarsi tra servizi legittimi.

Per la ricostruzione della timeline, integrare i dati di auditd. Se le regole di audit erano attive prima della compromissione, il file /var/log/audit/audit.log contiene gli eventi SYSCALL con il PID, l'UID e il path esatto di ogni scrittura nelle directory monitorate. Utilizzando ausearch (open source, parte del pacchetto audit):

ausearch -k systemd_persist -i --format text

Si ottiene la lista filtrata di tutti gli eventi correlati alla chiave impostata nelle regole di audit. Ogni evento include l'eseguibile che ha effettuato la scrittura — informazione cruciale per risalire al vettore di installazione del malware.

Analizzare anche la directory /run/systemd/generator/ per individuare unit file creati dinamicamente dai systemd generators, un vettore meno conosciuto ma documentato nella descrizione della tecnica. Questi file vengono rigenerati ad ogni boot, quindi è fondamentale acquisire l'immagine del sistema prima di un riavvio.

L'abuso dei servizi systemd per la persistenza è adottato da gruppi con obiettivi e sofisticazione molto differenti, ma accomunati dalla necessità di mantenere accesso a lungo termine su infrastrutture Linux.

TeamTNT (G0139) rappresenta il profilo finanziariamente motivato. Questo gruppo, noto per le operazioni di cryptojacking in ambienti cloud e container, ha usato systemctl per creare servizi dedicati al mining di criptovalute. La persistenza via systemd garantisce che il miner sopravviva ai riavvii, massimizzando il rendimento economico dell'intrusione. Il pattern operativo di TeamTNT è tipicamente opportunistico: scansione massiva di servizi esposti, compromissione automatizzata, installazione del miner con persistenza. La scelta di systemd riflette la prevalenza di distribuzioni Linux moderne negli ambienti cloud.

Scattered Spider (G1015) mostra un approccio diverso, più orientato all'intrusione mirata. Il gruppo ha utilizzato la variabile d'ambiente SYSTEMD_UNIT_PATH per reindirizzare systemd verso un unit file personalizzato per il tool di accesso remoto Teleport. Questa tecnica è più sottile rispetto alla semplice creazione di un file in /etc/systemd/system/: manipolando il path di ricerca, il servizio malevolo può risiedere in una posizione meno monitorata. Scattered Spider opera prevalentemente contro organizzazioni del settore telecomunicazioni e tecnologico, e la scelta di Teleport come strumento di accesso remoto indica una preferenza per tool che possono mimetizzarsi come strumenti IT legittimi.

Rocke (G0106), come TeamTNT, è focalizzato sul cryptojacking. L'installazione di script di servizio systemd per la persistenza segue un pattern ormai consolidato negli attori finanziari che colpiscono infrastrutture Linux.

La campagna 2022 Ukraine Electric Power Attack (C0034) aggiunge una dimensione geopolitica critica. Sandworm Team ha usato systemd per mantenere la persistenza di GOGETTER all'interno di un'utility elettrica ucraina, combinandola con CaddyWiper e tecniche living-off-the-land. La configurazione WantedBy=multi-user.target garantiva l'avvio automatico del tunnel dopo ogni riavvio, elemento essenziale per un'operazione che doveva mantenere l'accesso SCADA nel tempo.

Sul fronte software, emerge un pattern interessante: 8 malware distinti implementano questa tecnica, da tool multipiattaforma come Pupy (open source) a implant sofisticati come SysUpdate, che combina symlink e direttiva ExecStart per ottenere simultaneamente persistenza e privilege escalation. RotaJakiro adotta un approccio condizionale, attivando la persistenza systemd solo quando rileva di avere permessi root e una distribuzione compatibile — segno di un malware progettato per operare in ambienti eterogenei.

La tendenza emergente è l'uso dei systemd generators come vettore di persistenza. Poiché generano unit file dinamicamente al boot, offrono un livello di evasione superiore: il file malevolo esiste solo dopo il riavvio e viene ricreato automaticamente, complicando la remediation tradizionale basata sulla semplice rimozione del file.

Framework MITRE ATT&CK v16 — T1543.002 (Systemd Service), tattiche TA0003, TA0004. Campagna C0034 (2022 Ukraine Electric Power Attack). Detection DET0253, analytic AN0701. Mitigazioni M1018, M1022, M1026, M1033. Tool di detection: auditd, osquery, ausearch. Integrato con conoscenza professionale per tool e procedure operative.