Escalade de privilèges AD

D'un accès de faible privilège à la compromission du domaine

L'escalade de privilèges dans Active Directory ressemble rarement à l'exploitation d'une vulnérabilité logicielle classique, avec un CVE et un correctif unique. Elle consiste, dans l'immense majorité des cas réels, à enchaîner des droits mal configurés — chacun anodin pris isolément — jusqu'à atteindre un compte, un groupe ou un objet qui contrôle le domaine. Un attaquant qui compromet un compte utilisateur standard via phishing ne cherche pas une faille zero-day : il cherche le chemin le plus court entre ce compte et Domain Admins, en s'appuyant sur des années d'accumulation de droits accordés pour des raisons opérationnelles ponctuelles et jamais révoquées.

Ce chapitre couvre trois familles d'abus qui composent l'essentiel des chemins d'escalade observés en engagement réel : l'abus d'ACL sur les objets AD, l'abus de droits d'édition sur les GPO, et une introduction aux services de certificats Active Directory (ADCS), dont les gabarits mal configurés constituent depuis quelques années l'un des vecteurs d'escalade les plus fiables et les moins détectés. Nous terminons sur la façon de prioriser ces découvertes dans un rapport, car toutes les ACL permissives ne se valent pas en termes de risque métier réel. Tout ce qui suit suppose un accès déjà authentifié au domaine, même à faible privilège, et une cartographie construite lors des chapitres précédents : l'escalade n'est jamais la première étape d'un engagement, elle exploite une reconnaissance préalable.

Abus d'ACL : le levier le plus commun

Chaque objet Active Directory — utilisateur, groupe, ordinateur, OU, voire le domaine lui-même — possède une liste de contrôle d'accès discrétionnaire (DACL) qui définit qui peut faire quoi dessus. Ces droits sont accordés au fil du temps pour des besoins légitimes : un administrateur applicatif qui doit pouvoir réinitialiser les mots de passe de son équipe, un outil d'automatisation qui doit pouvoir modifier des attributs, un compte de service historique conservé après le départ de son créateur. Le problème n'est pas que ces droits existent, c'est qu'ils s'accumulent sans jamais être révoqués ni audités globalement.

Les droits les plus recherchés par un attaquant lors de cette phase :

Le cas DCSync mérite un développement séparé : ces deux droits de réplication, normalement réservés aux contrôleurs de domaine et à quelques comptes de service de réplication légitimes (Azure AD Connect, par exemple), permettent à quiconque les détient de se faire passer pour un contrôleur de domaine et de demander la réplication de n'importe quel secret, y compris le hash du compte krbtgt — la clé de voûte de tout le domaine Kerberos. Un attaquant qui obtient ces droits sur un compte compromis, même à première vue anodin, obtient en pratique l'équivalent d'un accès Domain Admin permanent.

Un compte de service svc_helpdesk, créé cinq ans plus tôt pour permettre à l'outil de ticketing de réinitialiser les mots de passe utilisateurs, s'est vu accorder GenericAll sur l'OU Utilisateurs — une délégation large, plus simple à configurer à l'époque qu'une délégation fine limitée au seul droit ForceChangePassword. Ce compte, kerberoastable et doté d'un mot de passe jamais renouvelé, tombe en quelques minutes lors du test. Le mot de passe cassé donne accès à GenericAll sur toute l'OU utilisateurs, y compris sur des comptes membres indirects de groupes à privilège. Un chemin d'escalade complet découle d'une seule délégation mal calibrée, posée pour une raison légitime et jamais réévaluée depuis.

Outils d'énumération et d'exploitation

# Énumération des ACL avec BloodHound (collecte SharpHound côté Windows)
SharpHound.exe -c All

# Abus direct avec PowerView
Add-DomainObjectAcl -TargetIdentity "OU=Utilisateurs,DC=corp,DC=local" -PrincipalIdentity jdupont -Rights All

# DCSync avec Mimikatz, une fois les droits de réplication obtenus
lsadump::dcsync /domain:corp.local /user:krbtgt

# DCSync avec Impacket, depuis un poste non-Windows
secretsdump.py corp.local/jdupont:'Password123!'@10.10.10.10 -just-dc-ntlm

Abus de GPO : exécution de code via une stratégie de groupe

