Chemins d'Attaque AD : Mauvaises Configurations en Chaîne

Que sont les Active Directory Attack Paths ?

Les chemins d'attaque Active Directory sont des chaînes de relations — appartenances aux groupes, permissions ACL, liens GPO, configurations de délégation, comptes kerberoastables — qui relient un attaquant peu privilégié à Domain Admin. Aucune mauvaise configuration isolée n'a besoin d'être critique en soi : ce qui compte, c'est si elles peuvent être enchaînées.

Les adversaires modernes n'exploitent pas des vulnérabilités individuelles. Ils cartographient l'ensemble de l'environnement Active Directory comme un graphe, identifient le chemin le plus court depuis leur position actuelle jusqu'à Domain Admin, et suivent ce chemin — un saut à la fois. Chaque saut exploite une mauvaise configuration différente : un mot de passe craqué, un chemin d'imbrication de groupes, une ACL exploitable, ou un certificat falsifié.

Cet article couvre les trois catégories de chemins les plus fiables : les chemins ACL, les chemins GPO et les chemins de Kerberoasting vers Domain Admin.

Comment fonctionnent les Active Directory Attack Paths

L'analyse des chemins d'attaque traite Active Directory comme un graphe orienté :

• Nœuds = utilisateurs, ordinateurs, groupes, GPO, OU, domaines
• Arêtes = relations pouvant être exploitées (MemberOf, GenericAll, WriteDACL, GpLink, etc.)

Des outils comme BloodHound (open source) collectent ces données de graphe et utilisent Neo4j pour trouver les chemins les plus courts entre deux nœuds quelconques. Un attaquant exécutant BloodHound depuis un compte utilisateur standard compromis peut visualiser l'ensemble du chemin vers Domain Admin en quelques minutes — trouvant souvent des chemins qui ont nécessité des années de mauvaises configurations accumulées pour se créer.

Catégories de chemins courantes

La chaîne d'attaque

Étape 1 - Collecter les données du graphe AD

# Depuis Linux avec des identifiants valides — collecteur BloodHound CE (pip install bloodhound-ce)
bloodhound-ce-python -u [email protected] -p password -ns 10.10.0.1 -d corp.local -c All --zip

# bloodhound-python (pip install bloodhound) est le collecteur legacy : uniquement BloodHound 4.2/4.3

# Depuis Windows
.\SharpHound.exe -c All --zipfilename corp_bloodhound.zip

Étape 2 - Trouver les chemins les plus courts vers Domain Admin

Dans l'interface BloodHound ou le navigateur Neo4j :

// Chemin le plus court depuis n'importe quel utilisateur vers Domain Admins
MATCH p=shortestPath((u:User {enabled:true})-[*1..]->(g:Group {name:"DOMAIN [email protected]"}))
RETURN p ORDER BY length(p) ASC LIMIT 10

// Trouver tous les utilisateurs kerberoastables avec un chemin vers DA
MATCH (u:User {hasspn:true})-[*1..]->(g:Group {name:"DOMAIN [email protected]"})
RETURN u.name, u.pwdlastset

// Trouver les chemins de droits d'édition GPO vers les DC
MATCH p=(u:User)-[:GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner*1..]->(g:GPO)-[:GPLink]->(c:OU)
WHERE c.blocksinheritance = false
RETURN p

Étape 3 - Suivre le chemin le plus court

Un chemin réel typique :

