Persistenza via Winlogon: Winlogon Helper DLL (T1547.004)

La simulazione di questa tecnica in laboratorio è relativamente semplice e non richiede tool esotici — bastano i comandi nativi di Windows e un minimo di attenzione alle chiavi corrette. L'obiettivo è dimostrare al cliente che una singola modifica al registro può garantire persistenza silenziosa a ogni login.

Scenario 1 — Abuso della sottochiave Shell (livello utente)

Il valore predefinito di Shell è explorer.exe. Per aggiungere un payload mantenendo la shell legittima funzionante, si concatena il percorso del malware con una virgola, esattamente come documentato per Gazer e Revenge RAT:

reg add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell /d "explorer.exe, C:\Temp\payload.exe" /f

Questo comando non rompe il desktop dell'utente — explorer parte normalmente — ma al prossimo logon verrà lanciato anche il payload. La variante HKCU non richiede privilegi elevati, il che la rende perfetta per simulare uno scenario di post-exploitation con utente standard.

Scenario 2 — Abuso di Userinit (livello macchina)

Il valore predefinito di Userinit punta a C:\Windows\System32\userinit.exe. Per replicare la tecnica usata da Wizard Spider e Remexi:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Userinit /d "C:\Windows\System32\userinit.exe, C:\Temp\implant.exe" /f

Questo richiede un prompt amministrativo. Al successivo logon di qualsiasi utente, userinit.exe eseguirà prima la propria inizializzazione e poi il binario aggiunto.

Scenario 3 — Notify DLL (tecnica legacy ma ancora funzionale)

La sottochiave Notify carica DLL di notifica. Si può registrare una DLL personalizzata creando una sottochiave dedicata:

reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\TestPkg" /v DLLName /d "C:\Temp\notify_test.dll" /f

Per validare che il meccanismo funzioni senza eseguire codice malevolo, si può utilizzare una DLL compilata con un semplice DllMain che scrive un file di log. Questo approccio replica quanto documentato per Dipsind.

Autoruns (a pagamento come parte della suite Sysinternals, ma distribuito gratuitamente da Microsoft) è lo strumento ideale per verificare se la persistenza è stata scritta correttamente: lanciando autorunsc.exe -m -c -nobanner si ottiene un output CSV filtrato che include le entry Winlogon, utile anche per confrontare snapshot pre e post-attacco.

Per il framework di simulazione, Atomic Red Team (open source) offre test pronti per T1547.004 che automatizzano l'intero ciclo di scrittura e pulizia delle chiavi.

La detection di questa tecnica si appoggia su un principio chiaro: i valori legittimi di Shell, Userinit e Notify cambiano raramente in un ambiente di produzione. Qualsiasi modifica a queste chiavi è, quasi per definizione, un evento ad alta priorità che merita investigazione immediata.

La fonte primaria di telemetria è Sysmon (open source), configurato per catturare eventi di modifica al registro. L'EventCode 13 (RegistryEvent — Value Set) è il cuore della detection: filtrando per TargetObject che contiene il percorso \CurrentVersion\Winlogon\ si intercettano tutte le varianti della tecnica in un unico filtro. La configurazione Sysmon va strutturata con un blocco <RegistryEvent onmatch="include"> che catturi esplicitamente i pattern Shell, Userinit e Notify.

Il secondo livello di visibilità arriva dal Security Event Log nativo. L'EventCode 4657 (audit di modifica a oggetti del registro) si attiva solo se è stata configurata una SACL (System Access Control List) sulle chiavi Winlogon. La configurazione richiede due passaggi: abilitare la policy "Audit Registry" tramite GPO e poi applicare l'auditing sulle chiavi specifiche tramite regedit o script PowerShell.

Per la correlazione comportamentale, la logica di detection suggerita nei dati è efficace: correlare la modifica al registro con il successivo caricamento di moduli (EventCode 7 di Sysmon, ImageLoaded) da parte di winlogon.exe o userinit.exe. Se una DLL non firmata viene caricata da winlogon.exe da una directory diversa da System32, la confidenza dell'alert sale drasticamente.

I parametri di tuning fondamentali sono quattro:

• TimeWindow: correlare la modifica registry con il caricamento DLL entro una finestra temporale ragionevole (tipicamente il prossimo ciclo di logon)
• UserContext: una modifica HKLM da un utente non-admin è anomala per definizione; una modifica HKCU è meno sospetta ma va comunque indagata
• BinarySignatureValidation: verificare la firma digitale delle DLL caricate tramite Winlogon helper — i binari non firmati o con firma non attendibile sono quasi sempre malevoli
• ExecutablePathScope: DLL provenienti da %TEMP%, %APPDATA% o directory utente sono altamente sospette

I falsi positivi principali derivano da software di gestione remota o agent di sicurezza che registrano legittimamente DLL Notify. Una whitelist basata su hash e percorso del file riduce efficacemente il rumore. Strumenti come OSQuery (open source) permettono di eseguire query periodiche sullo stato delle chiavi Winlogon tramite la tabella registry, creando una baseline comparabile nel tempo.

L'analisi forense di un abuso Winlogon parte dal registro e si espande radialmente verso filesystem e log eventi. Il vantaggio per l'analista è che questa tecnica lascia tracce robuste, difficili da cancellare completamente.

