Arresto dei Servizi: Service Stop (T1489)

L'arresto dei servizi è una tecnica ad alto impatto ma tecnicamente semplice da riprodurre in laboratorio. L'obiettivo di una simulazione red team non è solo fermare un servizio, ma ricostruire l'intera catena comportamentale: elevazione dei privilegi, enumerazione dei servizi attivi, arresto mirato e verifica che i data store siano effettivamente sbloccati per la manipolazione.

Su Windows, il punto di partenza è l'enumerazione. Con una shell elevata si può ottenere l'elenco dei servizi in esecuzione filtrando quelli di interesse:

sc query state= all | findstr /i "MSSQL Exchange Veeam"

Per simulare il comportamento di Conti, che arresta fino a 146 servizi, il comando nativo è diretto:

net stop MSSQLSERVER /y

Il flag /y conferma automaticamente l'arresto dei servizi dipendenti, replicando il comportamento automatizzato del malware. Per un approccio più aggressivo alla Wizard Spider, si può combinare taskkill.exe per i processi e net.exe per i servizi:

taskkill /F /IM sqlservr.exe /T

L'uso di sc config consente di disabilitare il servizio al riavvio, come fa Olympic Destroyer tramite l'API ChangeServiceConfigW:

sc config MSExchangeIS start= disabled

Su Linux, la simulazione è altrettanto lineare. Per fermare un servizio database in modo analogo a quanto descritto per gli analitici di detection:

sudo systemctl stop mysql

Per verificare lo stato post-arresto e confermare che il data store sia accessibile:

systemctl is-active mysql && echo "Ancora attivo" || echo "Servizio fermo"

Su ESXi, la simulazione richiede accesso SSH all'hypervisor. Il comando usato da famiglie come Cheerscrypt per terminare le VM è:

esxcli vm process kill --type=force --world-id=<ID_VM>

Per ottenere gli ID delle VM attive prima dell'arresto:

esxcli vm process list

In ambiente macOS, la tecnica sfrutta launchctl per disabilitare daemon di sistema:

sudo launchctl bootout system/com.apple.securityd

Per l'automazione in laboratorio, Atomic Red Team (open source) offre test atomici specifici per T1489 che eseguono esattamente queste catene. Si consiglia di eseguire ogni test con Sysmon (gratuito, Microsoft Sysinternals) attivo per generare la telemetria necessaria alla validazione delle regole di detection.

Un aspetto spesso trascurato è la sequenza temporale: nei ransomware reali, l'arresto dei servizi precede la cifratura di pochi secondi. Il red teamer dovrebbe misurare la finestra tra lo stop e l'azione distruttiva simulata, per verificare se il SOC riesce a intervenire in quel margine.

Il rilevamento dell'arresto dei servizi è insidioso perché i comandi coinvolti — net stop, sc.exe, taskkill.exe — sono strumenti di amministrazione legittima. La chiave non è il singolo evento, ma la catena comportamentale e il volume degli arresti in una finestra temporale ristretta.

Su Windows, la fonte primaria è il log System, dove l'EventCode 7036 registra ogni cambio di stato di un servizio. Un singolo arresto di MSSQLSERVER non è allarmante; dieci servizi fermati in 30 secondi da uno stesso processo padre lo è eccome. Il log Sysmon arricchisce il quadro: l'EventID 1 (Process Creation) cattura l'esecuzione di net.exe, sc.exe o taskkill.exe, mentre l'EventID 13 (Registry Value Set) rileva modifiche alla chiave SYSTEM\CurrentControlSet\Services — il meccanismo usato da Industroyer per rendere i servizi inoperabili a livello di registro.

La detection comportamentale suggerita dai dati (AN0061) si basa su una catena precisa: contesto di esecuzione elevato, seguito da comando di arresto servizio, seguito da manipolazione file. La regola SIEM dovrebbe correlare questi tre elementi in una finestra di 5-10 minuti. Il tuning è critico: la lista dei servizi monitorati deve includere almeno MSExchangeIS, SQLSERVERAGENT, MSSQLSERVER, Veeam, wscsvc (Windows Security Center) e i servizi dell'endpoint protection in uso.

