NTDS.dit Dump

Qu'est-ce qu'un NTDS.dit Dump ?

Un NTDS.dit dump désigne l'extraction du fichier NTDS.dit, la base de données qui constitue le cœur d'un annuaire Active Directory. Ce fichier, situé par défaut dans C:\Windows\NTDS\ntds.dit sur chaque contrôleur de domaine, contient l'intégralité des objets du domaine : utilisateurs, groupes, ordinateurs, unités d'organisation — et surtout les empreintes (hashes) NT de tous les mots de passe du domaine, y compris ceux des comptes à privilèges et du compte krbtgt.

Obtenir ce fichier revient à obtenir les clés du royaume. Un attaquant qui exfiltre NTDS.dit peut casser les mots de passe hors ligne à son rythme, rejouer les hashes via Pass-the-Hash, ou forger des Golden Tickets Kerberos valides pendant des années. C'est pourquoi cette technique — référencée T1003.003 dans le framework MITRE ATT&CK — figure parmi les objectifs finaux de la quasi-totalité des opérations de ransomware ciblant les environnements Windows.

Fonctionnement technique

NTDS.dit est une base ESE (Extensible Storage Engine, le même moteur que Jet Blue et Exchange). Sa structure repose sur trois tables principales : datatable (les objets et leurs attributs), link_table (les relations, notamment les appartenances aux groupes) et sd_table (les descripteurs de sécurité).

Les secrets ne sont pas stockés en clair : chaque hash est chiffré avec la PEK (Password Encryption Key), elle-même chiffrée par la BOOTKEY (ou SYSKEY) dérivée de la ruche de registre SYSTEM. Un dump exploitable exige donc deux artefacts : le fichier NTDS.dit et une copie de la ruche SYSTEM. Sans la seconde, la base reste inexploitable.

Le fichier étant verrouillé en permanence par le service lsass.exe, une simple copie échoue. Les attaquants contournent cette limitation par plusieurs voies :

• Volume Shadow Copy (VSS) : création d'un cliché instantané du volume, puis copie du fichier depuis le snapshot. Exemples : vssadmin create shadow /for=C:, ou l'outil diskshadow.exe piloté par script — technique dite « living off the land » car elle n'utilise que des binaires signés Microsoft.
• ntdsutil : la commande native ntdsutil "ac i ntds" "ifm" "create full C:\temp" génère un média d'installation contenant à la fois la base et la ruche SYSTEM. Rapide, légitime en apparence, redoutablement efficace.
• esentutl ou Invoke-NinjaCopy : lecture brute du volume NTFS pour contourner le verrou de fichier.
• DCSync : la méthode la plus discrète. Plutôt que de toucher au disque, l'attaquant se fait passer pour un contrôleur de domaine et demande la réplication des secrets via le protocole MS-DRSR (appel DRSGetNCChanges). Aucun accès au DC n'est nécessaire : il suffit de disposer des droits DS-Replication-Get-Changes et DS-Replication-Get-Changes-All, souvent hérités par les membres de Domain Admins, Enterprise Admins ou par des ACL mal configurées. Outils typiques : mimikatz lsadump::dcsync /all ou secretsdump.py -just-dc domaine/user@ip.

L'exploitation hors ligne s'effectue ensuite avec secretsdump.py (Impacket), DSInternals ou NTDSDumpEx, qui produisent une liste au format utilisateur:RID:LM:NT:::, directement injectable dans Hashcat (mode 1000) ou dans un outil de mouvement latéral.

Exemples concrets

Le scénario classique observé en réponse à incident : compromission d'un poste utilisateur par phishing, escalade de privilèges locale, récupération d'identifiants en mémoire via un dump LSASS, découverte d'un chemin d'attaque vers un compte administrateur (souvent mis en évidence par BloodHound), puis DCSync depuis ce compte. Le tout peut se dérouler en moins de deux heures. Les groupes ransomware comme Conti ou LockBit documentaient explicitement cette séquence dans leurs manuels opérationnels internes.

Concepts liés

Le NTDS.dit dump s'inscrit dans une chaîne d'attaque : il est alimenté par le Kerberoasting, l'AS-REP Roasting ou le vol de credentials en mémoire, et il alimente à son tour le Pass-the-Hash, le Golden Ticket (via le hash krbtgt) et le Silver Ticket. Il constitue la matérialisation ultime de la compromission du Tier 0.

Bonnes pratiques de défense

• Modèle en tiers : isoler strictement les comptes Tier 0 ; jamais d'authentification d'un administrateur du domaine sur un poste de travail.
• Auditer les ACL de réplication : recenser régulièrement les principals disposant de DS-Replication-Get-Changes-All hors comptes système légitimes.
• Détection : surveiller l'événement 4662 corrélé au GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 depuis une source non-DC, les événements VSS 8222/8224, et l'exécution de ntdsutil.exe ou diskshadow.exe (événement 4688).
• Durcir les DC : accès physique et virtuel restreint (un snapshot d'hyperviseur d'un DC équivaut à un dump), chiffrement des sauvegardes, RODC en site distant.
• Comptes protégés : groupe Protected Users, LAPS pour les comptes locaux, gMSA pour les comptes de service.
• Après compromission avérée : rotation du mot de passe krbtgt deux fois à intervalle supérieur à la durée de vie des tickets, sous peine de laisser les Golden Tickets valides.
• Surveillance comportementale : Microsoft Defender for Identity ou un SIEM avec règles Sigma dédiées détectent efficacement DCSync et les créations de shadow copies anormales.