Abuso SSP: Security Support Provider (T1547.005)

In un ingaggio red team autorizzato, l'abuso di SSP si presta come tecnica di persistenza silenziosa post-compromissione di un endpoint con privilegi amministrativi locali. Il flusso operativo tipico parte da una shell elevata su un host Windows di laboratorio.

Il primo approccio è PowerSploit (open source), suite PowerShell offensiva ancora ampiamente referenziata in letteratura. Il modulo Install-SSP automatizza la registrazione di una DLL nel registro e la copia nel percorso C:\Windows\System32. Su un sistema di test la sequenza è:

Import-Module .\PowerSploit.psd1

Install-SSP -Path .\mimilib.dll

La libreria mimilib.dll è distribuita insieme a Mimikatz (open source) e implementa un SSP che scrive ogni credenziale intercettata in un file di log locale (kiwissp.log in System32). Dopo il riavvio della VM, LSASS caricherà la libreria e inizierà a registrare le autenticazioni interattive e di rete.

Empire (open source, mantenuto dalla community BC-Security) integra la stessa logica in un framework post-exploitation completo. Dal modulo powershell/persistence/elevated/install_ssp si automatizza la catena, includendo l'enumerazione preventiva degli SSP già registrati per verificare la presenza di soluzioni di credential guarding.

Un approccio manuale, utile per validare detection rule senza toolkit noti, consiste nel modificare direttamente la chiave di registro con reg add:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v "Security Packages" /t REG_MULTI_SZ /d "kerberos\0msv1_0\0schannel\0wdigest\0tspkg\0pku2u\0evil" /f

dopo aver copiato evil.dll in System32. Un riavvio completa la persistenza.

Nei lab moderni due ostacoli sono attesi. Il primo è LSA Protection (RunAsPPL), attivabile via HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL, che impedisce il caricamento di DLL non firmate Microsoft dentro LSASS. Il bypass richiede un driver kernel firmato o l'exploit di vulnerabilità note, entrambi fuori scope per un normale test. Il secondo è Credential Guard, che isola i segreti in un contesto virtualizzato basato su VBS: anche una DLL SSP caricata con successo non vedrà più hash NTLM o ticket TGT in chiaro.

Per validare l'esecuzione post-riavvio si può usare Process Explorer (gratuito, Sysinternals) filtrando i moduli caricati da lsass.exe e verificando la firma digitale della DLL sospetta. In alternativa, PowerShell offre Get-Process lsass | Select-Object -ExpandProperty Modules per un enumerazione rapida da riga di comando.

La detection di T1547.005 si fonda su due pilastri correlati temporalmente: modifiche al registro delle chiavi SSP e caricamento di DLL anomale in LSASS dopo il riavvio successivo. La regola di rilevazione MITRE DET0542 codifica esattamente questa correlazione.

La prima sorgente è il Windows Security Log, dove abilitando la Audit Policy Audit Registry (subcategoria Object Access) si generano EventCode 4657 alla modifica di valori sotto HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Il filtro deve concentrarsi sui valori Security Packages e OSConfig\Security Packages: qualsiasi scrittura fuori dai cicli di patching Microsoft o installazioni SSO enterprise (RSA, Duo, alcuni MFA provider) va considerata sospetta.

La seconda sorgente è Sysmon (gratuito, Sysinternals), configurato con una regola ImageLoad focalizzata su lsass.exe. L'Event ID 7 di Sysmon riporta ogni DLL caricata, con hash, firma digitale e stato di validazione. Una configurazione robusta parte dal template di SwiftOnSecurity (open source) e aggiunge una regola specifica:

lsass.exe

Gli alert prioritari sono DLL caricate da LSASS che risultano Signed: false, SignatureStatus: Unavailable o firmate da publisher non Microsoft. Nomi come mimilib.dll, sekurlsa.dll o DLL con nomi legittimi (kerberos.dll) ma percorsi anomali (*C:\Users*, C:\Temp) sono indicatori di alta confidenza.

La correlazione temporale è il cuore della logica di detection: una modifica al valore Security Packages seguita, dopo un boot event (EventCode 6005 nel System Log o EventCode 4608 nel Security Log), dal caricamento di una DLL sconosciuta in LSASS entro la prima finestra di 5 minuti dall'avvio, costituisce una catena ad altissima specificità. In SIEM come Splunk o Elastic questa correlazione si esprime con una join tra indice registro e indice Sysmon sul campo ComputerName.

Un ulteriore controllo preventivo è il monitoraggio del valore AuditLevel sotto HKLM\SYSTEM\CurrentControlSet\Control\Lsa: impostato a 8, forza LSASS a scrivere in Event Log ogni caricamento di SSP tramite EventCode 3033 e 3063 nel canale Microsoft-Windows-CodeIntegrity/Operational, particolarmente utile in ambienti con RunAsPPL attivo.

I falsi positivi più comuni provengono da agent legittimi che estendono l'autenticazione: soluzioni MFA come Duo, gateway Citrix, driver di smart card di terze parti e prodotti di identity federation. Una whitelist per hash e publisher è indispensabile. Il tuning richiede baseline di almeno 30 giorni per stabilire il set normale di SSP nell'ambiente e definire la CustomSSPNameList menzionata nella logica DET0542.

L'analisi forense di un compromesso via SSP parte dall'acquisizione di registry hive e memoria volatile dell'host sospetto. Le due hive rilevanti sono SYSTEM (per la configurazione SSP) e SOFTWARE (per correlare eventuali installer o task che hanno preparato la persistenza).