Per ridurre i falsi positivi, il parametro discriminante è il processo padre. Un arresto eseguito da services.exe o da un task schedulato noto è fisiologico; lo stesso arresto innescato da cmd.exe con parent powershell.exe lanciato da wmiprvse.exe è una catena sospetta. Si consiglia di creare una whitelist di processi padre autorizzati e di generare alert per qualsiasi eccezione.

Su Linux (AN0062), auditd è la fonte primaria. Le regole audit dovrebbero monitorare le invocazioni di systemctl stop e service stop con particolare attenzione all'utente esecutore e alla correlazione temporale con operazioni di cancellazione file su /var/lib/mysql o altre directory dati.

Su ESXi (AN0064), i log di hostd registrano ogni operazione sulle VM. Un alert efficace correla il comando esxcli vm process kill con l'utente che lo esegue e con eventuali accessi successivi al datastore. L'assenza di agenti EDR nativi su ESXi rende questa log source particolarmente preziosa.

Come controllo preventivo, la segmentazione di rete (M1030) isola i sistemi di backup e monitoring su segmenti separati, complicando l'arresto remoto. La gestione degli account (M1018) limita i privilegi necessari per interagire con il Service Control Manager, riducendo la superficie d'attacco.

L'analisi forense dell'arresto servizi si concentra sulla ricostruzione della sequenza temporale tra l'interruzione e l'azione distruttiva che la segue. Gli artefatti sono abbondanti su Windows, meno strutturati su Linux e ESXi, ma in tutti i casi la chiave è correlare il momento esatto dello stop con le operazioni successive sui data store.

Su Windows, il punto di partenza è il log System: l'EventCode 7036 indica il cambio di stato con timestamp preciso al secondo. Per ogni servizio fermato, il record contiene il nome del servizio e il nuovo stato. L'EventCode 7040 nel medesimo log registra il cambio di tipo di avvio — da automatico a disabilitato — che è l'artefatto chiave per distinguere un arresto temporaneo da una disabilitazione permanente come quella eseguita da Olympic Destroyer via ChangeServiceConfigW.

La telemetria Sysmon aggiunge profondità critica. L'EventID 1 cattura la command line completa — fondamentale per distinguere un net stop MSSQLSERVER manuale da una catena automatizzata con decine di servizi in lista. L'EventID 13 traccia le modifiche dirette alle chiavi di registro sotto HKLM\SYSTEM\CurrentControlSet\Services, dove Industroyer scrive zeri per rendere i servizi permanentemente inutilizzabili.

I file Prefetch sono un secondo livello di conferma. L'esecuzione di net.exe, sc.exe o taskkill.exe genera file .pf in C:\Windows\Prefetch con timestamp di ultima esecuzione e conteggio delle esecuzioni. Se NET.EXE-xxxxxxxx.pf mostra 30 esecuzioni in un giorno normalmente privo di attività amministrativa, è un indicatore forte.

Per ricostruire la catena di processo, gli artefatti EVTX di Sysmon e gli Event ID 4688 (Process Creation con audit abilitato) del Security log forniscono la gerarchia processo padre–figlio. Nei casi documentati, pattern ricorrenti includono: explorer.exe → cmd.exe → net.exe (esecuzione manuale), oppure services.exe → malware.exe → cmd.exe → net stop (esecuzione automatizzata da malware installato come servizio).

Su Linux, il file /var/log/syslog o /var/log/messages registra gli eventi systemd di arresto servizio. I log di auditd, se configurati con regole per le syscall kill e execve, catturano l'utente, il PID e la command line completa. La correlazione temporale con accessi al filesystem tramite i record SYSCALL e PATH di auditd permette di collegare l'arresto del servizio MySQL con la successiva manipolazione dei file in /var/lib/mysql.