Un objet GPO (Group Policy Object) qui s'applique à une OU contenant des serveurs ou des postes sensibles est, du point de vue offensif, équivalent à un accès administrateur sur toutes les machines couvertes par cette OU. Les droits d'édition d'une GPO (GenericWrite sur l'objet GPO, ou appartenance au groupe qui en a l'édition déléguée) permettent d'y injecter une tâche planifiée, un script de démarrage, ou une préférence de groupe qui s'exécutera avec les privilèges SYSTEM sur chaque machine concernée, au prochain cycle de rafraîchissement des stratégies — généralement sous 90 minutes par défaut.

La séquence typique :

1. Identifier, via BloodHound ou une énumération manuelle, les comptes disposant de droits d'édition sur une GPO liée à une OU contenant des serveurs ou postes à forte valeur
2. Modifier la GPO pour y injecter une tâche planifiée exécutant une commande au nom SYSTEM (outil SharpGPOAbuse côté Windows, ou modification directe des fichiers GPT sur le partage SYSVOL)
3. Attendre le prochain rafraîchissement de stratégie, ou le forcer si un accès local existe déjà sur une machine de test (gpupdate /force)
4. Récupérer l'exécution obtenue — souvent un accès administrateur local sur un serveur qui héberge, à son tour, un compte de service à privilège plus élevé connecté en session

Les pentesters débutants se concentrent parfois uniquement sur les GPO racines du domaine, en négligeant les GPO plus modestes liées à une OU spécifique — support technique, comptabilité, serveurs applicatifs. Ces GPO secondaires ont souvent des délégations d'édition plus larges, posées historiquement pour permettre à une équipe métier de gérer ses propres paramètres, sans que personne n'ait mesuré que cela équivaut à un accès administrateur sur tout le parc couvert.

Introduction à ADCS : ESC1 et ESC8

Active Directory Certificate Services (ADCS) est le rôle qui gère l'infrastructure à clé publique interne d'un domaine. Depuis la publication des travaux de recherche sur les « Certified Pre-Owned » attack paths, ADCS est devenu l'un des vecteurs d'escalade privilégiés en engagement réel, en grande partie parce que ses gabarits de certificats sont configurés une fois à l'installation puis rarement revus, et parce que la détection de leur abus reste peu mature dans la majorité des environnements.

Deux scénarios (ESC pour Escalation, nomenclature issue de ces travaux) reviennent le plus fréquemment :

