Abuso di Systemctl: Systemctl (T1569.003)
La tecnica T1569.003 descrive l'abuso di systemctl, l'interfaccia primaria per interagire con systemd, il gestore di servizi e init system predominante nelle distribuzioni Linux moderne. Systemctl consente di avviare, fermare, abilitare e disabilitare unità di servizio, e questa stessa flessibilità la rende un vettore di esecuzione privilegiato per attori malevoli che vogliono lanciare payload sotto forma di servizio persistente e ben integrato nel sistema operativo.
L'inquadramento MITRE colloca la tecnica nella tattica TA0002 (Execution), che raggruppa i metodi con cui l'avversario riesce a far girare codice sulla macchina compromessa. Nella kill chain, systemctl viene tipicamente sfruttato in fase post-exploitation: una volta ottenuto un accesso iniziale (spesso via credenziali SSH, container esposti o RCE su servizi web), l'attaccante crea o modifica un'unità .service e la carica con systemctl daemon-reload seguito da systemctl enable --now.
L'impatto è significativo perché un servizio systemd viene eseguito con privilegi elevati (spesso root), sopravvive ai reboot e si mimetizza tra centinaia di unità legittime. I dati MITRE riportano 1 gruppo APT noto per l'uso della tecnica — TeamTNT, specializzato in cryptojacking su ambienti Linux e cloud — e 1 mitigazione dedicata al controllo degli account autorizzati a invocare systemctl. Il monitoraggio efficace richiede correlazione tra modifica dei file unit e successive invocazioni del binario.
In un contesto red team, l'abuso di systemctl è una delle vie più pulite per ottenere persistenza ed esecuzione privilegiata su host Linux. Il presupposto è avere shell con capacità di scrittura in /etc/systemd/system/ oppure privilegi sudo sul binario systemctl.
Il flusso operativo tipico parte dalla creazione di un file unit. Un esempio minimo è un file /etc/systemd/system/backup-agent.service contenente sezioni [Unit], [Service] con direttiva ExecStart=/usr/local/bin/agent e [Install] con WantedBy=multi-user.target. La denominazione conta: nomi come backup-agent, telemetry-collector o systemd-networkd-helper riducono l'attenzione degli analisti rispetto a nomi generici.
Una volta scritto il file, la sequenza di attivazione è:
systemctl daemon-reload
systemctl enable --now backup-agent.service
Il primo comando forza systemd a rileggere le unit, il secondo abilita l'avvio automatico al boot e lo lancia immediatamente. Per verificare lo stato senza generare troppo rumore si usa systemctl status backup-agent o systemctl is-active backup-agent.
Esistono varianti più stealth. Le user units in ~/.config/systemd/user/ non richiedono root e si attivano con systemctl --user enable, utili in scenari dove si compromette un account non privilegiato ma con sessione persistente (attivabile via loginctl enable-linger). Un'altra tecnica è l'uso di systemd timers al posto di cron: un file .timer accoppiato a un .service fornisce esecuzione schedulata con logging separato e minore ispezione da parte di molti tool EDR.
Per laboratorio e simulazioni, framework utili sono Atomic Red Team (open source), che include test T1569.003 pronti all'uso, e Sliver (open source), il C2 in Go che supporta la generazione di implant Linux facilmente wrappabili in unit file. Metasploit Framework (open source, con edizione Pro a pagamento) offre moduli post-exploitation Linux che possono essere combinati con script bash per il deploy dell'unità.
Durante gli engagement è buona pratica documentare timestamp esatti di daemon-reload ed enable, contenuto integrale del file .service e output di systemctl list-unit-files --state=enabled prima e dopo l'inserimento, per dimostrare al blue team la finestra di detection e supportare il purple teaming successivo. Ricordare sempre di rimuovere l'unità con systemctl disable --now e cancellare il file al termine del test.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo