Esecuzione via Systemctl: System Services – Systemctl (T1569.003)

Per simulare la tecnica in laboratorio serve una macchina Linux con systemd (qualsiasi distribuzione recente funziona) e accesso root o un account nel gruppo systemd-journal con permessi di scrittura su /etc/systemd/system.

Il primo passo è creare un file unit malevolo. In un engagement reale l'attaccante spesso scrive il file direttamente da una reverse shell; in lab puoi simularlo così:

cat <<'EOF' > /etc/systemd/system/updater.service

[Unit]
Description=System Update Helper

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'id > /tmp/pwned.txt'

[Install]
WantedBy=multi-user.target

EOF

La sezione ExecStart contiene il payload — qui un semplice proof-of-concept che scrive l'output di id in un file. In uno scenario offensivo reale, TeamTNT ha utilizzato servizi systemd per lanciare software di cryptomining, sostituendo quel comando innocuo con un miner persistente.

A questo punto si ricarica la configurazione di systemd e si avvia il servizio:

systemctl daemon-reload systemctl start updater.service

Per verificare l'esecuzione: systemctl status updater.service mostrerà lo stato del servizio, e cat /tmp/pwned.txt confermerà l'output. Per aggiungere persistenza al riavvio basta un ulteriore passaggio:

systemctl enable updater.service

Un aspetto spesso trascurato nei test è la collocazione del file unit. Gli avversari più sofisticati posizionano file in directory non standard — ad esempio /tmp o /dev/shm — per evadere i controlli. Puoi simulare anche questa variante creando un link simbolico oppure specificando un percorso custom tramite systemctl link:

systemctl link /tmp/sneaky.service systemctl start sneaky.service

Per la fase di cleanup, elemento fondamentale in qualsiasi esercizio red team:

• systemctl stop updater.service
• systemctl disable updater.service
• rm /etc/systemd/system/updater.service
• systemctl daemon-reload

Tool utili: pspy (open source) permette di monitorare in tempo reale i processi generati senza privilegi root, utile per validare che il servizio abbia effettivamente eseguito il payload. Atomic Red Team (open source) del progetto Red Canary include test atomici per la creazione di servizi systemd che automatizzano questa simulazione.

La detection di questa tecnica poggia su un principio semplice: correlazione tra la scrittura di un file unit e la successiva invocazione di systemctl. Le log source fondamentali sono i record auditd di tipo EXECVE, SYSCALL e CONFIG_CHANGE.

Configura auditd per intercettare le scritture nelle directory critiche. La regola seguente monitora le due posizioni standard dei file unit:

-w /etc/systemd/system -p wa -k systemd_unit_mod -w /usr/lib/systemd/system -p wa -k systemd_unit_mod

Queste regole generano un evento ogni volta che un file viene scritto (w) o i suoi attributi cambiano (a) in quelle directory. La chiave systemd_unit_mod consente di filtrare rapidamente nel SIEM.

Per la parte di esecuzione, aggiungi una regola sulle invocazioni di systemctl:

-a always,exit -F exe=/usr/bin/systemctl -F arch=b64 -S execve -k systemctl_exec

L'alert più efficace nasce dalla correlazione temporale tra i due eventi: se nello stesso intervallo di tempo — ad esempio 60 secondi — compare sia una modifica a un file .service sia un'invocazione di systemctl start o systemctl daemon-reload, la probabilità di un'azione offensiva è alta.

I sottocomandi su cui concentrare l'attenzione sono tre: start, enable e daemon-reload. Invocazioni di systemctl status o systemctl list-units sono generalmente benigne e genererebbero troppo rumore.

Per ridurre i falsi positivi, il tuning più importante riguarda le change window: se l'organizzazione applica patch e configurazioni in finestre di manutenzione programmate, escludi quegli orari dall'alert. Altro filtro efficace è l'utente: le operazioni condotte da account di automazione noti (Ansible, Puppet, Chef) con hash di processo verificato possono essere inserite in una whitelist, mentre qualsiasi invocazione da un utente non privilegiato o da una shell interattiva in orario anomalo merita escalation immediata.

Aggiungi anche una regola per i percorsi sospetti: qualsiasi file unit referenziato da /tmp, /dev/shm, /var/tmp o dalla home di un utente non amministrativo è un indicatore forte. Un approccio complementare prevede l'uso di Auditbeat (open source, di Elastic) per inviare gli eventi auditd direttamente a un cluster Elasticsearch, dove le regole di correlazione possono essere implementate come detection rules nel modulo SIEM di Elastic Security (freemium).

