Manipolazione Alimentazione: Power Settings (T1653)

In un contesto di red team autorizzato, la simulazione di T1653 si costruisce attorno a utility native del sistema operativo, evitando binari di terze parti che genererebbero alert immediati sugli EDR.

Su Windows il tool cardine è powercfg.exe, presente in ogni installazione. Per elencare gli schemi energetici disponibili si usa powercfg /list, mentre powercfg /query restituisce la configurazione dello schema attivo. Per impedire la sospensione automatica su alimentazione AC il comando è powercfg /change standby-timeout-ac 0, che imposta il timeout a zero (mai). Analogamente powercfg /change hibernate-timeout-ac 0 disabilita l'ibernazione temporizzata, e powercfg /hibernate off rimuove del tutto la funzionalità cancellando anche hiberfil.sys. Il timeout del blocco schermo si estende via registro modificando HKLM\SOFTWARE\Policies\Microsoft\Windows\Control Panel\Desktop.

Una catena realistica prevede: escalation a SYSTEM tramite tecnica separata, esecuzione dei comandi powercfg per congelare gli stati energetici, e successiva installazione del payload di persistenza. In un lab con Atomic Red Team (open source) esistono test specifici per T1653 che automatizzano queste modifiche in modo tracciabile.

Su Linux la simulazione ruota attorno a systemd. Il comando systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target rende impossibili le transizioni verso stati a basso consumo. In alternativa systemd-inhibit --what=sleep:shutdown --who=maintenance --why=test sleep infinity crea un blocco esplicito. La modifica di /etc/systemd/sleep.conf con direttive AllowSuspend=no e AllowHibernation=no produce un effetto persistente attraverso i reboot.

Su macOS pmset è l'equivalente di powercfg. sudo pmset -a sleep 0, sudo pmset -a disksleep 0 e sudo pmset -a displaysleep 0 neutralizzano tutti i timer di risparmio energetico. Il flag -a applica la configurazione a tutte le sorgenti di alimentazione.

Per la componente di crash dump evasion ispirata a Line Dancer, un red team può simulare la disabilitazione del kernel dump su Windows via registro (HKLM\SYSTEM\CurrentControlSet\Control\CrashControl con CrashDumpEnabled=0) documentando l'operazione. Su appliance di rete Cisco l'equivalente richiede accesso privilegiato al sistema operativo sottostante e non è replicabile in lab standard.

Durante l'esercizio è essenziale documentare lo stato iniziale con powercfg /query > baseline.txt per ripristinare la configurazione originale a fine test, evitando impatti operativi sulla macchina target.

La detection di T1653 si fonda sulla telemetria di process creation e sulla correlazione con modifiche di registro o file di configurazione. Come indicato dalla strategia DET0417, il segnale primario su Windows è l'esecuzione di powercfg.exe con argomenti che alterano timeout di standby, ibernazione o display.

La fonte principale è WinEventLog:Security con EventCode 4688 (process creation) e Sysmon (open source) Event ID 1, filtrando su Image terminante in powercfg.exe e CommandLine contenente stringhe come standby-timeout, hibernate-timeout, /change, /hibernate off. Una singola invocazione può essere legittima — un amministratore che tunizza un laptop — ma modifiche ripetute o eseguite da processi non interattivi (parent process cmd.exe spawnato da services.exe o da un binario in %TEMP%) alzano immediatamente il punteggio di rischio.

La correlazione utile secondo AN1174 lega l'esecuzione di powercfg.exe a successive modifiche di registro sotto HKLM\SYSTEM\CurrentControlSet\Control\Power o HKCU\Control Panel\Desktop (chiave ScreenSaveTimeOut). Sysmon Event ID 13 (registry value set) fornisce questa visibilità. Una finestra di correlazione di 60-120 secondi tra process creation e registry write è un buon punto di partenza.

Su Linux la telemetria arriva da auditd con regole SYSCALL e PATH mirate a intercettare esecuzioni di systemctl mask, systemd-inhibit, e scritture su /etc/systemd/sleep.conf e /etc/systemd/logind.conf. Una regola tipica traccia -w /etc/systemd/sleep.conf -p wa -k power_config. L'esecuzione di systemd-inhibit con lock di lunga durata è particolarmente indicativa quando il processo chiamante non è un desktop environment noto.

Su macOS il log unificato (macos:unifiedlog) intercetta invocazioni di pmset. Modifiche a /Library/Preferences/SystemConfiguration/com.apple.PowerManagement.plist fuori dai flussi MDM aziendali meritano indagine, così come qualunque uso di pmset -a da parte di processi non firmati Apple.

I falsi positivi più comuni derivano da script di gestione IT, GPO di dominio che ridistribuiscono policy energetiche, tool di monitoraggio come agenti RMM che riconfigurano il risparmio energetico su endpoint sempre-attivi. La tuning strategy suggerita in DET0417 prevede whitelist di script amministrativi noti e finestre di manutenzione conosciute. Utile mantenere una baseline per host: se una workstation utente vede improvvisamente hibernate-timeout impostato a zero mentre la GPO prevede 30 minuti, la deviazione è di per sé un indicatore. Alert compositi che combinano modifica power settings + connessione outbound persistente + processo non firmato producono i migliori risultati con basso rumore.

L'analisi forense di T1653 richiede la ricostruzione dello stato energetico del sistema al momento della compromissione e delle modifiche introdotte dall'attaccante. Gli artefatti differiscono per piattaforma ma la logica investigativa è comune: identificare il momento del cambio configurazione, associarlo a un processo, correlare con altri indicatori.