Il primo artefatto da estrarre è il contenuto attuale delle chiavi di registro. Con RegRipper (open source) si possono processare gli hive NTUSER.DAT (per HKCU) e SOFTWARE (per HKLM) offline, estraendo i valori Winlogon con i relativi timestamp di ultima modifica. Il timestamp LastWriteTime della chiave è fondamentale per la timeline: rappresenta il momento esatto in cui il valore è stato alterato. Analizzando l'hive SOFTWARE con il plugin winlogon di RegRipper si ottiene una vista completa delle entry Shell, Userinit e Notify.

Il secondo livello riguarda il filesystem. Una volta identificato il percorso della DLL o dell'eseguibile malevolo dalla chiave di registro, si procede con l'acquisizione del binario. I timestamp MACB (Modified, Accessed, Created, Birth) del file vanno correlati con il timestamp di modifica della chiave. Se il file è stato scritto pochi secondi prima della modifica al registro, la correlazione temporale è forte — un pattern coerente con l'automazione tipica dei malware come DarkTortilla o Bazar che configurano la persistenza Winlogon come parte della catena di installazione.

L'analisi degli Shimcache e Amcache fornisce ulteriore contesto. Se il binario malevolo è stato eseguito — anche solo una volta — il suo percorso comparirà nell'Amcache (Amcache.hve, analizzabile con AmcacheParser di Eric Zimmerman, open source). Lo Shimcache (nel registro SYSTEM, chiave AppCompatCache) registra l'esistenza del file anche se non è stato eseguito direttamente, il che aiuta a stabilire quando il binario è apparso per la prima volta nel sistema.

Per i log eventi, gli EventCode 13 di Sysmon — se era installato al momento dell'intrusione — offrono la prova più diretta. In assenza di Sysmon, i Security EventCode 4657 rappresentano l'alternativa, purché l'auditing fosse configurato. In entrambi i casi, l'evento registra l'account che ha eseguito la modifica, il processo responsabile e il valore precedente della chiave.

Un aspetto spesso trascurato è la verifica delle DLL di notifica: il sottoalbero Winlogon\Notify può contenere sottochiavi multiple, ciascuna con un valore DLLName. L'analista dovrebbe enumerare tutte le sottochiavi e confrontare ogni DLL referenziata con hash noti tramite servizi come VirusTotal (freemium). La tecnica usata da Dipsind sfrutta proprio questo meccanismo, registrandosi come Event Notify DLL in modo discreto.

I tre gruppi che utilizzano questa tecnica rappresentano profili operativi molto diversi, il che dimostra la trasversalità dell'abuso Winlogon come meccanismo di persistenza.

Wizard Spider è un gruppo con motivazione finanziaria, noto per operazioni ransomware su larga scala. Il suo utilizzo della sottochiave Userinit tramite la chiave HKLM indica un approccio che presuppone già privilegi amministrativi — coerente con la fase post-exploitation delle sue campagne, dove l'accesso elevato è già stato ottenuto. Il software Bazar, collegato all'ecosistema Wizard Spider, conferma l'uso di Winlogon Helper DLL come meccanismo di persistenza, creando una catena coerente: Bazar ottiene l'accesso iniziale, stabilisce persistenza Winlogon e prepara il terreno per il payload ransomware finale. Nella stessa orbita si colloca LockBit 3.0, che utilizza la chiave Winlogon per abilitare l'autologon — una variante funzionale che non mira alla persistenza classica ma all'automazione del login per facilitare l'esecuzione del ransomware senza interazione.

Turla rappresenta il polo opposto: un gruppo di spionaggio con attribuzione statale e operazioni a lungo termine. Il suo utilizzo della sottochiave Shell in HKCU, replicato dal software Gazer, suggerisce un approccio più cauto — la modifica a livello utente non richiede privilegi elevati e risulta meno visibile rispetto alle modifiche HKLM. Questa scelta operativa è coerente con l'esigenza di mantenere un profilo basso su reti target di alto valore.

Tropic Trooper adotta un approccio simile a Turla, creando la chiave Shell in HKCU. La sovrapposizione nella scelta della sottochiave tra questi due gruppi — pur con obiettivi geopolitici diversi — suggerisce che la variante HKCU/Shell è considerata il metodo più discreto nell'ecosistema Winlogon.

Dal punto di vista del software, la distribuzione è significativa. I 10 malware documentati coprono uno spettro ampio: dal ransomware (LockBit 3.0, Qilin) ai RAT (Revenge RAT, Remexi, KeyBoy), passando per loader generici (DarkTortilla, Cannon) e backdoor sofisticate (Gazer, Dipsind). Questo indica che la tecnica non è appannaggio di una singola categoria di threat actor, ma è adottata trasversalmente perché offre un rapporto costo-beneficio eccellente: implementazione banale, alta resilienza ai riavvii, bassa probabilità di detection in ambienti senza monitoraggio del registro.

Un pattern predittivo emerge chiaramente: gli attori finanziariamente motivati tendono a modificare HKLM (impatto su tutti gli utenti, utile per ransomware), mentre gli attori di spionaggio preferiscono HKCU (impatto limitato, profilo basso). Questa distinzione può informare il triage degli alert: una modifica HKLM\Winlogon suggerisce una fase avanzata di un attacco distruttivo, mentre una modifica HKCU\Winlogon orienta verso un'intrusione a scopo di raccolta intelligence.

Framework MITRE ATT&CK v16 — Tecnica T1547.004, Tattiche TA0003, TA0004. Mitigazioni M1038, M1018. Detection DET0404, AN1133. Gruppi G0102, G0081, G0010. Software S0168, S1242, S1066, S0200, S0534, S0375, S0379, S1202, S0387, S0351. Integrato con conoscenza professionale per tool e procedure operative.