Furto del Database Active Directory: OS Credential Dumping — NTDS (T1003.003)

Il dump dell'NTDS.dit è uno dei passaggi chiave in qualsiasi simulazione di compromissione del dominio. Per replicarlo in laboratorio servono credenziali con privilegi di Domain Admin — o almeno i diritti di backup sul domain controller — e una buona familiarità con le utility native di Windows e con i tool offensivi più diffusi.

Approccio 1 — Volume Shadow Copy con vssadmin

Il metodo più "rumoroso" ma anche il più diretto. Si crea una copia shadow del volume di sistema e si estrae il file dal percorso ombra. Sulla console del domain controller, da un prompt elevato:

vssadmin create shadow /for=C:

Annotate il percorso della shadow copy restituito nell'output (es. \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyX), poi copiate il file:

copy \?\GLOBALROOT\Device\HarddiskVolumeShadowCopyX\Windows\NTDS\ntds.dit C:\temp\ntds.dit

Serve anche l'hive SYSTEM per decifrare gli hash:

reg save HKLM\SYSTEM C:\temp\SYSTEM

Infine, pulite la shadow copy creata:

vssadmin delete shadows /shadow={ID-shadow}

Approccio 2 — ntdsutil.exe (IFM media)

La utility nativa di gestione Active Directory offre un metodo elegante che produce un set completo di file — NTDS.dit e registry hive — in un'unica operazione. L'approccio sfrutta la funzione "Install From Media", pensata per promuovere nuovi domain controller senza replicazione di rete:

ntdsutil "ac i ntds" "ifm" "create full C:\temp\ifm" q q

Nella cartella C:\temp\ifm troverete sia il database che le chiavi necessarie all'estrazione offline.

Approccio 3 — Impacket secretsdump.py (remoto)

Impacket (open source) permette di estrarre gli hash via protocollo DRSUAPI senza toccare fisicamente il file, simulando una replicazione di dominio. Da una macchina Linux d'attacco:

secretsdump.py -just-dc DOMINIO/utente:password@IP-DC

Questo approccio è particolarmente insidioso perché non crea shadow copy e non accede direttamente al file NTDS.dit sul disco, rendendo la detection basata su file access molto meno efficace.

Approccio 4 — CrackMapExec

CrackMapExec (open source, oggi proseguito nel fork NetExec) offre un wrapper comodo per le stesse operazioni:

nxc smb IP-DC -u utente -p password --ntds

Per l'estrazione offline degli hash da un file NTDS.dit già ottenuto, usate secretsdump.py in modalità locale:

secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL

Durante l'engagement, documentate quale metodo genera più artefatti: la shadow copy è facilmente rilevabile, mentre DRSUAPI richiede detection di livello diverso. Questo confronto fornisce al blue team informazioni preziose sulla copertura dei propri controlli.

La detection dell'NTDS dumping richiede una strategia a più strati, perché gli avversari possono scegliere percorsi molto diversi per raggiungere lo stesso obiettivo. L'analytic principale (DET0586) si concentra su tre log source fondamentali: Security Event Log, Sysmon e i log del Volume Shadow Copy Service (VSS).

Il primo segnale da monitorare è la creazione di shadow copy sul domain controller. L'EventCode 8222 nei log VSS segnala la creazione di una nuova copia shadow, ma da solo genera falsi positivi legati ai backup legittimi. La chiave è la correlazione temporale: se entro una finestra di 5 minuti dalla creazione della shadow copy si osserva un accesso al percorso \NTDS\ntds.dit — rilevabile tramite Sysmon EventCode 11 (FileCreate) o l'EventCode 4663 nei Security log con audit sugli object access abilitato — allora la confidenza dell'alert sale significativamente.

Per la detection di ntdsutil.exe e vssadmin.exe, il processo di creazione è tracciabile con Sysmon EventCode 1 (Process Creation). Costruite una regola che rilevi l'esecuzione di questi binari sul domain controller con parametri sospetti: per ntdsutil cercate le stringhe ifm e create full nella command line, per vssadmin il parametro create shadow. Il tuning suggerisce di gestire il ParentProcessName escludendo i processi padre legittimi legati a sistemi di backup enterprise (ad esempio agenti Veeam, Commvault o Windows Server Backup).