Su Windows la fonte primaria è il registro di sistema. La chiave HKLM\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes conserva gli schemi energetici e i loro parametri. I timestamp LastWrite delle sottochiavi indicano quando è avvenuta l'ultima modifica. Utilizzando RegRipper (open source) o Registry Explorer di Eric Zimmerman (gratuito) si estrae la timeline delle modifiche. La presenza o assenza di C:\hiberfil.sys indica se l'ibernazione è stata disabilitata: la sua rimozione recente è visibile via MFT analizzata con MFTECmd (gratuito) cercando record con flag di eliminazione e timestamp coerenti.

Il Security Event Log (Security.evtx) contiene EventID 4688 con la command line di powercfg.exe, purché sia stato abilitato Include command line in process creation events via GPO. Il System Event Log registra transizioni di stato energetico (EventID 1, 42, 107 del provider Kernel-Power): un'improvvisa scomparsa di questi eventi in una macchina che storicamente entrava in sleep è di per sé un indicatore. Prefetch (C:\Windows\Prefetch\POWERCFG.EXE-.pf*) conferma esecuzioni recenti con conteggio e ultimi run.

Su Linux gli artefatti chiave sono i file sotto /etc/systemd/, in particolare sleep.conf, logind.conf e i symlink in /etc/systemd/system/ che indicano unit masked verso /dev/null — segnale distintivo di systemctl mask applicato a sleep.target. I timestamp ctime e mtime ottenuti via stat forniscono la timeline. I log journalctl con filtro _COMM=systemctl mostrano chi ha eseguito i comandi. Le regole auditd, se attive, offrono la ricostruzione completa syscall-per-syscall.

Su macOS il file com.apple.PowerManagement.plist è l'artefatto di riferimento; plutil -p ne consente la lettura. Il log unificato conserva le invocazioni di pmset.

Un caso emblematico è ArcaneDoor (C0046, luglio 2023 - aprile 2024) contro appliance Cisco ASA. L'exploitation di CVE-2024-20353 ha forzato il reboot dei dispositivi vittima, innescando l'estrazione automatica e l'esecuzione di Line Runner (S1188). Parallelamente, Line Dancer (S1186) modificava il processo di crash dump per saltare la generazione del dump stesso, procedendo direttamente al reboot: una tattica anti-forense che ha ostacolato la raccolta di memoria volatile durante l'incident response. In casi analoghi la memory acquisition va tentata prima di qualunque reboot indotto, e le configurazioni di crash control vanno confrontate con la baseline vendor.

Il quadro di threat intelligence su T1653 è dominato da un singolo caso operativo di alto profilo che merita analisi approfondita, poiché rappresenta un uso sofisticato e mirato della manipolazione degli stati energetici e di reboot come componente di una catena di attacco più ampia.

La campagna ArcaneDoor (C0046), attiva tra luglio 2023 e aprile 2024, ha preso di mira dispositivi di rete Cisco e di altri vendor, con focus su reti governative e infrastrutture critiche. L'attribuzione punta al gruppo tracciato come UAT4356 (denominazione Cisco Talos) o STORM-1849 (denominazione Microsoft), valutato come attore state-sponsored. Il profilo operativo — targeting geopolitico selettivo, sviluppo di impianti custom per appliance di rete, uso di zero-day — è coerente con capacità di intelligence sponsorizzate da uno stato-nazione.

Gli operatori hanno impiegato due impianti custom che sfruttano T1653 in modi complementari. Line Runner (S1188) ha utilizzato CVE-2024-20353 per innescare il reboot del dispositivo vittima; durante il processo di riavvio il payload veniva estratto da un archivio e installato in modo persistente. Line Dancer (S1186) operava invece a valle, modificando il processo di crash dump dell'appliance per saltare la generazione del dump e procedere direttamente al reboot. Questa manipolazione serviva un duplice scopo: garantire persistenza attraverso il ciclo di riavvio e neutralizzare la principale fonte di evidenza forense disponibile su questi dispositivi.

Il pattern è tecnicamente notevole per almeno tre ragioni. Primo, l'obiettivo — appliance di rete di frontiera — indica una scelta strategica: questi dispositivi sono spesso sprovvisti di EDR, ricevono aggiornamenti poco frequenti e sono difficili da analizzare forensicamente. Secondo, l'uso combinato di reboot indotto (per attivare persistenza) e crash dump suppression (per prevenire forensics) mostra maturità nella pianificazione anti-IR. Terzo, la scelta di uno zero-day per il trigger di reboot suggerisce disponibilità di ricerca offensiva significativa.

Sul piano dei trend, la manipolazione delle impostazioni energetiche e dei meccanismi di reboot si sta spostando dagli endpoint tradizionali verso dispositivi embedded, network gear e sistemi OT dove le contromisure di detection sono meno mature. Per organizzazioni con superficie di attacco che include appliance di rete perimetrali, la lezione ArcaneDoor è chiara: monitoraggio dei reboot inattesi, verifica dell'integrità dei processi di crash dump, confronto periodico delle configurazioni con baseline vendor. L'applicazione della mitigazione M1047 (Audit) in forma di ispezione periodica delle impostazioni energetiche e dei parametri di crash control è un controllo di basso costo con alto valore contro questa classe di minacce.

MITRE ATT&CK: T1653 (Power Settings), tattica TA0003. Software: S1186 (Line Dancer), S1188 (Line Runner). Campagna: C0046 (ArcaneDoor), CVE-2024-20353. Mitigazione: M1047 (Audit). Detection: DET0417 con analytics AN1174 (Windows), AN1175 (Linux), AN1176 (macOS). MITRE D3FEND per artefatti difensivi correlati. Il documento integra conoscenza professionale di cybersecurity per comandi operativi (powercfg, systemctl, pmset), artefatti forensi (registro Windows, systemd unit files, plist macOS) e tool di analisi (RegRipper, MFTECmd, Registry Explorer, Atomic Red Team).