Skeleton Key sul Domain Controller: Domain Controller Authentication (T1556.001)

Questa tecnica consente a un avversario di alterare il processo di autenticazione direttamente sul domain controller, iniettando credenziali fittizie nella memoria del processo LSASS. Il risultato è una backdoor silenziosa: l'attaccante può autenticarsi come qualsiasi utente del dominio usando una password universale — la cosiddetta Skeleton Key — senza modificare le password reali degli account.

La tecnica si colloca in tre tattiche distinte della kill chain. In Credential Access (TA0006) rappresenta un metodo per ottenere accesso alle credenziali di qualunque account di dominio. In Defense Evasion (TA0005) funziona perché le credenziali legittime degli utenti restano invariate, rendendo la compromissione invisibile ai controlli convenzionali. In Persistence (TA0003), infine, garantisce una presenza stabile finché il domain controller non viene riavviato, poiché la patch risiede solo in memoria.

L'impatto è devastante negli ambienti a singolo fattore di autenticazione: una volta patchato LSASS, l'intera infrastruttura Active Directory diventa accessibile con una sola password. Un riavvio del DC cancella la modifica dalla memoria, ma senza detection attiva l'attaccante può reiniettare il payload indisturbato. Dai dati disponibili risultano 1 gruppo APT, 1 software documentato e 4 mitigazioni applicabili — numeri contenuti che riflettono l'alto livello di privilegio necessario per eseguire questa tecnica, tipico di fasi avanzate dell'intrusione.

Per simulare questa tecnica in laboratorio è indispensabile un ambiente Active Directory isolato con almeno un domain controller Windows Server 2019 o 2022. Il test richiede privilegi di Domain Admin o equivalenti, poiché l'iniezione avviene nel processo LSASS del DC — un processo protetto ad alto privilegio.

Lo strumento di riferimento è Mimikatz (open source), che include il modulo misc::skeleton progettato esattamente per questo scenario. Prima di eseguire l'iniezione, è utile verificare lo stato di protezione del processo LSASS sul target. Da una sessione PowerShell elevata sul domain controller:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL"

Se il valore è impostato a 1, la protezione Protected Process Light è attiva e l'iniezione standard fallirà. In laboratorio, per procedere con il test, si può disabilitare temporaneamente questa protezione — operazione che in produzione costituirebbe invece il primo indicatore di manomissione.

Con LSASS non protetto da PPL, l'iniezione si esegue dal domain controller stesso dopo aver ottenuto una sessione privilegiata:

mimikatz # privilege::debug mimikatz # misc::skeleton

Il modulo patcha in memoria le funzioni di autenticazione NTLM, iniettando la password di default mimikatz. A questo punto, da qualsiasi workstation del dominio, si può verificare l'autenticazione con la skeleton key:

net use \DC01\C$ /user:DOMINIO\qualsiasi_utente mimikatz

Se il comando restituisce accesso, l'iniezione ha funzionato. La password legittima dell'utente continua a funzionare normalmente — entrambe le credenziali sono valide in parallelo.

Per un approccio red team più strutturato, Cobalt Strike (a pagamento) permette di eseguire Mimikatz in-memory tramite il comando mimikatz nella beacon console, evitando di scrivere il binario su disco. In alternativa, il framework Impacket (open source) consente di interagire con il DC via rete per validare le credenziali iniettate usando lo script smbclient.py.

Al termine del test, un semplice riavvio del domain controller cancella la patch dalla memoria. Documentate nella timeline del report il momento esatto dell'iniezione, il SID dell'account utilizzato e tutti gli accessi eseguiti con la skeleton key, perché questi dati serviranno al blue team per calibrare le detection.

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto fin dal primo passo

La detection di questa tecnica ruota attorno a un principio chiave: qualcuno sta manipolando il processo LSASS su un domain controller. Le log source primarie sono Sysmon, il canale Security e il canale System del DC, come indicato nella detection DET0271.