L'analisi forense di un abuso di systemctl lascia tracce su più livelli del filesystem e dei log di sistema. Il primo artefatto da cercare è il file unit stesso. I servizi systemd personalizzati risiedono tipicamente in /etc/systemd/system, ma un attaccante potrebbe aver usato directory meno ovvie. Un buon punto di partenza è cercare tutti i file .service modificati di recente:

find /etc/systemd/system /usr/lib/systemd/system /run/systemd/system -name ".service" -mtime -30 -ls*

Esamina il contenuto di ciascun file sospetto prestando attenzione alla direttiva ExecStart: path assoluti verso binari in /tmp, /dev/shm o directory utente sono un red flag immediato. Verifica anche le direttive User e Group — un servizio che gira come root senza necessità operativa è anomalo.

Il secondo strato di evidenze si trova nei log di journald. Ogni servizio systemd genera messaggi catturati dal journal:

journalctl -u nome-servizio-sospetto.service --no-pager --output=json-pretty

L'output JSON include timestamp precisi, PID del processo, codice di uscita e messaggi stdout/stderr. Questi dati sono preziosi per ricostruire esattamente quando il servizio è stato avviato e cosa ha eseguito.

Il terzo livello è il log auditd. Se le regole erano attive al momento dell'intrusione, i record SYSCALL e EXECVE contengono l'intera riga di comando passata a systemctl, il PID del processo chiamante, l'UID reale e effettivo, e il timestamp. Usa ausearch per estrarre gli eventi rilevanti:

ausearch -k systemd_unit_mod -i ausearch -k systemctl_exec -i

Nel caso di TeamTNT, la sequenza tipica da ricostruire in timeline è: download del miner (spesso tramite curl o wget), scrittura del file .service, invocazione di systemctl daemon-reload seguita da systemctl enable --now. Cerca quindi anche gli artefatti di rete correlati — la bash_history dell'utente compromesso e i log DNS per risoluzioni verso pool di mining.

Infine, controlla lo stato dei link simbolici in /etc/systemd/system/multi-user.target.wants/: un servizio abilitato crea qui un symlink. La data di creazione del link (accessibile tramite stat) fornisce un ulteriore timestamp per ancorare la timeline.

TeamTNT (G0139)

TeamTNT è il gruppo documentato per l'utilizzo operativo di questa tecnica. Il collettivo, specializzato in attacchi contro infrastrutture cloud e container, ha creato servizi systemd specificamente per eseguire software di cryptomining in modo persistente sugli host compromessi. Il pattern operativo è coerente: dopo l'accesso iniziale — spesso tramite credenziali cloud esposte o API Docker/Kubernetes mal configurate — il gruppo installa un miner e ne garantisce la sopravvivenza ai riavvii registrandolo come servizio di sistema.

Questa scelta tattica rivela alcune priorità strategiche di TeamTNT. L'uso di systemctl anziché crontab o script in .bashrc indica una preferenza per meccanismi nativi del sistema operativo che si confondono con l'attività amministrativa legittima. Un servizio systemd offre inoltre vantaggi operativi come il restart automatico in caso di crash (direttiva Restart=always), la gestione dei limiti di risorse tramite cgroups, e la capacità di mascherare il processo con un nome innocuo nel listing dei servizi.

Dal punto di vista del profilo geografico e delle motivazioni, TeamTNT opera primariamente con finalità finanziarie. I target sono ambienti Linux in cloud — AWS, GCP, Azure — dove le risorse computazionali sottratte si traducono direttamente in profitto tramite mining di criptovalute come Monero.

Per anticipare le prossime mosse, il threat intelligence officer dovrebbe monitorare l'overlap tra strumenti di TeamTNT e l'ecosistema di tool open source per il mining: cambiamenti nei pool di mining utilizzati, nuovi wallet address, e varianti dei payload sono tutti indicatori di evoluzione della campagna. La mitigazione raccomandata — User Account Management (M1018) — suggerisce che il vettore primario resta lo sfruttamento di account con privilegi eccessivi, il che rende il monitoraggio delle configurazioni IAM in ambienti cloud una priorità di intelligence operativa.

Framework MITRE ATT&CK: tecnica T1569.003 (System Services: Systemctl), tattica TA0002, gruppo G0139, mitigazione M1018, detection DET0073/AN0200. Tool di detection: auditd, ausearch, journalctl, Auditbeat, Elastic Security. Simulazione: Atomic Red Team, pspy. Integrato con conoscenza professionale per tool e procedure operative.