• ESC1 — un gabarit de certificat autorise l'inscription (enrollment) par des utilisateurs à faible privilège et permet au demandeur de spécifier lui-même le nom alternatif du sujet (Subject Alternative Name, SAN) du certificat. Un attaquant demande un certificat en indiquant le nom d'un compte Domain Admin comme SAN, obtient un certificat valide pour ce compte, puis s'authentifie avec via PKINIT — sans jamais connaître le mot de passe réel du compte ciblé.
• ESC8 — le service d'inscription web ADCS (Certificate Enrollment Web Service) accepte l'authentification NTLM sans protection contre le relais. Un attaquant relaie l'authentification NTLM d'un compte machine ou utilisateur (obtenue par exemple via un abus de coercition d'authentification) vers ce service web, et obtient à sa place un certificat exploitable pour s'authentifier en tant que la victime relayée.

Contrairement aux droits AD classiques, les permissions sur les gabarits de certificats sont configurées dans la console de gestion PKI, un outil que les équipes sécurité auditent rarement au même titre que les ACL AD ou les GPO. L'infrastructure PKI est souvent perçue comme un sujet cryptographique distinct de l'annuaire, alors qu'elle en est, du point de vue offensif, une extension directe et généralement moins surveillée.

# Énumération des gabarits vulnérables avec Certipy
certipy find -u jdupont@corp.local -p 'Password123!' -dc-ip 10.10.10.10 -vulnerable

# Exploitation ESC1 : demande de certificat au nom d'un autre compte
certipy req -u jdupont@corp.local -p 'Password123!' -ca CORP-CA -template VulnTemplate -upn administrateur@corp.local

# Authentification avec le certificat obtenu (PKINIT)
certipy auth -pfx administrateur.pfx -domain corp.local

Cartographier avec BloodHound : trouver le chemin le plus court

Énumérer manuellement les ACL de plusieurs milliers d'objets AD, croiser les appartenances de groupes imbriquées et les sessions actives n'est pas réaliste à la main sur un domaine de taille réelle. BloodHound convertit cette masse de relations en graphe et applique des algorithmes de plus court chemin pour répondre directement à la question qui intéresse un pentester : « depuis mon compte compromis, quel est le chemin le plus court vers Domain Admins ? »

La collecte se fait via SharpHound (agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire Windows) ou BloodHound.py (depuis un poste non-Windows avec des identifiants valides), puis s'importe dans l'interface graphique pour analyse. Les requêtes les plus utiles en engagement :

• Shortest Paths to Domain Admins — la vue par défaut la plus actionnable
• Find Principals with DCSync Rights — repère directement les comptes disposant des droits de réplication
• Shortest Paths from Owned Principals — une fois un premier compte compromis marqué comme « owned », affiche tous les chemins qui en partent

Dès qu'un identifiant est obtenu en engagement, marquez-le comme owned dans BloodHound plutôt que de composer manuellement des requêtes Cypher à chaque nouvelle découverte. La vue Shortest Paths from Owned Principals se met à jour automatiquement et révèle souvent en quelques secondes des chemins d'escalade non anticipés, notamment via des appartenances de groupes imbriquées à plusieurs niveaux, difficiles à repérer manuellement même par un administrateur AD expérimenté.

L'attribut AdminSDHolder mérite une mention à part : ce mécanisme AD copie périodiquement (toutes les 60 minutes par défaut) une DACL de référence sur tous les membres de groupes protégés (Domain Admins, Enterprise Admins, etc.), y compris sur d'anciens membres retirés depuis longtemps si leur objet conserve la marque AdminCount=1. Un attaquant qui identifie un objet avec AdminCount=1 et des droits mal nettoyés dessus — vestige d'une ancienne appartenance à un groupe protégé — dispose parfois d'un chemin d'escalade que personne n'a jamais audité, précisément parce que ce mécanisme de protection est mal compris et rarement vérifié après coup.

Priorisation du risque métier

Un rapport de pentest qui liste vingt ACL permissives sans hiérarchie n'aide pas un client à prioriser sa remédiation avec des ressources limitées. La grille suivante aide à trancher :

La priorité « Élevée » pour un chemin non exploité par prudence (stabilité de production, contrainte de temps) ne doit jamais être revue à la baisse simplement parce que la démonstration s'est arrêtée avant l'objectif final. La confirmation technique du chemin — via BloodHound, Certipy ou une simple vérification d'ACL — suffit à en établir la criticité. Attendre l'exploitation complète pour la qualifier reviendrait à sous-évaluer systématiquement les risques les plus dangereux, ceux que le temps limité d'un engagement ne permet pas toujours de dérouler jusqu'au bout.

Pièges fréquents

• Se concentrer uniquement sur les droits directs sur les groupes à privilège, en ignorant les chemins indirects via GPO, ADCS ou appartenances imbriquées à plusieurs niveaux
• Exploiter un gabarit ADCS en production sans avoir vérifié au préalable l'impact d'une demande de certificat sur l'infrastructure PKI du client — certaines actions, comme la révocation, ne sont pas anodines
• Oublier de vérifier AdminCount=1 sur les objets suspects, un signal souvent révélateur d'un vestige de droit non nettoyé après un changement d'appartenance à un groupe protégé
• Confondre un chemin BloodHound théoriquement valide avec un chemin réellement exploitable : certaines relations affichées supposent des conditions (session active, machine accessible) qui ne sont plus vraies au moment du test
• Documenter une ACL permissive sans retracer le chemin complet qu'elle permet, ce qui prive le client du contexte nécessaire pour juger de l'urgence réelle de la correction

Ce qu'il faut retenir

1. L'escalade de privilèges AD résulte presque toujours d'un enchaînement de droits individuellement légitimes, pas d'une vulnérabilité logicielle isolée
2. Les ACL (GenericAll, WriteDACL, ForceChangePassword, droits DCSync), les GPO mal déléguées et les gabarits ADCS constituent les trois familles de chemins les plus fréquentes en engagement réel
3. BloodHound transforme une masse de relations ingérable manuellement en chemins d'attaque directement actionnables, à condition de marquer systématiquement les comptes compromis comme owned
4. Un chemin d'escalade confirmé mais non exploité par prudence reste un constat critique à part entière, jamais un constat mineur
5. La priorisation du rapport doit toujours relier la découverte technique à l'objectif métier qu'elle permet d'atteindre, pas seulement à la sévérité isolée du droit constaté

Les chemins d'escalade identifiés ici deviennent le socle du chapitre suivant, consacré à la cartographie complète des chemins d'attaque et à la construction d'un scénario d'attaque cohérent pour le rapport final. Conservez une trace précise de chaque ACL, GPO et gabarit ADCS exploité ou confirmé : ils seront réassemblés dans une narration unique destinée au client.