Su ESXi, il file hostd.log è la fonte primaria. Ogni operazione vim-cmd o esxcli viene registrata con utente e timestamp. I file di log delle singole VM (vmware.log nella directory della VM) registrano l'evento di spegnimento forzato, distinguendolo da uno shutdown ordinato.

La timeline finale dovrebbe evidenziare tre fasi: arresto servizi (T1489), manipolazione dati (T1485 o T1486), ed eventuale lateral movement precedente che ha portato l'attaccante sul sistema bersaglio.

La tecnica T1489 è un punto di convergenza tra operazioni ransomware a scopo finanziario e sabotaggio sponsorizzato da stati nazionali. I sei gruppi documentati disegnano una mappa chiara di motivazioni, target e modalità operative.

Sandworm Team rappresenta il polo del sabotaggio statale. Il gruppo, noto per operazioni distruttive, utilizza l'arresto del servizio MSSQL come passaggio preparatorio alla cifratura dei file bloccati. Il pattern è coerente con l'uso di wiper travestiti da ransomware: l'obiettivo non è l'estorsione ma la distruzione operativa. Il software Prestige, che esegue esplicitamente net.exe stop MSSQLSERVER, e HermeticWiper, che ferma il Volume Shadow Copy per impedire il ripristino, rientrano nello stesso ecosistema operativo. Anche Olympic Destroyer e Industroyer operano in questa logica distruttiva, con quest'ultimo che scrive zeri nelle chiavi di registro dei servizi per renderli permanentemente inutilizzabili.

Wizard Spider e Indrik Spider incarnano il modello ransomware maturo. Wizard Spider, operatore di Ryuk e Conti, utilizza taskkill.exe e net.exe per eliminare sistematicamente servizi di backup, database e sicurezza prima della cifratura. La scala è impressionante: Conti arresta fino a 146 servizi con un'unica routine. Indrik Spider adotta un approccio più chirurgico, usando PsExec per fermare servizi da remoto su specifici endpoint prima di distribuire il payload.

Lazarus Group si colloca a metà strada tra sabotaggio e criminalità finanziaria. L'arresto di MSExchangeIS è un'operazione mirata a massimizzare il danno organizzativo rendendo inaccessibile la posta elettronica, coerente con le operazioni distruttive del gruppo contro infrastrutture critiche.

LAPSUS$ introduce una variante infrastrutturale interessante: lo spegnimento delle macchine virtuali dall'interno dell'infrastruttura VMware ESXi della vittima. Questo approccio, condiviso con famiglie ransomware come Cheerscrypt, BlackCat e Akira _v2, riflette la crescente importanza degli ambienti virtualizzati come target primario.

Medusa Group completa il quadro con un profilo ransomware classico, terminando servizi di backup, sicurezza, database, comunicazione e file sharing — un pattern identico a quello del Medusa Ransomware documentato tra i software.

Il dato più significativo per la threat intelligence è la convergenza dei tool: net.exe, sc.exe, taskkill.exe e le API del Service Control Manager sono utilizzati trasversalmente da tutti i gruppi. L'overlap nei servizi target è altrettanto marcato: Exchange, SQL Server, Veeam e le soluzioni antivirus compaiono in quasi tutti i profili. Per le organizzazioni che gestiscono infrastrutture ESXi, il trend è chiaro: la catena accesso SSH → esxcli vm process kill → cifratura vmdk è ormai un playbook consolidato. Monitorare l'accesso amministrativo agli hypervisor è una priorità immediata.

Framework MITRE ATT&CK v16 — Tecnica T1489 (Service Stop), Tattica TA0040 (Impact). Mitigazioni M1030, M1018, M1060, M1024, M1022. Detection DET0021 con analitici AN0061, AN0062, AN0063, AN0064. Gruppi: G1051, G0032, G0034, G1004, G0102, G0119. Integrato con conoscenza professionale per tool e procedure operative.