Spegnimento e Riavvio: System Shutdown/Reboot (T1529)

In un esercizio red team la simulazione di T1529 va contestualizzata nella fase finale della kill chain, tipicamente dopo aver acquisito privilegi amministrativi e completato le azioni di impact simulato. L'obiettivo non è provocare downtime reale in produzione, ma dimostrare la capacità di innescare la sequenza in un ambiente lab controllato.

Su Windows il comando base è shutdown /r /t 1 per un reboot immediato, replicando esattamente il comportamento osservato in APT37 e in numerosi wiper. Varianti utili includono shutdown /s /f /t 0 per forzare lo spegnimento chiudendo le applicazioni senza prompt, e shutdown /r /m \\target /t 0 per riavviare host remoti sfruttando credenziali già raccolte. Per emulare wiper come WhisperGate o BFG Agonizer si può scrivere un piccolo PoC in C che invochi ExitWindowsEx con il flag EWX_SHUTDOWN oppure NtRaiseHardError, ricordando che occorre abilitare SeShutdownPrivilege tramite AdjustTokenPrivileges. Strumenti come Impacket (open source) permettono di veicolare il comando via WMI o SMB con wmiexec.py o smbexec.py, catene tipiche di operazioni post-exploitation.

Su Linux i comandi shutdown -r now, reboot e systemctl poweroff coprono la maggior parte degli scenari. In ambienti containerizzati o ESXi il red team può testare esxcli system shutdown reboot -d 10 -r "test" oppure vim-cmd vmsvc/power.shutdown per replicare il pattern osservato in Medusa Group e nella variante Linux di AvosLocker contro macchine ESXi.

Per apparati di rete Cisco IOS il comando reload in 1 permette di pianificare un riavvio differito, utile per simulare scenari di Network Device CLI abuse. Su macOS osascript -e 'tell app "System Events" to shut down' o sudo shutdown -h now completano la matrice.

Come framework di orchestrazione, Atomic Red Team (open source) include test case specifici per T1529 in Windows e Linux, mentre Caldera (open source) di MITRE consente di innestare l'azione in playbook più ampi che simulano wiper come HermeticWiper o AcidRain. È fondamentale coordinare la finestra di test con il blue team e disporre di snapshot delle macchine target, perché la ripetibilità del test dipende dalla velocità di ripristino dell'ambiente.

La detection di T1529 è un esercizio di correlazione contestuale: il comando in sé è legittimo, ciò che lo rende sospetto è il chi, quando e cosa lo precede. La logica di allerta descritta in DET0559 parte proprio da questa premessa.

Su Windows le fonti primarie sono WinEventLog:Security e WinEventLog:Sysmon. Gli EventID chiave sono 1074 (shutdown iniziato da utente o processo, con dettaglio del motivo) e 6006 (Event Log service stopped, marker classico dello shutdown pulito). L'EventID 4688 con process command line, correlato agli eventi Sysmon 1, permette di identificare invocazioni di shutdown.exe, Restart-Computer o binari che caricano advapi32.dll per chiamare InitializeSystemShutdownExW. La regola di correlazione deve verificare che l'utente iniziatore appartenga a un gruppo autorizzato (Helpdesk, IT Ops) e che l'orario ricada in una finestra di manutenzione approvata. Un reboot innescato da un processo figlio di winword.exe o powershell.exe fuori orario è un indicatore ad alta priorità.

Su Linux auditd con regole sui syscall reboot() e kexec_load(), unite al monitoraggio di /var/log/wtmp e journal per esecuzioni di shutdown, reboot o systemctl poweroff, forniscono la visibilità necessaria. Una regola auditd tipica è -a always,exit -F arch=b64 -S reboot -k T1529_reboot. Il contesto utente (root diretto vs sudo) e la presenza di un ticket di change management sono i discriminanti.

Su macOS l'unified log raccoglie via log show --predicate 'process == "shutdown"' le invocazioni interattive e scriptate; distinguere tra shutdown avviato dalla GUI e uno lanciato via osascript o LaunchDaemon è la chiave.

Su ESXi i log hostd.log e shell.log registrano comandi come esxcli system shutdown e vim-cmd vmsvc/power.shutdown. L'assenza di un maintenance window valido, sommata a un account non pertinente al ruolo di virtualization admin, deve generare alert immediato — pattern esattamente osservato in Medusa Group e nella variante Linux di AvosLocker.

Sugli apparati di rete il comando reload Cisco IOS viene loggato via syslog e correlato con TACACS+/AAA per validare il livello di privilegio dell'operatore. I falsi positivi principali derivano da patch cycle non comunicati, riavvii automatici post-Windows Update e script di manutenzione notturni: l'integrazione con il sistema ITSM per correlare change ticket è indispensabile per ridurre il rumore. Uno shutdown preceduto entro pochi minuti da massive file writes, cancellazioni VSS o modifiche all'MBR è un signal ad altissima confidenza di attacco distruttivo in corso.

L'analisi forense di un evento T1529 parte quasi sempre in condizioni sfavorevoli: il sistema è spento, spesso non riavviabile, e l'analista lavora su immagini disco offline o su artefatti raccolti da endpoint peer. La ricostruzione della timeline è tuttavia possibile perché lo shutdown lascia tracce robuste.