La chiave HKLM\SYSTEM\CurrentControlSet\Control\Lsa, estratta con RegRipper (open source) tramite il plugin lsa, mostra i pacchetti registrati. Il confronto con una baseline pulita rivela immediatamente valori aggiuntivi. In un sistema Windows 10/11 di riferimento Security Packages contiene tipicamente kerberos, msv1_0, schannel, wdigest, tspkg, pku2u, cloudAP; qualsiasi voce ulteriore va considerata artefatto.

Il timestamp della chiave Lsa (LastWrite time) fornisce l'ancora temporale iniziale: usando Registry Explorer di Eric Zimmerman (open source) si visualizza con precisione al millisecondo il momento della modifica. Correlando con UserAssist, ShimCache (AppCompatCache) e Amcache.hve si identifica il processo esecutore e l'eventuale binario intermedio (PowerShell, cmd, un dropper). Amcache in particolare conserva hash SHA1 di ogni eseguibile lanciato, utile per pivotare su altri host.

Sul filesystem, la DLL malevola risiede normalmente in C:\Windows\System32 per essere caricata senza path esplicito. L'analisi del Master File Table con MFTECmd (open source, Zimmerman) e la timeline con plaso/log2timeline (open source) permettono di verificare data di creazione, modifica e ultimo accesso della DLL sospetta. Un file System32 con timestamp recente e non correlato ad alcun aggiornamento Windows (verificabile via DISM o log CBS) è fortemente indicativo.

Sulla memoria, un dump acquisito con WinPmem (open source) o FTK Imager (gratuito) si analizza con Volatility 3 (open source). I plugin chiave sono windows.dlllist filtrato per PID di lsass.exe, windows.malfind per rilevare regioni di memoria RWX iniettate, e windows.modules per l'elenco completo dei driver e moduli caricati. Le DLL non presenti sul disco ma caricate in memoria (reflective loading) rappresentano un pattern di alta severità.

Gli Event Log rilevanti sono System.evtx (evento 6005 per boot, 6006 per shutdown, ricostruzione della sequenza temporale), Security.evtx (4657 per registry modification, 4624/4625 per autenticazioni successive che la DLL può aver intercettato) e Microsoft-Windows-Sysmon/Operational per gli ImageLoad. EVTX Explorer e Chainsaw (entrambi open source) accelerano il triage.

Se mimilib.dll è stato usato senza modifiche, in C:\Windows\System32\kiwissp.log si trovano credenziali raccolte in chiaro — un artefatto conclusivo per la ricostruzione dell'impatto.

Il panorama di threat intelligence su T1547.005 è caratterizzato non tanto da attribuzioni a gruppi APT specifici documentate nel dataset MITRE, quanto dalla commodificazione della tecnica attraverso tre strumenti open source di riferimento che ne hanno definito lo standard operativo per oltre un decennio.

Mimikatz (S0002), creato da Benjamin Delpy, rappresenta l'implementazione canonica. La libreria mimilib.dll inclusa nel progetto contiene un SSP funzionante che registra ogni tentativo di autenticazione processato da LSASS su file locale. La sua diffusione è tale che praticamente ogni actor con capacità Windows — dai gruppi state-sponsored ai ransomware affiliate — ha avuto accesso o adattato porzioni del suo codice. La disponibilità pubblica del sorgente ha reso Mimikatz una baseline che i difensori devono assumere sempre nel modello di minaccia.

PowerSploit (S0194), pur non più attivamente sviluppato, resta ampiamente referenziato per il modulo Install-SSP che astrae la complessità della registrazione. Il framework PowerShell offensivo è stato assorbito, forkato e integrato in innumerevoli pipeline di attacco, incluse versioni obfuscate distribuite attraverso loader personalizzati per evadere AMSI e signature statiche.

Empire (S0363), oggi mantenuto da BC-Security come fork community-driven del progetto originale, integra sia PowerSploit sia Mimikatz e ne orchestra l'uso combinato. Il modulo dedicato può enumerare SSP esistenti, installare una nuova libreria malevola e sfruttare Invoke-Mimikatz per l'estrazione immediata di credenziali. Questa combinazione tool-chain è particolarmente osservata in operazioni condotte da actor ransomware di livello intermedio e in attività di penetration testing non autorizzate.

Il pattern strategico che emerge è chiaro: T1547.005 non è una tecnica opportunistica ma post-compromissione avanzata, che presuppone privilegi amministrativi locali già acquisiti. Per questo motivo compare tipicamente in kill chain estese, dopo fasi di Initial Access, Execution ed Escalation. L'obiettivo finale è quasi sempre la raccolta di credenziali di dominio in ambienti Active Directory, propedeutica a lateral movement massivo e a operazioni di dumping tipo DCSync.

La tendenza di lungo periodo mostra un declino relativo dell'efficacia della tecnica su endpoint moderni, dovuto all'adozione progressiva di LSA Protection (PPL), Credential Guard basato su virtualizzazione e Windows Defender Application Control. Tuttavia, in ambienti enterprise con parco macchine misto — server legacy Windows Server 2012/2016, workstation non aggiornate, controller di dominio con configurazioni ereditate — la tecnica resta pienamente sfruttabile. Attori che investono in ricognizione preliminare tendono a targetizzare specificamente questi host residuali, dove il ROI della persistenza SSP resta elevato.

MITRE ATT&CK T1547.005 (Security Support Provider), tattiche TA0003 e TA0004. Software: S0002 (Mimikatz), S0194 (PowerSploit), S0363 (Empire). Mitigazione M1025 (Privileged Process Integrity). Detection MITRE DET0542 con analytic AN1495. MITRE D3FEND per artefatti Registry Key e Process/Module Load. Il documento integra conoscenza professionale verificata su tool open source (Sysmon, Volatility 3, RegRipper, MFTECmd, plaso, Chainsaw, WinPmem) e configurazioni Windows LSA Protection e Credential Guard.