Dans le cadre de nos missions d’audit interne, nous rencontrons régulièrement des infrastructures AD CS (Active Directory Certificate Services) déployées sur les réseaux d’entreprise.
Ce composant retient systématiquement notre attention, car une configuration inadéquate peut rapidement ouvrir la voie à une compromission totale du domaine Active Directory.
Malheureusement, AD CS est souvent déployé sans les précautions de sécurité nécessaires. Ce manque de rigueur offre des opportunités pour les attaquants. En 2021, plusieurs travaux ont mis en lumière les risques liés à AD CS. Les recherches de SpecterOps ont notamment démontré comment exploiter des déploiements mal configurés. La même année, la vulnérabilité PetitPotam a été révélée. Elle permet à un attaquant non authentifié de compromettre un domaine entier via AD CS.
Vous pouvez consulter notre article dédié aux failles spécifiques d’AD CS et techniques d’exploitation ESC. Ici, nous nous concentrons sur les principes de fonctionnement d’AD CS, son rôle dans un environnement Active Directory, ainsi que les mécanismes de gestion des certificats qu’il met en œuvre.
Dans un environnement Active Directory, Active Directory Certificate Services (AD CS) constitue l’implémentation de l’infrastructure à clé publique (PKI – Public Key Infrastructure) de Microsoft. Ce service permet de gérer les mécanismes de chiffrement, les certificats numériques et les signatures électroniques.
Grâce à AD CS, il devient possible de renforcer la sécurité des échanges et des authentifications en associant l’identité d’un utilisateur, d’une machine ou d’un service à une clé privée correspondante. Pour faire simple, AD CS est utilisé pour émettre, gérer et révoquer des certificats numériques.
AD CS repose sur plusieurs composants fondamentaux :
Comprendre l’architecture AD CS, c’est bien. Mais depuis le début, nous parlons de certificats. Il est donc pertinent de regarder de plus près ce qu’ils contiennent, comment ils sont générés et pourquoi leur intégrité est si cruciale.
Les certificats délivrés par AD CS respectent la norme X.509 (RFC 5280). Chaque certificat inclut un ensemble de champs standards, parmi lesquels :
DC=local, DC=essos, CN=ESSOS-CA.DC=local, DC=essos, CN=Users, CN=khal.drogo.
À noter qu’en possédant uniquement le certificat, il n’est pas possible de s’authentifier sur un service ou de demander un ticket TGT, car il faut être en possession de la clé privée.
Un certificat X.509 délivré par AD CS ne se limite pas aux seules informations de base. Il embarque également un ensemble d’extensions, qui jouent un rôle essentiel dans la définition des usages autorisés et dans le renforcement (ou non) de la sécurité.
Ces champs supplémentaires apportent des fonctionnalités avancées, mais ils sont également une porte d’entrée pour des attaquants.
Parmi les extensions les plus couramment rencontrées, certaines méritent une attention particulière.
Key Usage (1) spécifie les opérations cryptographiques que le certificat est autorisé à effectuer.
Le standard X.509 définit neuf usages possibles, tels que la signature numérique (Digital Signature), le chiffrement de clé (Key Encipherment), la signature de certificat, ou encore la signature de liste de révocation.
Ce champ permet donc de restreindre, ou au contraire d’élargir, l’usage technique du certificat.
Extended Key Usage (2) affine encore davantage les possibilités d’utilisation en précisant les cas d’usage applicatifs prévus pour le certificat.
On y trouve, par exemple, les valeurs « Client Authentication », « Email Protection » ou encore « Smartcard Logon ». Ces indications permettent aux services consommateurs de certificats de vérifier que le certificat présenté correspond bien au contexte attendu.
Une mauvaise configuration de ces EKU peut entraîner de graves conséquences, notamment en permettant à un certificat de s’authentifier à des services auxquels il ne devrait pas avoir accès.
L’extension Subject Alternative Name (2) complète l’identification de l’entité titulaire du certificat.
Elle permet d’ajouter des identifiants secondaires, tels que des noms DNS ou des UPN (User Principal Name). Cette flexibilité est particulièrement exploitée dans les certificats de serveurs web ou dans les scénarios d’authentification où un même certificat doit être reconnu sous plusieurs identités.
Là encore, une configuration trop permissive peut créer des opportunités pour un attaquant, en autorisant par exemple l’usurpation d’un nom DNS critique.
Impossible de passer à côté d’un élément crucial des certificats : les formats de fichiers.
Sur le terrain, en audit ou en phase de post-exploitation, on tombe souvent sur des extensions aussi variées que mystérieuses : .pem, .crt, .pfx, etc.
Le format .p12 (ou .pfx sous Windows) est certainement le plus répandu lorsqu’il s’agit de gérer des certificats utilisateurs.
Décrit dans la RFC 7292 (PKCS #12), ce format a une particularité intéressante : il contient à la fois le certificat X.509 et la clé privée associée. Et pour éviter les mauvaises surprises, l’ensemble est protégé par un mot de passe.
Côté Windows, .pfx est la norme historique imposée par Microsoft, mais dans les faits, .p12 et .pfx sont techniquement identiques.
Sur un système Linux, on peut facilement les inspecter ou les convertir avec openssl :
# Afficher le contenu d’un fichier .p12/.pfx
openssl pkcs12 -in certificat.p12 -info
# Extraire le certificat sans la clé privée
openssl pkcs12 -in certificat.pfx -clcerts -nokeys -out certificat.pemLes extensions .pem et .crt désignent des fichiers contenant uniquement le certificat public, sans la clé privée.
.pem est le plus explicite : il s’agit d’un encodage Base64, encadré par les fameuses balises -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----..crt, quant à lui, est un peu plus ambigu : il peut désigner un certificat encodé en Base64 (comme un .pem) ou en binaire pur (format DER). En pratique, tout dépend du contexte d’utilisation.Pour lire le contenu d’un certificat .pem ou .crt, la commande suivante suffit :
openssl x509 -in certificat.crt -text -nooutAprès avoir exploré le fonctionnement général d’AD CS et la structure d’un certificat, il reste une question clé : comment ces certificats sont-ils générés ?
Pour mieux comprendre, imaginons que les certificats délivrés dans un domaine soient comparables à des badges d’accès. Ces badges permettent aux utilisateurs de prouver leur identité, d’accéder à certaines ressources ou d’authentifier des services.
Plutôt que de concevoir chaque badge manuellement, on établit des modèles standards, appelés templates. Il existe par exemple un modèle pour les visiteurs, un pour les employés, un pour les administrateurs, etc.
Chaque template spécifie un ensemble de caractéristiques comme :
Dans AD CS, les templates permettent de normaliser l’émission des certificats, d’automatiser leur déploiement, et d’en contrôler l’usage selon les rôles et les besoins des utilisateurs ou des machines. Autrement dit, ils assurent que chaque utilisateur reçoit un certificat qui correspond précisément à son profil.
Mais attention : une mauvaise configuration d’un template peut vite devenir un vecteur d’attaque. Si, par exemple, le modèle prévu pour les visiteurs permet accidentellement un accès privilégié aux systèmes critiques, alors n’importe quel utilisateur disposant de ce certificat pourrait en profiter.
Les propriétés des templates sont identifiées par des OID (Object Identifiers). Ces propriétés déterminent avec précision les conditions d’émission d’un certificat, son usage et les droits associés.
Chaque template est défini par :
Concernant la durée de vie du certificat, deux paramètres sont clés :
Les droits d’accès à un template sont gérés via une ACL (Access Control List). Celle-ci permet par exemple d’autoriser certains utilisateurs ou groupes à demander un certificat via le droit « Enroll », ou de permettre une délivrance automatique via le droit « Autoenroll », souvent utilisé pour les machines ou comptes intégrés dans Active Directory. Le droit « Read », quant à lui, donne accès à la lecture des propriétés du template.
Un autre élément clé est la manière dont le nom du sujet (Subject Name) est défini. Ce nom représente l’identité qui figurera dans le certificat final. Il peut être construit automatiquement à partir des attributs Active Directory de l’utilisateur ou de la machine, ou bien saisi manuellement.
Enfin, les templates intègrent des extensions qui précisent ce que le certificat est autorisé à faire.
Après avoir exploré la manière dont sont définis les modèles de certificats, il est temps de se pencher sur le processus concret d’émission d’un certificat par AD CS.
Le point de départ se situe toujours du côté du client, qu’il s’agisse d’un utilisateur ou d’une machine.
Ce dernier génère une paire de clés cryptographiques : une clé privée, conservée précieusement en local, et une clé publique destinée à être communiquée. En parallèle, le client crée une demande de certificat, connue sous le nom de CSR (Certificate Signing Request).
Ce fichier contient toutes les informations nécessaires pour que l’autorité de certification puisse émettre un certificat valide : identité du demandeur, usages souhaités, extensions, et bien sûr la clé publique.
Il est essentiel de souligner que la clé privée ne quitte jamais le client. Seule la clé publique est incluse dans la CSR, ce qui constitue une garantie de sécurité fondamentale dans le processus.
Une fois la demande prête, le client transmet son CSR à l’autorité de certification, en l’occurrence AD CS, pour traitement.
Cette opération peut se faire automatiquement, selon la configuration du système et les droits attribués au client.
Avant de délivrer un certificat, AD CS procède à une série de contrôles rigoureux.
Si toutes les conditions sont réunies, AD CS procède à la création du certificat. Elle le signe à l’aide de sa propre clé privée, garantissant ainsi l’authenticité du document, puis le transmet au client.
Cependant, certains paramètres de sécurité supplémentaires peuvent altérer ce processus ou empêcher sa finalisation automatique. Il existe notamment deux protections souvent méconnues, mais pourtant cruciales.
Dans le cadre d’un pentest Active Directory, ces deux mécanismes doivent être absents pour que les scénarios d’exploitation soient valides. Fort heureusement (ou malheureusement, selon le point de vue), dans les environnements que nous auditons, ces protections sont rarement mises en œuvre.
Une fois le certificat délivré, celui-ci est automatiquement stocké sur le poste client, dans le Windows Certificate Store. Il est alors immédiatement disponible pour les usages prévus : authentification, signature électronique ou encore chiffrement.
Ce certificat devient ainsi un élément central du fonctionnement sécurisé de l’environnement Active Directory.
Le mapping des certificats désigne le processus par lequel un contrôleur de domaine (DC) associe un certificat reçu à un compte utilisateur ou machine dans Active Directory.
Ce mécanisme peut être implicite ou explicite, et qualifié de fort (strong) ou de faible (weak), selon le niveau de vérification effectué.
Dans le cas du mapping implicite, le DC s’appuie sur le contenu même du certificat pour identifier son porteur.
Il commence par extraire l’attribut Subject Alternative Name (SAN). S’il s’agit d’un certificat utilisateur, il tente de faire correspondre l’entrée otherName de type UPN (User Principal Name) avec l’attribut userPrincipalName dans l’AD. Si cette tentative échoue, il vérifie l’attribut sAMAccountName, voire ce dernier suffixé d’un dollar ($) dans le cas des comptes machines. Pour un certificat destiné à une machine, le DC utilise la valeur dNSName et cherche une correspondance avec l’attribut dNSHostName de l’objet correspondant. À défaut, les mêmes vérifications que pour un certificat utilisateur peuvent être appliquées.
Le mapping explicite, quant à lui, repose sur une association manuelle entre un certificat et un compte AD.
Celle-ci est enregistrée dans l’attribut altSecurityIdentities de l’objet concerné. Cette méthode offre un contrôle précis sur quels certificats sont autorisés, mais implique une gestion plus lourde.
La distinction entre un mapping faible et un mapping fort repose sur le niveau de confiance accordé aux informations extraites du certificat.
Un mapping faible consiste simplement à associer un certificat à un compte en se basant sur des champs comme le UPN ou le DNS Name, sans réelle vérification de l’identité. Cela ouvre la voie à des attaques, notamment si un attaquant parvient à se procurer un certificat avec un SAN forgé.
Pour contrer cela, Microsoft a introduit en mai 2022, à la suite de la vulnérabilité Certifried (CVE-2022-26923), plusieurs mécanismes renforçant le mapping fort :
szOID_NTDS_CA_SECURITY_EXT (OID 1.3.6.1.4.1.311.25.2), contenant le objectSid de l’utilisateur demandeur. Ce champ, unique à chaque utilisateur AD, permet au DC de vérifier avec précision l’identité du porteur.CT_FLAG_NO_SECURITY_EXTENSION (0x80000) dans l’attribut msPKI-Enrollment-Flag, l’extension de sécurité est désactivée, ramenant le mapping à un mode faible.CertificateMappingMethods, qui contrôle la méthode de mappage pour l’authentification TLS/SSL (Schannel), et StrongCertificateBindingEnforcement, qui impose la vérification du propriétaire du certificat.Depuis mai 2022, les environnements Active Directory correctement mis à jour et configurés peuvent imposer un mapping fort, rendant l’exploitation des certificats beaucoup plus difficile pour un attaquant.
En pratique toutefois, ces mesures de sécurité sont rarement activées, que ce soit par méconnaissance ou pour éviter une surcharge administrative.
Ainsi, le mapping implicite faible reste la configuration par défaut dans la majorité des environnements audités. Combiné à une mauvaise configuration des templates de certificats, il constitue un vecteur d’attaque particulièrement attractif, que les attaquants exploitent pour usurper des identités et compromettre des systèmes entiers.
Active Directory Certificate Services (AD CS) joue un rôle central dans la gestion des identités, des accès et de la confiance au sein des environnements Windows. En permettant la délivrance, la gestion et la révocation de certificats numériques, il constitue la pierre angulaire de nombreuses fonctions de sécurité.
Dans cet article, nous avons exploré notamment les composants clés d’AD CS et le fonctionnement des modèles de certificats (templates). Ces éléments, souvent en arrière-plan du quotidien des utilisateurs, sont pourtant essentiels à la sécurité et au bon fonctionnement de l’infrastructure Active Directory dans son ensemble.
Les infrastructures AD CS restent encore trop souvent mal sécurisées. Comme nous avons pu le voir, un simple mauvais paramétrage (par exemple un template permissif) peut offrir à un attaquant un accès privilégié aux systèmes les plus sensibles.
Dans un prochain article, nous reviendrons en détail sur les vulnérabilités courantes liées à AD CS, les scénarios d’attaque concrets qui en découlent, ainsi que les bonnes pratiques pour sécuriser efficacement cette brique souvent sous-estimée mais hautement stratégique.
Auteur : Adrien HOC – Pentester @Vaadata
