Driver LSASS Malevoli: LSASS Driver (T1547.008)

In un ingaggio red team con privilegi amministrativi già ottenuti sull'endpoint, la simulazione di T1547.008 parte dalla mappatura dei punti d'estensione di LSASS. Le chiavi di registro chiave da ispezionare sono HKLM\SYSTEM\CurrentControlSet\Control\Lsa con i valori Authentication Packages, Notification Packages e Security Packages, oltre alla sottochiave OSConfig. Un semplice controllo con reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa mostra i pacchetti attualmente registrati.

La tecnica documentata da Wingbird consiste nel droppare una DLL malevola (nell'esempio storico sspisrv.dll) accanto a una copia di lsass.exe, registrando un servizio che carica la libreria come driver. Il payload risiede nella funzione di entry-point della DLL e viene eseguito prima che il servizio spoofato collassi. Per replicare il pattern in laboratorio si può utilizzare una DLL compilata ad hoc con una DllMain che scriva un marker su disco, registrarla come Security Support Provider aggiungendo il nome (senza estensione) al valore Security Packages e riavviare la macchina di test.

Strumenti utili in fase di simulazione:

• Atomic Red Team (open source) contiene test dedicati a T1547.008 con payload dimostrativi già pronti
• PowerSploit (open source, archiviato ma funzionante) offre moduli per manipolare chiavi di registro sensibili
• Mimikatz (open source) implementa il modulo misc::memssp che inietta un Security Support Provider in memoria per catturare credenziali di logon senza persistenza su disco
• SharpSSDP e utility custom in C# per interagire con le API di LSA

Il comando emblematico in Mimikatz è privilege::debug seguito da misc::memssp, che aggiunge un provider in-memory e scrive le credenziali intercettate in C:\Windows\System32\mimilsa.log. Va notato che questa variante è volatile e non persiste al reboot, ma dimostra il concetto senza modificare il registro.

Per la variante persistente stile Wingbird, il workflow lab è: compilazione della DLL non firmata, copia in System32, aggiunta al valore Security Packages tramite reg add, reboot controllato e verifica del caricamento tramite Process Explorer (gratuito, Sysinternals) filtrando sui moduli di lsass.exe. In un ambiente con RunAsPPL attivo il caricamento fallisce, ed è proprio questo il controllo che l'esercizio deve validare per il cliente. Documentare sempre nel report il fingerprint della DLL, gli hash SHA256 e i tempi esatti di caricamento per facilitare la successiva bonifica.

La detection di T1547.008 ruota attorno a tre segnali complementari: modifiche alle chiavi di registro che governano i pacchetti LSA, caricamento di DLL non firmate o firmate da publisher inattesi nel contesto di lsass.exe, e creazione di file DLL immediatamente seguita dal loro caricamento nel processo di autenticazione. La regola AN0629 documentata in MITRE suggerisce di correlare questi eventi in una finestra temporale di circa 5 minuti attorno a eventi di boot o logon.

Le fonti di log essenziali sono Sysmon (open source, Microsoft) e il Windows Security Log. In Sysmon gli EventID rilevanti sono Event ID 7 per il caricamento di immagini (con filtro su Image=C:\Windows\System32\lsass.exe), Event ID 11 per la creazione di file DLL in percorsi sensibili, Event ID 12/13/14 per le modifiche alle chiavi di registro sotto HKLM\SYSTEM\CurrentControlSet\Control\Lsa e sottochiavi correlate. La configurazione consigliata è il template SwiftOnSecurity sysmon-config (open source), che include già filtri specifici per LSA.

Una query di caccia in KQL su Microsoft Defender for Endpoint (a pagamento) può filtrare DeviceImageLoadEvents dove InitiatingProcessFileName == "lsass.exe" e FolderPath esce dai percorsi noti, oppure la firma digitale risulta assente. Su Splunk o Elastic (freemium) la stessa logica si applica ai log Sysmon indicizzati, aggiungendo un lookup verso una allow-list di hash cripografici delle DLL LSA legittime.

Gli indicatori comportamentali da privilegiare:

• Scrittura sul valore Authentication Packages o Security Packages da parte di un processo diverso dagli installer di sicurezza Microsoft
• Caricamento in lsass.exe di una DLL creata sul filesystem meno di 5 minuti prima
• Presenza di DLL non firmate tra i moduli di LSASS visibile con listdlls.exe /v lsass.exe (Sysinternals, gratuito)
• Crash ricorrenti di lsass.exe seguiti da riavvii (pattern osservato nel comportamento di Wingbird)

I falsi positivi principali arrivano da soluzioni di autenticazione multifattore enterprise, agent di smart card e provider SSO che legittimamente aggiungono Security Packages. Una baseline preventiva del contenuto della chiave LSA per ogni immagine gold aziendale abbatte drasticamente il rumore. È utile inoltre monitorare l'attivazione o disattivazione di RunAsPPL: qualsiasi modifica al valore HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL deve generare alert ad alta priorità, perché rappresenta un tentativo esplicito di indebolire le difese prima dell'installazione del driver malevolo.

L'analisi forense di un compromesso via T1547.008 parte dalla ricostruzione della catena registro-filesystem-processo. Su un sistema live o su un'immagine acquisita, il primo passo è l'esame degli hive di registro: SYSTEM\CurrentControlSet\Control\Lsa va estratto con RegRipper (open source) o Registry Explorer di Eric Zimmerman (gratuito), verificando i valori Authentication Packages, Notification Packages, Security Packages e la sottochiave OSConfig. Ogni voce che non corrisponda ai package standard di Windows (msv1_0, kerberos, wdigest, tspkg, pku2u, cloudap, negoexts) è un candidato investigativo.

Per ogni DLL sospetta indicata nei valori LSA, si procede all'analisi del binario in C:\Windows\System32: hash SHA256 confrontato con VirusTotal (freemium), verifica della firma digitale con signtool verify /pa /v o con DIE (Detect It Easy) (open source), estrazione di stringhe e import table con PE-bear (open source). La timeline del filesystem tramite MFTECmd (gratuito) mostra il momento di creazione della DLL, spesso disallineato rispetto al resto delle librerie di sistema installate durante il setup iniziale.

Gli artefatti temporali chiave da correlare:

• Timestamp $SI e $FN nella MFT per la DLL sospetta
• Ultima scrittura della chiave LSA visibile nel campo LastWrite dell'hive
• Eventi 4688 (process creation) nel Security log che mostrano il processo padre responsabile della modifica del registro
• Eventi Sysmon ID 13 archiviati che documentano la scrittura del valore
• Prefetch di lsass.exe dopo il reboot successivo, analizzabile con PECmd (gratuito)

Per campagne documentate come Wingbird (S0176) l'artefatto distintivo è la presenza di una copia di lsass.exe al di fuori di System32 accompagnata dal file sspisrv.dll, con la registrazione di un servizio dedicato visibile in HKLM\SYSTEM\CurrentControlSet\Services. Il crash ricorrente del servizio spoofato lascia tracce in Application.evtx con EventID 1000 (Application Error) riferito a lsass.exe o al processo mascherato.

Per Pasam (S0208) l'artefatto centrale è l'infezione della SAM DLL, quindi la baseline crittografica di samsrv.dll e la sua verifica rispetto al catalogo Microsoft diventa dirimente. Un dump di memoria acquisito con WinPmem (open source) e analizzato con Volatility 3 (open source) tramite il plugin windows.dlllist filtrato su lsass permette di enumerare tutti i moduli caricati nel processo al momento dell'acquisizione, confrontandoli con la baseline. La preservazione del NTUSER.DAT dell'utente attaccante, dei log Microsoft-Windows-Sysmon/Operational e degli Amcache.hve (che tracciano l'esecuzione di binari) completa il set di evidenze necessarie per attribuire la modifica a un preciso attore e istante temporale.

I dati MITRE ATT&CK per T1547.008 non associano gruppi APT specifici alla tecnica, ma documentano due famiglie malware che ne rappresentano l'implementazione storica di riferimento e che permettono di ragionare su pattern di threat intelligence.

Wingbird (S0176) è un backdoor caratterizzato da una tecnica di persistenza sofisticata: droppa la libreria malevola sspisrv.dll accanto a una copia di lsass.exe e registra un servizio che carica la DLL come driver LSA. Il payload eseguito nella DllMain opera nei primi millisecondi prima che il servizio spoofato collassi, sfruttando la finestra di esecuzione garantita dal ciclo di caricamento dei Security Support Provider. Questo pattern indica un attore con conoscenza approfondita dell'architettura di autenticazione Windows e capacità di sviluppo native in C/C++, con priorità alla persistenza a livello SYSTEM e all'intercettazione di credenziali.

Pasam (S0208) adotta una strategia diversa ma concettualmente affine: infetta direttamente la Security Accounts Manager DLL per caricare una libreria malevola droppata su disco. L'approccio è più invasivo perché altera un componente di sistema firmato, ma garantisce esecuzione automatica ogniqualvolta la SAM viene interrogata, coprendo così sia la persistenza sia l'accesso alle credenziali locali. Il profilo tecnico suggerisce un attore interessato a compromessi di lungo termine su workstation e server con account locali di valore.

Dal punto di vista dei trend osservabili, l'introduzione di RunAsPPL (Windows 8.1+) e Credential Guard (Windows 10+) ha progressivamente reso la tecnica meno attraente per attori generalisti, spingendo la maggior parte del tradecraft moderno verso alternative meno visibili come T1003.001 (LSASS Memory dumping) o T1556 (Modify Authentication Process). T1547.008 resta però nel repertorio di attori state-sponsored che operano contro target con posture di sicurezza legacy, dove RunAsPPL non è abilitato o è stato disattivato tramite modifiche registry pre-attack.

Indicatori di prioritizzazione per un programma di threat intelligence:

• Verificare esposizione di endpoint con Windows Server 2012 o precedenti dove RunAsPPL non è disponibile o configurabile
• Monitorare feed OSINT per varianti moderne di Wingbird e Pasam, storicamente collegate a gruppi di spionaggio est-europeo
• Correlare rilevamenti T1547.008 con altri TTP di credential access nella stessa killchain, poiché la tecnica raramente compare isolata
• Includere nella threat modeling la possibilità di supply-chain attack che introducano Security Package firmati con certificati compromessi, scenario che aggira parte delle mitigazioni standard

L'attribuzione di un singolo evento a un gruppo specifico richiede sempre correlazione con altri indicatori (infrastruttura C2, tool ausiliari, target vertical), poiché la tecnica in sé non è discriminante geograficamente.

MITRE ATT&CK: T1547.008 (LSASS Driver), tattiche TA0003 e TA0004. Software: S0176 (Wingbird), S0208 (Pasam). Mitigazioni: M1025, M1043, M1044. Detection: DET0225, analytic AN0629. MITRE D3FEND per artefatti Process e Kernel Module. Contenuti operativi su comandi, tool (Sysmon, Volatility 3, RegRipper, Mimikatz, Atomic Red Team, PECmd, MFTECmd, WinPmem) e procedure di detection integrano la conoscenza professionale di cybersecurity dell'autore con riferimenti a documentazione ufficiale dei rispettivi progetti.