1. L'attaquant compromet jsmith (utilisateur standard) via phishing
2. jsmith a GenericWrite sur svc_deploy (reste d'un projet antérieur)
3. svc_deploy est kerberoastable avec un mot de passe vieux de 3 ans
4. L'attaquant écrit un SPN sur svc_deploy via GenericWrite et craque le ticket de service résultant (Kerberoasting ciblé), ou écrit msDS-KeyCredentialLink pour les Shadow Credentials — GenericWrite seul ne permet pas une réinitialisation de mot de passe, qui nécessite ForceChangePassword ou GenericAll
5. svc_deploy est membre du groupe IT_Admins
6. IT_Admins est imbriqué dans Domain Admins
7. Compromission totale du domaine — 3 sauts de graphe, aucun exploit

Étape 4 - Maintenir la persistance

Une fois l'accès DA obtenu, l'attaquant établit sa persistance via un Golden Ticket, de nouveaux comptes backdoor, ou des backdoors de certificats ADCS — s'assurant de survivre aux réinitialisations de mot de passe et aux tentatives de remédiation.

Détection

Détecter la traversée d'un chemin d'attaque nécessite de surveiller chaque saut individuel — aucune entrée de journal unique ne révèle le chemin complet.

Event ID Windows

Requête de corrélation SIEM

KQL ne fait que filtrer des documents — il ne peut pas agréger — la corrélation elle-même est donc exprimée en ES|QL :

// Détecter des événements séquentiels rapides d'escalade de privilèges depuis la même source
FROM logs-*
| WHERE event.code IN ("4769", "4724", "4728", "5136")
    AND @timestamp > NOW() - 1 hour
| STATS event_count = COUNT(*) BY winlog.event_data.SubjectUserName
| WHERE event_count > 3

Remediation

1. Éliminer d'abord les chemins les plus courts

Exécutez BloodHound et exportez les 10 chemins les plus courts vers Domain Admin. Pour chaque chemin :

• Arête ACL : supprimez l'ACE dangereuse de l'objet
• Arête d'imbrication de groupes : retirez le groupe du groupe privilégié
• Arête kerberoastable : changez le mot de passe ou migrez vers gMSA
• Arête GPO : retirez les droits d'édition du compte non-admin

2. Mettre en place une surveillance continue des chemins d'attaque

# Collecte hebdomadaire BloodHound via tâche planifiée
# SharpHound est un exécutable natif : passez les flags explicitement (le splatting de hash-table ne
# se lie qu'aux cmdlets PowerShell, pas à un .exe)
.\SharpHound.exe -c All `
    --outputdirectory "C:\BloodHound\Collections\" `
    --zipfilename "weekly_$(Get-Date -Format yyyyMMdd).zip"
# Comparer avec les données de la semaine précédente et alerter sur les nouveaux chemins DA

3. Prioriser les comptes kerberoastables sur le chemin DA

# Trouver tous les comptes kerberoastables ayant un chemin quelconque vers des privilèges DA
# -Filter attend une chaîne ; krbtgt porte un SPN mais n'est pas roastable en pratique
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties MemberOf, PasswordLastSet |
    Where-Object { $_.SamAccountName -ne "krbtgt" } |
    Where-Object {
        $_.MemberOf | Get-ADGroup | Where-Object { $_.Name -match "Admin" }
    } | Select-Object SamAccountName, PasswordLastSet
# Migrer ces comptes vers gMSA immédiatement

Comment EtcSec détecte cela

EtcSec effectue une analyse continue des chemins d'attaque sur l'ensemble de votre graphe Active Directory, identifiant tous les chemins depuis des comptes peu privilégiés jusqu'à Domain Admin.

PATH_ACL_TO_DA cartographie chaque chemin basé sur les ACL depuis des utilisateurs standards vers Domain Admin, y compris les chaînes à sauts multiples via des objets intermédiaires.

PATH_GPO_TO_DA identifie les chemins où des droits d'édition GPO sur des stratégies liées à des OU Tier 0 fournissent un chemin indirect vers la compromission d'un contrôleur de domaine.

PATH_KERBEROASTING_TO_DA signale les comptes de service kerberoastables disposant — directement ou de manière transitive — de privilèges Domain Admin, représentant le chemin d'attaque à fort impact le plus courant dans les environnements réels.

Priorités de revue

Les chemins d'attaque Active Directory vers Domain Admin doivent être traités comme une exposition réelle au sein de votre parc Active Directory, pas comme un simple paramètre isolé. Commencez par définir le périmètre de revue : quels groupes privilégiés, comptes de service, ACL, liens GPO, trusts, configurations de délégation, modèles de certificats et postes d'administration sont concernés, quels flux métier en dépendent, quels privilèges ils exposent, et quelles exceptions d'urgence ont été ajoutées au fil du temps. Cette étape de cadrage évite une remédiation superficielle, car le symptôme technique est souvent plus réduit que le rayon d'impact opérationnel. En documentant le chemin complet de la configuration au privilège, l'équipe peut prioriser les changements qui réduisent le risque rapidement sans casser les accès de production. Cela crée aussi une base défendable pour une validation ultérieure et donne à la direction une explication claire de l'importance du sujet aujourd'hui.

Contrôles adjacents à revoir

Lorsque les attaquants atteignent votre parc Active Directory, ils s'arrêtent rarement au premier point faible. Autour des chemins d'attaque Active Directory vers Domain Admin, ils testent généralement si le chemin exposé peut être enchaîné avec des comptes privilégiés obsolètes, une imbrication de groupes dangereuse, une délégation excessive, des politiques de mot de passe faibles, des chemins GPO inscriptibles et un abus d'ACL héritées. Les défenseurs doivent donc revoir non seulement la faiblesse principale, mais aussi chaque dépendance voisine qui transforme un accès en persistance ou en escalade de privilèges. Confirmez quelles identités, rôles, permissions et hypothèses de confiance peuvent être réutilisées par un opérateur motivé. Si un correctif ne ferme qu'un seul objet en laissant intacts des chemins de privilège adjacents, le risque effectif change à peine. Une revue disciplinée des possibilités d'enchaînement est ce qui transforme ce sujet en un exercice de durcissement pratique plutôt qu'en simple case à cocher.

Preuves et télémétrie à collecter

Une réponse solide aux chemins d'attaque Active Directory vers Domain Admin nécessite des preuves que les équipes d'ingénierie et de détection peuvent examiner ensemble. Collectez les Event ID 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, les changements SYSVOL et l'activité des certificats ou de l'autorité de certification, comparez les changements récents avec les fenêtres de maintenance connues, et isolez les comptes ou systèmes dont le comportement a changé sans raison métier claire. Utilisez ces preuves pour répondre à trois questions : quand le chemin risqué est-il apparu, qui peut encore l'utiliser, et une exposition similaire existe-t-elle ailleurs dans votre parc Active Directory. Une bonne revue de la télémétrie aide aussi à distinguer la dette technique héritée de l'abus actif. Cette distinction compte, car le plan de remédiation pour une mauvaise configuration ancienne diffère de celui pour un chemin qui montre déjà une activité proche de celle d'un attaquant ou des exceptions de politique répétées.

Faiblesses adjacentes à examiner

Très peu d'environnements ne contiennent que des chemins d'attaque Active Directory vers Domain Admin. En pratique, le même segment de tenant ou d'annuaire contient souvent aussi des comptes privilégiés obsolètes, une imbrication de groupes dangereuse, une délégation excessive, des politiques de mot de passe faibles, des chemins GPO inscriptibles et un abus d'ACL héritées, et ce sont ces faiblesses voisines qui déterminent si le problème reste simplement bruyant ou devient vraiment critique. Revoyez les propriétaires partagés, les permissions héritées, les exceptions dupliquées et les raccourcis administratifs de longue durée. Vérifiez si la même équipe a approuvé des schémas à risque similaires à plusieurs endroits, car des décisions répétées indiquent généralement une lacune de processus plutôt qu'un bug technique isolé. Cette revue plus large évite un nettoyage partiel et augmente vos chances d'éliminer le chemin d'attaque dans son ensemble. Elle améliore aussi la préparation aux audits, car l'état final est plus facile à expliquer et à surveiller dans la durée.

Lectures associées

Consultez ce sujet avec Abus d'ACL et DCSync : les chemins silencieux vers Domain Admin, Imbrication dangereuse de groupes AD : chemins cachés vers Domain Admin, Attaques de confiance Active Directory : du domaine enfant à la racine de la forêt, Mauvaises configurations GPO : comment Group Policy devient un vecteur d'attaque, et Supervision Active Directory : les Event ID de sécurité qui comptent. Ces articles connexes montrent comment les mêmes faiblesses d'identité s'enchaînent généralement lors d'une évaluation réelle, au lieu d'apparaître comme des constats isolés.

• Abus d'ACL et DCSync : les chemins silencieux vers Domain Admin
• Imbrication dangereuse de groupes AD : chemins cachés vers Domain Admin
• Attaques de confiance Active Directory : du domaine enfant à la racine de la forêt
• Mauvaises configurations GPO : comment Group Policy devient un vecteur d'attaque
• Supervision Active Directory : les Event ID de sécurité qui comptent

L'utilisation de ces références permet de garder la discussion de remédiation centrée sur le chemin d'attaque complet plutôt que sur une seule lacune de contrôle.

Liste de validation

Avant de clôturer la revue, relancez les mêmes vérifications qui ont révélé le problème et confirmez que le chemin risqué n'existe plus du point de vue de l'attaquant. Vérifiez les identités, privilèges, chemins d'héritage et contrôles compensatoires pertinents en production, pas seulement en staging ou dans la documentation. Consignez le propriétaire technique, la dépendance métier attendue, et la preuve que la nouvelle configuration est à la fois plus sûre et opérationnellement soutenable. Cette dernière étape de validation est ce qui garde l'article ancré dans la manière dont les équipes réduisent réellement le risque identitaire.