Su Windows il registro eventi System.evtx contiene gli EventID 1074 (shutdown iniziato, con nome processo e ragione), 6006 (clean shutdown del logging service), 6008 (unexpected shutdown, tipico di reboot forzato via API o BSOD) e 41 del Kernel-Power (kernel error, spesso presente dopo NtRaiseHardError). Il file SYSTEM hive, chiave HKLM\SYSTEM\CurrentControlSet\Control\Windows, contiene il valore ShutdownTime aggiornato all'ultimo spegnimento pulito. L'Amcache.hve e le Prefetch di shutdown.exe confermano l'esecuzione del binario, mentre le ShimCache e UserAssist aiutano a datare la prima apparizione di eseguibili malevoli precedenti. Sysmon EventID 1 per shutdown.exe o processi che caricano advapi32.dll + ntdll.dll con chiamate a NtRaiseHardError sono indicatori forensi diretti dell'uso di API-based shutdown, pattern osservato in WhisperGate e BFG Agonizer.

Su Linux i file /var/log/wtmp (leggibile con last -x), /var/log/btmp, syslog e il journal systemd (journalctl -b -1) forniscono la sequenza degli ultimi boot. La presenza di record shutdown o reboot in wtmp senza corrispondente entry di manutenzione, e l'assenza di processi di logging graceful prima dell'evento, indicano azione ostile. Il file /var/log/auth.log correla l'utente sudo che ha invocato il comando.

Su ESXi hostd.log, vmkernel.log e shell.log in /var/log/ registrano l'operazione e l'utente. La correlazione tra shutdown VM e file .vmdk cifrati o cancellati poco prima è tipica delle operazioni Medusa Group e AvosLocker Linux.

La timeline va costruita mettendo in relazione: modifica MBR (settore 0 del disco, verificabile con dd if=/dev/sdX bs=512 count=1 | xxd), creazione di file eseguibili sospetti nelle ore precedenti, esecuzione del wiper, shutdown/reboot finale, tentativo di boot fallito. Campagne come Shamoon, NotPetya, HermeticWiper, AcidRain e AcidPour seguono tutte questo schema. In presenza di NotPetya il ritardo caratteristico di un'ora tra infezione e reboot è un marker temporale utile per identificare la finestra di compromissione iniziale. Strumenti come Volatility 3 (open source), Autopsy (open source) e KAPE (gratuito per uso non commerciale) coprono la raccolta e l'analisi degli artefatti citati.

Il panorama degli attori che sfruttano T1529 è dominato da operazioni distruttive con finalità geopolitica e da ransomware con focus sulla massimizzazione del danno. Quattro gruppi APT sono censiti nei dati MITRE.

Lazarus Group (G0032), attribuito alla Corea del Nord, integra il reboot come step finale dopo la distruzione dei file e il wiping dell'MBR. Il pattern è coerente con operazioni storiche del gruppo contro settore finanziario ed entertainment, dove l'obiettivo dichiarato include la disruption dell'operatività della vittima oltre al furto di fondi. APT37 (G0067), anch'esso nordcoreano ma con focus prevalente su Corea del Sud e dissidenti, impiega malware che invoca shutdown /r /t 1 dopo aver corrotto l'MBR — un pattern operativo semplice ma efficace nel massimizzare il tempo di irreversibilità dell'attacco. APT38 (G0082), cluster nordcoreano orientato a operazioni bancarie, utilizza il wiper custom BOOTWRECK che innesca il reboot dopo la distruzione dell'MBR, tipicamente per coprire le tracce di rapine SWIFT già consumate.

Medusa Group (G1051) rappresenta il vettore ransomware moderno: spegnimento manuale e cifratura di macchine virtuali, con particolare attenzione agli hypervisor. Il pattern converge con la variante Linux di AvosLocker, che termina esplicitamente le VM ESXi, e con Maze, che emette il comando di shutdown per far ripartire la macchina eseguendo il ransomware all'interno di una VM — tecnica di evasion sofisticata.

L'overlap tra famiglie di malware racconta una storia interessante. I wiper puri — Shamoon, NotPetya, HermeticWiper, AcidRain, AcidPour, MultiLayer Wiper, Apostle, WhisperGate, KillDisk, BFG Agonizer — condividono tutti la sequenza wipe-then-reboot, differenziandosi per il meccanismo tecnico: alcuni usano shutdown.exe, altri API dirette come ExitWindowsEx o NtRaiseHardError. La convergenza tra NotPetya (attribuito a Sandworm) e HermeticWiper (utilizzato in operazioni contro l'Ucraina) suggerisce una linea evolutiva di TTP nel toolkit distruttivo russo, anche se i dati MITRE forniti qui non attribuiscono direttamente queste famiglie a gruppi specifici.

Sul fronte ransomware Black Basta, LockerGoga, Maze, DCSrv, AvosLocker, ShrinkLocker e Qilin integrano tutti funzionalità di shutdown/reboot come parte della strategia di lockout della vittima. Qilin in particolare mira ai server di backup, comportamento coerente con la tendenza degli operatori ransomware a colpire l'infrastruttura di recovery prima della richiesta di riscatto. DarkGate, Latrodectus, CHIMNEYSWEEP e XLoader confermano che anche loader e infostealer stanno integrando primitive di shutdown, probabilmente come funzione di anti-forensics o come modulo distruttivo opzionale attivabile su richiesta dell'operatore.

MITRE ATT&CK T1529 (System Shutdown/Reboot), tattica TA0040 (Impact). Detection strategy DET0559 con analytics AN1538-AN1542 per Windows, Linux, macOS, ESXi e Network Devices. Gruppi G0032, G0067, G0082, G1051 e software S0140, S0365, S0368, S0372, S0449, S0582, S0607, S0689, S0697, S1033, S1053, S1070, S1111, S1125, S1133, S1135, S1136, S1149, S1160, S1167, S1178, S1207, S1242. Integrata conoscenza professionale su tool forensi (Volatility, Autopsy, KAPE), framework red team (Atomic Red Team, Caldera, Impacket) e sintassi comandi nativi OS.