Personne ne « pirate » Domain Admin en un coup. On y arrive par une chaîne de petits droits légitimes : un compte de service au mot de passe faible, une délégation oubliée, un modèle de certificat trop permissif, un groupe de support qui peut modifier une stratégie de groupe. Voici comment lire ces chaînes, ce que dit l’ANSSI, un calculateur de chemins que nous avons testé, et dans quel ordre les couper.
Ce qu’il faut retenir
- Un « chemin de contrôle AD » est, selon l’ANSSI, « un chemin d’attaque spécifique reposant sur une suite de relations de contrôle logique entre objets de l’annuaire ». Il est créé par les administrateurs eux-mêmes, au fil des droits accordés.
- Un utilisateur sans privilèges suffit pour commencer. Le Kerberoasting, par exemple, peut être mené par n’importe quel utilisateur non privilégié, depuis n’importe quel ordinateur (ANSSI).
- Fermer un chemin n’en ferme pas d’autres. Dans notre exemple à quatre utilisateurs, aucune suppression d’une seule relation ne coupe plus d’un chemin sur quatre.
- Les autorités de certification font partie du périmètre le plus sensible. Le papier fondateur de SpecterOps (2021) décrit huit techniques d’escalade (ESC1 à ESC8), et recommande de traiter les autorités de certification comme des ressources du Tier 0.
- Le travail est itératif : analyser depuis un compte sans privilèges, supprimer les chemins qui entrent dans le Tier 0, recommencer à chaque changement.
Un chemin de contrôle, c’est quoi
Le guide « Recommandations relatives à l’administration sécurisée des systèmes d’information reposant sur Microsoft Active Directory » (ANSSI-PA-099, 2 octobre 2023) consacre une section entière aux chemins de contrôle. La définition à retenir : une suite de relations où chaque objet peut en contrôler un autre grâce à ses droits, par exemple parce qu’il a le droit de modifier son ACL, d’ajouter des membres à un groupe, ou de modifier une GPO.
L’ANSSI précise qu’ils sont « créés par les administrateurs lors de l’octroi de droits et privilèges sur des objets de l’AD tout au long du cycle de vie de l’annuaire, par modification d’ACL, par ajout d’utilisateurs à des groupes privilégiés, par délégations de droits sur des OU ou des GPO », et que des chemins « anormaux et suspects » peuvent être le signe d’une compromission, ancienne ou récente, par un attaquant qui a cherché à consolider sa persistance. Le guide illustre par deux exemples, dont l’un passe par le groupe « Opérateurs d’impression » qui permet de charger un pilote malveillant sur un contrôleur de domaine, et l’autre par des droits de modification sur une GPO.
Les maillons qui reviennent
| Maillon | Ce que c’est | Pourquoi c’est un chemin | Ce que dit la source |
|---|---|---|---|
| Compte de service avec SPN (Kerberoasting) | Un compte utilisateur qui porte un SPN Kerberos | N’importe quel utilisateur peut demander un ticket de service, chiffré avec le condensat du mot de passe du compte, et tenter de le casser hors ligne | ANSSI, section 4.13 et recommandation R69 : proscrire les comptes utilisateurs avec SPN dans le Tier 0 |
| Délégation Kerberos non contrainte | Un service peut endosser l’identité des utilisateurs qui s’y connectent, auprès de toutes les ressources | Si un administrateur du Tier 0 s’y connecte, son secret est en mémoire et réutilisable partout | ANSSI : réserver ces délégations au Tier 0, idéalement aux contrôleurs de domaine seulement |
| Groupes, ACL, GPO, OU délégués | Droits d’écriture sur un groupe, une OU ou une GPO | Chaque droit de modification est une relation de contrôle ; un groupe de support peut devenir administrateur de fait | ANSSI, section 3.2 : chemins via conteneurs système, groupes intégrés, approbations |
| Sessions et comptes locaux | Un administrateur de domaine ouvert sur une machine moins protégée ; un même mot de passe administrateur local partout | Le secret réutilisable en mémoire ou le mot de passe local partagé donne la machine, puis le compte | ANSSI, R30 : diversifier et renouveler les mots de passe des administrateurs locaux (LAPS) |
| Services de certificats (AD CS) | Modèles de certificats, droits sur l’autorité, points d’inscription HTTP | Un modèle mal configuré permet de demander un certificat au nom d’un autre compte | SpecterOps, ESC1 à ESC8 ; ANSSI, R37 et R20 |
AD CS : ESC1 en une phrase
Dans « Certified Pre-Owned » (Will Schroeder et Lee Christensen, juin 2021), la technique ESC1 est l’« escalade de domaine via un modèle sans exigence d’émission, ouvert à l’inscription, avec une utilisation d’authentification cliente ou d’ouverture de session par carte à puce, et le drapeau CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT ». En clair : un utilisateur ordinaire peut demander un certificat en indiquant le nom de son choix, et l’utiliser ensuite pour s’authentifier comme un administrateur. Les huit techniques (ESC1 à ESC8) couvrent aussi le contrôle d’accès des modèles (ESC4), des objets PKI (ESC5), l’option EDITF_ATTRIBUTESUBJECTALTNAME2 des autorités (ESC6), les droits sur l’autorité (ESC7) et le relais NTLM vers les points d’inscription HTTP (ESC8). Le papier recommande notamment de traiter les autorités de certification comme des ressources du Tier 0 (PREVENT1) et d’appliquer une correspondance stricte des comptes (PREVENT7). D’autres chercheurs ont depuis documenté des variantes au-delà d’ESC8, par exemple ESC13.
Un calculateur de chemins, testé
Les outils publics comme BloodHound (cité par l’ANSSI, « maintenu par BloodHound Enterprise ») font exactement ce calcul sur un annuaire réel. Pour en comprendre le principe, voici un calculateur minimal en Python (bibliothèque standard uniquement), sur un graphe d’exemple fabriqué pour cet article, inspiré des chemins que décrit l’ANSSI. Chaque relation signifie « la source peut prendre le contrôle de la cible » :
#!/usr/bin/env python3
"""Chemins de contrôle vers Domain Admins sur un graphe d'exemple (bibliothèque standard uniquement)."""
from collections import deque
# (source, cible, relation) : « source peut prendre le contrôle de cible »
EDGES = [
("alice", "Print Operators", "MemberOf"),
("Print Operators", "DC01", "SeLoadDriverPrivilege"),
("bob", "OU Lyon", "WriteOU"),
("OU Lyon", "Assistance Lyon", "Contains"),
("Assistance Lyon", "Admins postes", "MemberOf"),
("Admins postes", "GPO DC", "WriteGPO"),
("GPO DC", "DC01", "AppliedTo"),
("alice", "svc_sql", "Kerberoast"),
("bob", "svc_sql", "Kerberoast"),
("carol", "svc_sql", "Kerberoast"),
("dave", "svc_sql", "Kerberoast"),
("svc_sql", "SQL Admins", "MemberOf"),
("SQL Admins", "SRV-SQL01", "AdminTo"),
("SRV-SQL01", "adm_tier0", "HasSession"),
("dave", "Modele Web", "Enroll"),
("Modele Web", "Domain Admins", "ESC1"),
("dave", "SRV-APP", "LocalAdmin"),
("SRV-APP", "adm_tier0", "HasSession"),
("adm_tier0", "Domain Admins", "MemberOf"),
("DC01", "Domain Admins", "Controls"),
]
USERS = ["alice", "bob", "carol", "dave"]
TARGET = "Domain Admins"
def shortest(edges, src, dst=TARGET):
adj = {}
for a, b, r in edges:
adj.setdefault(a, []).append((b, r))
q, seen = deque([(src, [])]), {src}
while q:
node, path = q.popleft()
if node == dst:
return path
for nxt, rel in adj.get(node, []):
if nxt not in seen:
seen.add(nxt)
q.append((nxt, path + [(node, rel, nxt)]))
return None
def report(edges):
paths = {u: shortest(edges, u) for u in USERS}
for u, p in paths.items():
print(f"{u:<6}", " -> ".join([f"{u}"] + [f"[{r}] {b}" for _, r, b in p]) if p else "aucun chemin")
return paths
if __name__ == "__main__":
print("== Plus courts chemins vers", TARGET)
report(EDGES)
print("\n== Une seule relation supprimée : combien d'utilisateurs atteignent encore Domain Admins ?")
base = sum(shortest(EDGES, u) is not None for u in USERS)
rows = []
for e in EDGES:
left = [x for x in EDGES if x != e]
rows.append((sum(shortest(left, u) is not None for u in USERS), e))
for n, (a, b, r) in sorted(rows, key=lambda x: x[0])[:3]:
print(f" sans {a} -[{r}]-> {b} : {n}/{base}")
print("\n== Après correction : Kerberoast supprimé (comptes de service sans mot de passe faible), ESC1 corrigé, délégation retirée, sessions Tier 0 interdites")
fixed = [e for e in EDGES if e[2] not in ("Kerberoast", "ESC1") and not (e[1] == "adm_tier0")]
report(fixed)Résultat de l’exécution :
== Plus courts chemins vers Domain Admins
alice alice -> [MemberOf] Print Operators -> [SeLoadDriverPrivilege] DC01 -> [Controls] Domain Admins
bob bob -> [Kerberoast] svc_sql -> [MemberOf] SQL Admins -> [AdminTo] SRV-SQL01 -> [HasSession] adm_tier0 -> [MemberOf] Domain Admins
carol carol -> [Kerberoast] svc_sql -> [MemberOf] SQL Admins -> [AdminTo] SRV-SQL01 -> [HasSession] adm_tier0 -> [MemberOf] Domain Admins
dave dave -> [Enroll] Modele Web -> [ESC1] Domain Admins
== Une seule relation supprimée : combien d'utilisateurs atteignent encore Domain Admins ?
sans carol -[Kerberoast]-> svc_sql : 3/4
sans svc_sql -[MemberOf]-> SQL Admins : 3/4
sans SQL Admins -[AdminTo]-> SRV-SQL01 : 3/4
== Après correction : Kerberoast supprimé (comptes de service sans mot de passe faible), ESC1 corrigé, délégation retirée, sessions Tier 0 interdites
alice alice -> [MemberOf] Print Operators -> [SeLoadDriverPrivilege] DC01 -> [Controls] Domain Admins
bob bob -> [WriteOU] OU Lyon -> [Contains] Assistance Lyon -> [MemberOf] Admins postes -> [WriteGPO] GPO DC -> [AppliedTo] DC01 -> [Controls] Domain Admins
carol aucun chemin
dave aucun chemin
Trois constats se lisent immédiatement. Dave n’est qu’à deux relations de Domain Admins, à cause d’un modèle de certificat. Bob et carol passent par le même compte de service Kerberoastable. Et supprimer une relation isolée ne ferme qu’un seul chemin : le résultat « 3/4 » signifie que trois utilisateurs sur quatre atteignent encore Domain Admins. Après correction des mots de passe des comptes de service, du modèle de certificat, de la délégation et des sessions Tier 0, il reste pourtant deux chemins : ceux d’alice (Opérateurs d’impression) et de bob (délégation d’écriture sur une OU), qui sont précisément les deux familles que l’ANSSI illustre dans son guide. Les chemins hérités sont les plus durs à voir et à retirer.
Corriger dans le bon ordre
L’ANSSI propose une démarche itérative, qu’on peut résumer ainsi (section 3.2.4) :
- Analyser l’annuaire avec un outil de chemins de contrôle (BloodHound, PingCastle, ADTimeLine, ou le service ADS de l’ANSSI pour les entités éligibles), avec un compte sans privilèges et depuis un poste du Tier 2, comme le préconise le guide.
- Chercher les chemins vers chaque objet du Tier 0 connu (contrôleurs de domaine, groupes d’administration, objets sensibles listés en annexe A du guide).
- Pour chaque chemin, vérifier qu’il ne vient que d’objets eux-mêmes du Tier 0. Sinon, supprimer la relation ou faire entrer l’objet dans le Tier 0.
- Recommencer à chaque changement de catégorisation. L’ANSSI rappelle que ces outils ne voient que l’annuaire : ils ne représentent qu’une partie des chemins d’attaque possibles.
Les corrections que l’ANSSI et SpecterOps recommandent explicitement : aucun compte utilisateur avec SPN dans le Tier 0 (R69, ANSSI) ; les délégations non contraintes réservées au Tier 0 (ANSSI) ; des mots de passe administrateur local diversifiés (R30, ANSSI) ; les autorités de certification traitées comme du Tier 0 (PREVENT1, SpecterOps). À notre avis, il faut y ajouter des secrets longs et aléatoires pour tous les comptes de service, puisque le Kerberoasting attaque précisément le mot de passe du compte.
Pour trouver les comptes exposés au Kerberoasting, l’ANSSI fournit elle-même ce script PowerShell (listing 11 du guide, que nous n’avons pas exécuté faute de domaine Windows dans notre banc d’essai) :
Get-ADUser -filter * -Properties * |
Where {$_.ServicePrincipalName -ne $null -and $_.Name -ne "krbtgt"} |
Select Name, ServicePrincipalNameLe compte krbtgt est exclu, car aucun ticket de service ne peut être émis pour lui.
Voir l’attaque pendant qu’elle se déroule
Chaque maillon laisse une trace. Le Kerberoasting apparaît sous forme de rafales d’événements 4769 en RC4, les créations de comptes et ajouts à des groupes privilégiés sous forme d’événements 4720 et 4728, la réplication de l’annuaire sous forme d’événements 4662. Notre article sur les 15 événements Windows qui trahissent un attaquant détaille ces événements, avec un script de détection testé sur des données de démonstration.
Les pièges à éviter
- Corriger un chemin à la fois sans recalculer. Un chemin fermé peut en révéler un autre plus long mais toujours praticable ; il faut relancer l’analyse.
- Lancer l’analyse avec un compte d’administrateur depuis un poste sensible. L’ANSSI recommande un compte sans privilèges, depuis un poste du Tier 2 : c’est aussi ce que ferait l’attaquant.
- Traiter les comptes de service comme des utilisateurs. Un mot de passe choisi par un humain est plus facile à casser hors ligne qu’un secret aléatoire long ; les comptes de service devraient avoir des secrets que personne ne saisit.
- Oublier les certificats. Un AD réputé propre peut rester escaladable par un modèle de certificat ; les autorités de certification appartiennent au Tier 0.
- Laisser des comptes de support dans les groupes intégrés comme Opérateurs d’impression : l’exemple du guide de l’ANSSI montre qu’ils peuvent mener à un contrôleur de domaine.
- Croire que l’outil voit tout. Selon l’ANSSI, ces outils se limitent globalement à l’analyse de l’annuaire, et leurs résultats ne représentent qu’une partie des chemins d’attaque possibles.
Huit questions pour votre annuaire
- Quel est le plus court chemin de contrôle entre un utilisateur ordinaire et Domain Admins, et l’avez-vous calculé ?
- Combien de comptes utilisateurs portent un SPN, et lesquels sont dans des groupes privilégiés ?
- Quelles ressources ont une délégation Kerberos non contrainte ?
- Les mots de passe administrateur local sont-ils uniques par machine et renouvelés (LAPS) ?
- Qui peut modifier les GPO liées aux contrôleurs de domaine, et les groupes qui y ont accès ?
- Les modèles de certificats et les autorités ont-ils été audités, en particulier pour ESC1 ?
- Des administrateurs Tier 0 ouvrent-ils des sessions sur des machines moins protégées ?
- Qui est alerté quand un compte est ajouté à un groupe privilégié ?
En résumé
Domain Admin n’est presque jamais atteint par une faille unique : c’est un parcours de droits légitimes que des administrateurs ont accordés au fil des années. Le remède est aussi un parcours : calculer les chemins comme le ferait l’attaquant, supprimer ceux qui entrent dans le Tier 0, recommencer. Notre calculateur de démonstration est volontairement minuscule ; sur un vrai annuaire, utilisez un outil spécialisé, avec un compte sans privilèges, et traitez les résultats comme une liste de travaux, pas comme un score.
Transparence : cet article a été rédigé avec l’aide d’un assistant Claude. Les définitions, recommandations et numéros cités (R20, R30, R37, R69, sections 3.2 et 4.13) proviennent du guide ANSSI-PA-099 du 2 octobre 2023 ; les techniques ESC1 à ESC8 du papier « Certified Pre-Owned » version 1.0.1. Le graphe et le script adpaths.py ont été fabriqués pour l’article et exécutés ; ils illustrent le principe, ils ne mesurent aucun annuaire réel. Le script PowerShell est celui de l’ANSSI et n’a pas été exécuté. Références consultées en septembre 2026.
À lire aussi
- Les 15 événements Windows qui trahissent un attaquant : comment voir ces chemins dans les journaux, avec un script de détection testé.
- MFA : toutes les authentifications fortes ne se valent pas : la première marche : empêcher le vol d’identifiants.
Sources
- ANSSI, « Recommandations relatives à l’administration sécurisée des systèmes d’information reposant sur Microsoft Active Directory » (ANSSI-PA-099, 2 octobre 2023) : cyber.gouv.fr
- SpecterOps, Will Schroeder et Lee Christensen, « Certified Pre-Owned: Abusing Active Directory Certificate Services » (version 1.0.1, juin 2021) : specterops.io
- SpecterOps, « ADCS ESC13 Abuse Technique » (14 février 2024) : specterops.io
- MITRE ATT&CK, T1558.003 Kerberoasting : attack.mitre.org
- KillChain, « Les 15 événements Windows qui trahissent un attaquant » : killchain.fr