Il percorso DRSUAPI è più subdolo. La detection richiede di monitorare l'EventCode 4662 nei Security log, cercando richieste di replica directory che specificano i GUID delle proprietà di replicazione (in particolare l'estensione dei diritti DS-Replication-Get-Changes-All). Se l'account che effettua la richiesta non è un domain controller registrato, è un forte indicatore di compromissione.

Per il contesto utente, configurate una whitelist degli account di servizio e degli account amministrativi autorizzati a interagire con NTDS. Qualsiasi accesso da un account non in lista — specialmente se combinato con logon anomali (EventCode 4624 tipo 3 o tipo 10) — merita investigazione immediata.

I falsi positivi più comuni provengono da:

• Backup schedulati che creano shadow copy regolari
• Operazioni di manutenzione AD (deframmentazione NTDS, verifica integrità con esentutl)
• Promozione di nuovi domain controller che usano IFM

Il consiglio pratico è separare le regole per metodo — shadow copy, ntdsutil, DRSUAPI — assegnando severity crescente e utilizzando la correlazione temporale come moltiplicatore. Un alert su shadow copy isolata può essere medio; shadow copy + accesso NTDS + account non in whitelist è critico.

La ricostruzione di un dump NTDS.dit lascia tracce distribuite su più fonti, ed è fondamentale raccoglierle tutte prima che la rotazione dei log le cancelli. I domain controller sono spesso i sistemi più trascurati in termini di retention, perché si assume siano "sicuri per default".

Artefatti del Volume Shadow Copy

Il primo elemento da cercare è la lista delle shadow copy residue. Anche se l'attaccante ha eseguito la cancellazione, il log VSS conserva traccia della creazione e della rimozione. Interrogate il sistema con:

vssadmin list shadows

Confrontate le shadow copy presenti con quelle attese dal piano di backup. Le shadow copy "orfane" — create fuori dalla schedulazione — sono un forte indicatore. Nel registro eventi, il canale Microsoft-Windows-VSS contiene gli eventi di creazione e cancellazione con timestamp precisi che ancorano la timeline.

Artefatti di ntdsutil e IFM

L'uso di ntdsutil con il parametro IFM lascia una struttura di cartelle caratteristica, con sottodirectory Active Directory e registry. Anche se l'attaccante ha rimosso la cartella di output, i record MFT (Master File Table) e il journal $UsnJrnl conservano traccia della creazione e cancellazione dei file. Estraete la MFT con tool come MFTECmd (open source, parte della suite Eric Zimmerman Tools) e filtrate per il path di output:

MFTECmd.exe -f "C:$MFT" --csv C:\output --csvf mft_parsed.csv

Cercate nel CSV risultante entry riferite a ntds.dit, SYSTEM e alle cartelle temporanee tipiche (ifm, temp, exfil).

Artefatti DRSUAPI

Se l'attaccante ha usato il percorso di replicazione remoto, gli artefatti sul domain controller sono più sottili. L'EventCode 4662 con i GUID di replica è la traccia primaria, ma verificate anche i log di autenticazione (EventCode 4624) per identificare da quale sistema è partita la richiesta. Correlate l'IP sorgente con i log di rete per tracciare il percorso laterale dell'attaccante.

Evidenze di staging e esfiltrazione

Dopo il dump, l'attaccante deve trasferire il file — che può pesare diversi gigabyte. Cercate nei log del firewall e del proxy trasferimenti anomali in uscita dal domain controller, specialmente su protocolli come SMB, HTTP/S o servizi cloud. Sul filesystem, l'attaccante potrebbe aver compresso il file prima del trasferimento: cercate artefatti di 7-Zip, WinRAR o comandi compress nativi nei log Sysmon e nella Prefetch del sistema.

Per le campagne documentate, la APT28 Nearest Neighbor Campaign (C0051) mostra un pattern specifico: dump via vssadmin seguito da trasferimento attraverso sistemi dual-homed compromessi. In Cutting Edge (C0029), gli attaccanti hanno montato backup di dischi virtuali dei domain controller per estrarre il file offline — un metodo che bypassa completamente gli artefatti sul DC attivo e richiede di estendere l'analisi ai sistemi di backup e virtualizzazione.