Il primo livello di monitoraggio riguarda l'accesso anomalo alla memoria di LSASS. Sysmon EventCode 10 (ProcessAccess) registra ogni tentativo di aprire un handle verso un processo. Un alert efficace filtra gli eventi dove il processo target è lsass.exe e i permessi richiesti includono 0x1010 o 0x1FFFFF (PROCESS_ALL_ACCESS). Le esclusioni per ridurre i falsi positivi devono coprire tool legittimi come Windows Defender, l'agente EDR in uso e il servizio WMI — ma ogni esclusione va documentata e rivista trimestralmente.

Il secondo livello monitora il caricamento di DLL sospette nel contesto di LSASS. Sysmon EventCode 7 (ImageLoaded) cattura i moduli caricati nei processi. Le DLL critiche da sorvegliare sono cryptdll.dll e samsrv.dll — se queste vengono caricate da percorsi non standard o con hash non corrispondenti ai file di sistema, si tratta di un indicatore ad alta confidenza. Un buon tuning prevede una whitelist di hash noti per la versione specifica del sistema operativo.

Il terzo livello è comportamentale e correlativo. Dopo l'iniezione, l'attaccante tende a eseguire autenticazioni massive con account diversi in un intervallo di tempo ristretto. Dal canale Security, l'EventCode 4624 (Logon Success) con logon type 3 (Network) va correlato con gli eventi di accesso a LSASS: se entro una finestra temporale configurabile — tipicamente 5-15 minuti — si osservano accessi LSASS sospetti seguiti da molteplici logon riusciti da account eterogenei verso lo stesso DC, la probabilità di skeleton key è elevata.

Sul fronte dei controlli preventivi, la misura più efficace è l'abilitazione di RunAsPPL (Protected Process Light) per LSASS tramite la chiave di registro indicata nella mitigazione M1025. Inoltre, Windows Defender Credential Guard isola le credenziali in un ambiente virtualizzato, rendendo l'iniezione in LSASS significativamente più complessa. L'implementazione di MFA (M1032) per gli accessi privilegiati neutralizza il vantaggio della skeleton key, poiché la sola password non basta.

Per lo strumento SIEM, una regola Sigma di partenza può combinare: EventCode 10 verso LSASS + EventCode 7 con DLL di autenticazione + EventCode 4624 multipli — con soglia a tre o più logon da account distinti entro la finestra temporale.

Vuoi diventare SOC Analyst ma non sai da dove iniziare?

Scarica la guida gratuita e scopri come si monitorano e bloccano gli attacchi informatici

L'analisi forense di un attacco Skeleton Key è una sfida a tempo: la patch vive esclusivamente in memoria, e un riavvio del domain controller la cancella. L'acquisizione della RAM del DC diventa quindi la priorità assoluta, prima di qualsiasi altra operazione.

Con un dump di memoria disponibile, Volatility 3 (open source) è lo strumento di elezione. Il primo passo è elencare i moduli caricati nel processo LSASS per individuare DLL non standard o con percorsi anomali:

python3 vol.py -f memoria_dc.raw windows.dlllist --pid <PID_LSASS>

Un modulo caricato da una directory diversa da C:\Windows\System32 è un indicatore critico. Se emergono DLL sospette, si può estrarre il binario dalla memoria per analisi statica con:

python3 vol.py -f memoria_dc.raw windows.dumpfiles --pid <PID_LSASS>

Il plugin windows.malfind rileva sezioni di memoria con permessi anomali — tipicamente regioni marcate come RWX (Read-Write-Execute) all'interno del processo LSASS, che indicano codice iniettato. Skeleton Key modifica le funzioni di autenticazione in memoria, quindi le sezioni patchate presenteranno byte diversi rispetto alle DLL originali su disco. Un confronto hash tra la cryptdll.dll in memoria e quella su filesystem è un check rapido ed efficace.

