Contrôleur de domaine : la cible prioritaire des attaquants

Dans une mission Red Team, il existe un objectif non écrit qui revient systématiquement : compromettre le contrôleur de domaine. Pas parce que c'est le chemin le plus court, mais parce que c'est le plus décisif. Quand un attaquant contrôle le DC, il contrôle tout — les comptes, les politiques, les accès, les secrets. C'est le point de convergence de toute infrastructure Active Directory.

Cet article décrit les techniques réellement utilisées lors de tests d'intrusion, les mécanismes exploités, et les mesures concrètes pour durcir votre DC avant que quelqu'un d'autre ne le fasse à votre place.

Pourquoi le DC est une cible de choix

Le contrôleur de domaine centralise l'authentification Kerberos, la gestion des GPO, la base NTDS.dit (qui contient les hash de tous les mots de passe du domaine) et les relations d'approbation inter-domaines. Compromettre un DC, c'est obtenir ce qu'on appelle en jargon offensif le «Domain Admin» — le Graal de toute attaque sur environnement Windows.

La plupart des infrastructures d'entreprise, y compris au Maroc et en Afrique subsaharienne, reposent encore largement sur Active Directory. Ce n'est pas un reproche — c'est un constat. Et c'est précisément pour ça que les attaquants continuent d'y investir autant.

Les techniques d'attaque les plus utilisées

1. Kerberoasting

Un utilisateur du domaine peut demander un ticket de service (TGS) pour n'importe quel compte ayant un SPN enregistré. Ce ticket est chiffré avec le hash du compte de service ciblé. L'attaquant récupère le ticket, le sort du réseau et le craque hors ligne.

# Avec Rubeus
Rubeus.exe kerberoast /outfile:hashes.txt

# Puis crackage offline avec Hashcat
hashcat -m 13100 hashes.txt wordlist.txt

Le point critique : si le mot de passe du compte de service est faible ou n'a pas été changé depuis des années, le crackage prend quelques minutes.

2. DCSync — extraire NTDS.dit sans toucher au DC

DCSync est une technique qui abuse du protocole de réplication Active Directory. Un compte disposant des droits Replicating Directory Changes All peut simuler le comportement d'un contrôleur de domaine et demander la réplication des hash de comptes, y compris celui de krbtgt.

# Avec Mimikatz
lsadump::dcsync /domain:corp.local /user:Administrator

# Avec Impacket (depuis Linux)
secretsdump.py domain/user:password@dc_ip

Ce qui rend DCSync redoutable : il ne nécessite pas d'accès physique ou interactif au DC. Il suffit d'un compte avec les bons droits — et ces droits sont souvent accordés trop largement.

3. Golden Ticket — persistance totale sur le domaine

Une fois le hash NTLM du compte krbtgt obtenu, l'attaquant peut forger n'importe quel ticket Kerberos valide, pour n'importe quel utilisateur, sans aucune limite de durée. C'est le Golden Ticket.

# Création d'un Golden Ticket avec Mimikatz
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /krbtgt:<hash> /ptt

La persistance est quasi totale. Même si vous changez le mot de passe Administrator, l'attaquant conserve l'accès. Le seul remède : changer le mot de passe de krbtgt deux fois de suite.

Comment défendre son contrôleur de domaine

• Appliquer le Tiering Model. Le DC ne doit jamais être administré depuis une station de travail classique. Utilisez des PAW (Privileged Access Workstations) dédiées, cloisonnées du reste du réseau.
• Auditer les comptes de service. Chaque SPN enregistré est une surface d'attaque potentielle. Utilisez des Managed Service Accounts (gMSA) avec rotation automatique du mot de passe.
• Surveiller les droits de réplication. Aucun compte autre que les contrôleurs de domaine eux-mêmes ne devrait détenir Replicating Directory Changes All. Vérifiez via BloodHound — un attaquant le fera.
• Activer Protected Users et Credential Guard. Le groupe Protected Users désactive NTLM, la délégation Kerberos non contrainte, et la mise en cache des credentials pour les comptes sensibles.
• Monitorer avec précision. Les événements Windows ID 4768, 4769, 4771 (Kerberos), 4662 (accès objet AD) et 4742 (modification compte machine) sont vos indicateurs clés. Envoyez-les vers votre SIEM et construisez des règles de détection.
• Changer régulièrement le hash krbtgt. Un script Microsoft officiel (New-KrbtgtKeys.ps1) permet de le faire en minimisant l'impact opérationnel.

Ce que révèlent les missions Red Team

Sur la majorité des missions offensives menées dans des environnements Active Directory, la compromission du DC intervient en moins de 48 heures après le premier accès initial. Non pas parce que les outils sont magiques, mais parce que les fondamentaux ne sont pas en place : droits trop permissifs, comptes de service avec des mots de passe faibles, absence de segmentation entre les tiers d'administration.

BloodHound, exécuté en lecture seule sur un domaine, révèle en quelques minutes des chemins d'attaque que personne n'avait anticipés. C'est un outil que toute équipe défensive devrait utiliser avant les attaquants.

Si votre organisation n'a jamais soumis son Active Directory à un test d'intrusion ciblé, c'est probablement le premier investissement à faire — pas pour cocher une case de conformité, mais parce que le résultat sera instructif.