La timeline finale dovrebbe collegare: accesso iniziale al DC → escalation di privilegi → creazione shadow copy o esecuzione ntdsutil → accesso al file NTDS.dit → compressione → esfiltrazione, con ogni passaggio ancorato a un timestamp verificabile.

Con 17 gruppi che impiegano questa tecnica, il dump NTDS.dit è uno dei pochi denominatori comuni tra attori con motivazioni, capacità e geografie radicalmente diverse. L'analisi dei profili rivela pattern operativi che permettono di anticipare comportamenti futuri.

APT28 (G0007) — attore russo con focus su spionaggio geopolitico — ha utilizzato sia ntdsutil.exe che vssadmin in contesti diversi. Nella campagna Nearest Neighbor (C0051), condotta tra febbraio 2022 e novembre 2024 contro obiettivi legati all'Ucraina, APT28 ha creato shadow copy via vssadmin per il dump NTDS.dit, inserendo l'operazione in una catena d'attacco basata su tecniche living-off-the-land e sfruttamento zero-day di CVE-2022-38028. L'aspetto più innovativo di questa campagna è stata la tecnica di accesso iniziale via reti Wi-Fi adiacenti al bersaglio, con concatenamento di organizzazioni compromesse — un segnale che questo attore continua a evolvere nelle fasi iniziali della kill chain pur mantenendo tecniche consolidate nelle fasi post-compromissione.

Volt Typhoon (G1017) rappresenta una minaccia diversa: attore cinese orientato al pre-posizionamento in infrastrutture critiche. L'uso di ntdsutil per creare media di installazione del domain controller indica un approccio di raccolta credenziali massiva e sistematica, coerente con operazioni a lungo termine. Mustang Panda (G0129) e APT41 (G0096), anch'essi di nexus cinese, completano un cluster che predilige utility native — vssadmin e ntdsutil — preferendo la mimetizzazione nel rumore di fondo amministrativo.

Sul fronte cybercriminale, Wizard Spider (G0102) spicca per la sofisticazione operativa: combina shadow copy, ntdsutil e script batch automatizzati per il dump, segno di playbook maturi e standardizzati. FIN6 (G0037) ha impiegato il modulo PsExec NTDSGRAB di Metasploit, mentre FIN13 (G1016) ha scelto Impacket per la decrittazione locale — mostrando che i gruppi a motivazione finanziaria selezionano i tool in base all'ambiente vittima. Scattered Spider (G1015) e LAPSUS$ (G1004), entrambi gruppi con operatori giovani e tattiche aggressive, si distinguono per l'uso rispettivamente di shadow copy su domain controller virtualizzati e ntdsutil diretto.

L'operazione Cutting Edge (C0029), attribuita ad attori di nexus cinese, introduce un vettore che merita attenzione per il futuro: il montaggio di backup di dischi virtuali per l'estrazione offline, che elimina quasi completamente gli artefatti endpoint. Questo approccio, combinato con lo sfruttamento di vulnerabilità zero-day su appliance perimetrali (Ivanti Connect Secure), suggerisce una tendenza verso il dump "fuori banda" che complica significativamente la detection tradizionale.

Il pattern complessivo è chiaro: il dump NTDS.dit è una tecnica che non viene abbandonata né sostituita, ma adattata al contesto operativo. Gli attori più sofisticati stanno migrando verso metodi che minimizzano le tracce — DRSUAPI remoto, estrazione da backup virtualizzati — mentre gli operatori meno maturi continuano a fare affidamento su vssadmin e ntdsutil. Per i difensori, questo significa che la detection deve coprire l'intero spettro, dal più banale al più sofisticato.

Framework MITRE ATT&CK v16 — T1003.003 (OS Credential Dumping: NTDS), TA0006. Campagne: C0051 (APT28 Nearest Neighbor Campaign), C0048 (Operation MidnightEclipse), C0029 (Cutting Edge). Detection: DET0586 (AN1611). Integrato con conoscenza professionale per tool e procedure operative.