Password Filter DLL Malevola: Password Filter DLL (T1556.002)

In un esercizio red team autorizzato, la simulazione di T1556.002 richiede un laboratorio isolato con un Domain Controller di test, perché la tecnica intercetta password reali di ogni utente e non deve mai toccare produzione.

La catena tipica parte da un accesso con privilegi amministrativi sul DC (o su una workstation per credenziali locali), seguita dallo sviluppo di una DLL che esporta le funzioni richieste dall'API di Windows: InitializeChangeNotify, PasswordChangeNotify e PasswordFilter. Microsoft documenta queste esportazioni nella sezione Password Filters di Win32 API; la DLL può essere scritta in C con Visual Studio o MinGW. Per finalità didattiche esiste il progetto PasswordFilter di Clymb3r su GitHub (open source), che mostra un'implementazione di riferimento che scrive le password in chiaro su file — da usare solo in lab.

Il deployment richiede due passaggi. Prima la DLL va copiata in *C:\Windows\System32* con lo stesso ACL delle DLL legittime, cosa che tipicamente si fa con:

*copy filtro.dll C:\Windows\System32*

Poi va registrata aggiungendo il nome (senza estensione) alla chiave di registro dei Notification Packages. Da PowerShell elevato:

$key = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa'; $current = (Get-ItemProperty -Path $key -Name 'Notification Packages').'Notification Packages'; Set-ItemProperty -Path $key -Name 'Notification Packages' -Value ($current + 'filtro')

Dopo un riavvio del sistema, lsass.exe carica il nuovo filtro e inizia a passargli ogni password validata. Per un red team la validazione dell'operazione consiste nel cambiare la password di un utente di test e verificare che la DLL abbia intercettato il valore in chiaro.

Come alternativa più realistica ai tool custom, Mimikatz (open source) include il modulo misc::memssp che, pur essendo tecnicamente un Security Support Provider (T1556.005) e non un Password Filter, ottiene un risultato analogo iniettando in lsass un componente che logga credenziali in chiaro. La distinzione va mantenuta nel report finale.

Durante l'esercizio è utile documentare il tempo tra registrazione e primo cambio password intercettato, la persistenza attraverso riavvii, e verificare quali soluzioni EDR presenti nell'ambiente cliente rilevano la modifica alla chiave Notification Packages o il caricamento di una DLL non firmata da parte di lsass.exe. Al termine dell'esercizio, rimuovere il valore dal registro, riavviare, cancellare la DLL e ruotare tutte le password intercettate.

La detection di T1556.002 si costruisce attorno a due segnali forti e uno debole. I due forti sono la modifica del valore di registro HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages e il caricamento di una DLL non nota dentro lsass.exe. Il segnale debole è la creazione di un file DLL in *C:\Windows\System32* fuori dai cicli di patch Microsoft.

Sul fronte log, la modifica del registro genera un evento nel Security log se la SACL sulla chiave Lsa è configurata per auditare le scritture: EventCode 4657 riporta il nome del valore modificato e il processo che ha operato la modifica. In parallelo, Sysmon (open source, Microsoft Sysinternals) è indispensabile: la regola EventID 13 (Registry Value Set) cattura la modifica di Notification Packages senza dipendere dalla SACL, mentre EventID 7 (Image Loaded) registra ogni DLL caricata da lsass.exe. Una configurazione Sysmon efficace è quella di SwiftOnSecurity o la baseline di Olaf Hartong (entrambe open source), che includono già filtri specifici per LSA.

La regola di correlazione che risponde alla detection DET0472 dovrebbe innescare quando, in una finestra di pochi minuti, si osservano: creazione di una DLL in una directory di sistema, modifica del valore Notification Packages, e — al riavvio successivo o al primo cambio password — caricamento della stessa DLL dentro lsass.exe. Un allarme immediato serve anche solo per la modifica isolata della chiave, perché in un ambiente stabile Notification Packages cambia raramente.

Come baseline di tuning, mantenere una allowlist dei nomi DLL attesi: rassfm, scecli e i filtri di terze parti installati esplicitamente (ad esempio quelli dei prodotti di password policy enforcement come Specops Password Policy o nFront Password Filter, entrambi a pagamento). Ogni valore aggiunto fuori da questa lista è sospetto.

Sul lato preventivo, D3FEND suggerisce controlli di integrità sui percorsi di caricamento e su LSA. LSA Protection (RunAsPPL, configurabile via HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1) impedisce il caricamento in lsass di codice non firmato Microsoft o con firma non conforme, e blocca alla radice la maggior parte delle implementazioni di password filter malevoli.

I falsi positivi principali derivano da installazioni legittime di prodotti di password policy o da agent di sincronizzazione password verso IdP esterni (Azure AD Connect, Okta AD Agent). In questi casi il change management deve tracciare l'installazione e la relativa DLL va aggiunta alla baseline. Un altro falso positivo classico è il caricamento di DLL Microsoft aggiornate dopo Patch Tuesday: correlare sempre con la firma digitale e il timestamp di patching.

L'analisi forense di un caso T1556.002 parte dai due artefatti primari sopravvissuti nel sistema: la chiave di registro HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages e la DLL fisica in *C:\Windows\System32*.

Sull'immagine disco o su un triage live, il hive SYSTEM si estrae da C:\Windows\System32\config\SYSTEM e si analizza con Registry Explorer di Eric Zimmerman (open source) oppure con RegRipper (open source) usando il plugin lsa. Il valore Notification Packages è di tipo REG_MULTI_SZ e contiene una lista di nomi DLL senza estensione. La presenza di nomi diversi da quelli standard (rassfm, scecli, kdcsvc sui DC) è un forte indicatore di compromissione. Il timestamp LastWrite della chiave Lsa nel hive fornisce il momento approssimativo della registrazione ed è il pivot temporale per costruire la timeline.

Per la DLL sospetta, l'analisi va condotta su tre livelli. Metadata di file system: $MFT estratta con MFTECmd (open source) rivela timestamp di creazione, eventuale timestomping (discrepanza tra $STANDARD_INFORMATION e $FILE_NAME), e il numero di sequenza che aiuta a collocare il file rispetto ad altri artefatti. Firma digitale: una password filter DLL legittima è firmata Microsoft o dal vendor di terze parti; l'assenza di firma o una firma self-signed è diagnostica. Analisi statica: verificare che la DLL esporti InitializeChangeNotify, PasswordChangeNotify e PasswordFilter con PE-bear o CFF Explorer (entrambi open source). Se esporta funzioni di rete, scrittura file o crittografia, il ruolo malevolo è confermato.

La timeline dell'incidente si costruisce correlando: LastWrite della chiave Lsa, timestamp $SI della DLL, evento 4657 nel Security log se disponibile, eventi Sysmon 13 e 7, log di lsass nel canale Microsoft-Windows-LSA/Operational. Utile anche estrarre le Prefetch con PECmd (open source) per capire quali eseguibili amministrativi (regedit, reg.exe, PowerShell) sono stati eseguiti nella finestra temporale della registrazione.

Per la valutazione di impatto — cioè quali credenziali sono state esposte — bisogna assumere che ogni password cambiata o impostata dopo la registrazione del filtro sia compromessa. Sui DC questo significa potenzialmente l'intero dominio. La query LDAP pwdLastSet > timestamp_registrazione identifica gli account che hanno ruotato la password nella finestra pericolosa e devono essere considerati esposti.

Sui casi documentati, Remsec (S0125) impiegato da Strider ha usato questa tecnica proprio sui Domain Controller per raccogliere credenziali in modo silente e prolungato, mentre OilRig l'ha usata anche come vettore di drop per ulteriori componenti — quindi la DLL può contenere sia logica di credential harvesting sia loader secondari, e va analizzata per intero.

L'abuso dei Password Filter DLL è una tecnica di nicchia ma segnaletica: appare quasi esclusivamente in operazioni di cyber espionage condotte da attori state-sponsored con obiettivi di persistenza a lungo termine e raccolta credenziali su scala di dominio. La casistica pubblica è limitata a due gruppi, ma il profilo di entrambi è indicativo del tipo di avversario che investe in questa tecnica.

Strider (G0041), noto anche in letteratura come ProjectSauron, è un gruppo di cyber espionage attribuito ad attività contro target governativi, militari e di ricerca scientifica in diverse aree geografiche tra cui Russia, Iran, Ruanda e Belgio. La sofisticazione operativa di Strider è di primo livello: infrastruttura unica per vittima, malware modulare (Remsec), e uso pesante di tecniche di persistenza che non richiedono callback frequenti verso C2, per ridurre la superficie di detection di rete. La registrazione di Remsec come password filter sui Domain Controller è coerente con questa filosofia: una volta piazzato, il modulo raccoglie credenziali passivamente ogni volta che un utente cambia password, senza necessità di rilanciare processi o generare traffico anomalo. Le credenziali raccolte alimentano poi movimenti laterali interni al dominio compromesso.

OilRig (G0049), tracciato anche come APT34 e Helix Kitten, è un gruppo attribuito a interessi iraniani, attivo principalmente contro target in Medio Oriente nei settori energia, finanza, governo e telecomunicazioni. L'uso di password filter DLL da parte di OilRig è documentato anche come meccanismo di drop di malware aggiuntivo, non solo come credential harvester puro. Questo doppio uso è un dettaglio operativamente interessante: la registrazione del filtro fornisce sia persistenza sia una funzione operativa secondaria dentro un processo estremamente privilegiato (lsass.exe), difficile da terminare senza destabilizzare il sistema.

Sul fronte software, Remsec (S0125) è il caso pubblico più chiaramente documentato di implementazione di password filter malevolo, con harvesting di credenziali in plaintext direttamente sui DC.

Il pattern comune tra i due gruppi è l'obiettivo di dominio: entrambi bersagliano i Domain Controller, non le workstation, perché il ROI in termini di credenziali raccolte è ordini di grandezza superiore. Il prerequisito operativo condiviso è l'accesso amministrativo pregresso al DC, quindi la tecnica non è mai un vettore iniziale ma un moltiplicatore di privilegi già ottenuti attraverso altre vie (spearphishing, sfruttamento di vulnerabilità perimetrali, credenziali riutilizzate).

Come trend prospettico, l'adozione crescente di LSA Protection (RunAsPPL) e Credential Guard in ambienti enterprise sta riducendo la finestra operativa per questa tecnica. Gli attaccanti sofisticati tendono a spostarsi verso alternative come Security Support Provider malevoli (T1556.005) o manipolazione del processo di autenticazione a livello Kerberos. La tecnica rimane però praticabile in tutti gli ambienti dove LSA Protection non è stato abilitato — che restano la maggioranza fuori dai top-tier security programs.

MITRE ATT&CK: T1556.002 (Password Filter DLL), tattiche TA0003, TA0005, TA0006. Gruppi G0041 (Strider), G0049 (OilRig). Software S0125 (Remsec). Mitigazione M1028. Detection DET0472 con analytic AN1303. MITRE D3FEND per controlli difensivi su LSA e integrità DLL. Contenuti tecnici su implementazione API password filter, Sysmon, LSA Protection e strumenti forensi Zimmerman derivano da conoscenza professionale di cybersecurity e documentazione ufficiale Microsoft Win32 API.