Passando agli artefatti su disco e nei log, la timeline si costruisce su tre pilastri. Il primo è il canale Security del DC: gli eventi 4624 con logon type 3 vanno filtrati per individuare pattern di autenticazione anomali — lo stesso indirizzo IP sorgente che si autentica con successo usando account diversi in rapida successione è la firma comportamentale della skeleton key in uso. Il secondo pilastro sono i log Sysmon: gli EventCode 10 verso LSASS e gli EventCode 7 relativi a cryptdll.dll e samsrv.dll forniscono il timestamp dell'iniezione.

Il terzo pilastro riguarda il contesto. Il gruppo Chimera (G0114) ha utilizzato questa tecnica modificando il programma di autenticazione NTLM sui domain controller. In fase di analisi, cercate artefatti di lateral movement precedenti l'iniezione — l'attaccante ha necessariamente raggiunto privilegi di Domain Admin prima di patchare LSASS. Le tracce di accesso al DC tramite PsExec, WMI o WinRM nei minuti precedenti l'evento Sysmon sono elementi fondamentali della timeline.

Per la preservazione delle evidenze, oltre al dump di memoria, acquisite i registri di sistema — in particolare la chiave HKLM\SYSTEM\CurrentControlSet\Control\Lsa per verificare se RunAsPPL era attivo o se è stato disabilitato dall'attaccante come passo preparatorio.

Vuoi diventare Forensic Analyst ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto per analizzare incidenti e prove digitali

Chimera (G0114)

Chimera è il gruppo APT documentato per l'impiego di questa tecnica. Il loro approccio si distingue per la modifica diretta del programma di autenticazione NTLM sul domain controller, un'operazione che richiede un livello di accesso già profondo nell'infrastruttura target. Questo posiziona la tecnica nelle fasi avanzate della kill chain di Chimera — non è un vettore iniziale, ma un meccanismo di consolidamento post-compromissione.

Il pattern operativo suggerisce un gruppo con competenze avanzate in ambienti Active Directory e una chiara focalizzazione sulla persistenza silenziosa. La scelta di alterare l'autenticazione NTLM piuttosto che creare account aggiuntivi o modificare Group Policy riflette un approccio orientato alla stealth: le credenziali degli utenti non cambiano, nessun account viene creato e l'unica traccia è in memoria volatile.

Skeleton Key (S0007) come indicatore di sofisticazione

Il software Skeleton Key rappresenta l'implementazione di riferimento per questa tecnica. La sua architettura — patch in memoria senza persistenza su disco — definisce un profilo di threat actor che privilegia la volatilità rispetto alla permanenza. Qualsiasi gruppo che impieghi varianti di Skeleton Key sta operando con l'assunzione di poter ripristinare l'accesso dopo un reboot, il che implica altri meccanismi di persistenza già attivi nell'ambiente.

Pattern predittivi e raccomandazioni

Dal punto di vista dell'intelligence operativa, il rilevamento di questa tecnica in un'intrusione attiva indica con alta probabilità che l'attaccante ha già raggiunto il dominio e possiede almeno un canale di persistenza alternativo. La priorità dell'analisi non è solo contenere la skeleton key — che si risolve con un riavvio — ma individuare il meccanismo con cui l'avversario ha ottenuto e mantiene i privilegi di Domain Admin.

Gli ambienti a singolo fattore di autenticazione sono esposti al massimo impatto. L'adozione di MFA per gli accessi privilegiati e l'abilitazione di PPL su tutti i domain controller sono le contromisure strategiche con il miglior rapporto costo-efficacia. Monitorare la telemetria dei DC con priorità superiore rispetto ai normali endpoint è una raccomandazione da tradurre in policy: i domain controller non sono server generici, sono il cuore dell'identità.

Il trend da osservare è l'evoluzione di tecniche simili verso ambienti cloud ibridi. Man mano che le organizzazioni sincronizzano Active Directory con Azure AD (ora Entra ID), la compromissione del DC on-premises può estendersi all'identità cloud — ampliando la superficie d'impatto ben oltre il perimetro tradizionale.