I. Présentation
Dans cet article, nous allons explorer comment auditer les serveurs d’autorité de certification AD CS (Active Directory Certificate Services) sous Windows Server afin d’identifier d’éventuels risques, vulnérabilités ou mauvaises configurations.
Cet audit s’inscrit dans deux contextes principaux :
Une démarche de sécurité courante, comme un test annuel ou une vérification planifiée
En amont d’une opération de hardening
Connaître l’état actuel de sa configuration PKI permet de mieux comprendre les enjeux techniques et de définir une stratégie de sécurisation adaptée à son environnement.
Pour approfondir ce sujet, retrouvez notre cours complet sur la mise en œuvre d’AD CS :
II. À propos de l’audit PKI
L’audit d’une infrastructure PKI peut prendre plusieurs formes et il est souvent confondu avec des tests d’intrusion (Pentests) ciblant les serveurs d’autorité de certification. Pourtant, ces deux approches sont complémentaires, mais bien distinctes. Une mauvaise configuration peut ne représenter aucun danger immédiat, mais devenir critique dans un avenir proche.
À l’inverse, le fait qu’un test d’intrusion ne parvienne pas à compromettre l’infrastructure ne signifie pas pour autant qu’elle est correctement sécurisée.
Il existe aussi des formes d’audit plus classiques, qu’elles soient manuelles ou automatisées. Des outils populaires comme PingCastle ou Purple Knight permettent d’analyser certaines facettes de la PKI, notamment :
Les modèles de certificats publiés
Les ACL associées à ces modèles dans Active Directory
Les informations de révocation (CRL/AIA) référencées
Cependant, ces outils se limitent aux données exposées dans Active Directory pour une raison de performance, sans aller interroger directement les bases des autorités de certification (CA), en particulier lorsqu’il s’agit de CAs autonomes ou mal intégrées à l’annuaire.
Or, c’est bien dans les bases de la CA que résident la majorité des éléments critiques : les certificats émis, les rôles et droits d’administration, les paramètres de sécurité (algorithmes, tailles de clés, CSP), ou encore les extensions configurées.
III. Automatisation de l’audit
Les informations stockées dans Active Directory ne suffisent pas à auditer correctement une infrastructure PKI. De nombreux éléments critiques – comme les paramètres de la CA, les certificats émis ou certaines options de sécurité – ne sont pas exposés dans l’annuaire.
Pour aller plus loin, il est possible d’automatiser l’audit grâce à plusieurs outils :
Certutil, outil natif de Windows
Le module PowerShell PSPKI, très complet, mais nécessitant un peu de développement personnalisé
Le module PSPKIAudit basé sur PSPKI, régulièrement mis à jour, et conçu pour détecter les vulnérabilités connues.
C’est ce dernier que nous allons utiliser dans la suite de l’article.
A. Présentation de PSPKIAudit
PSPKIAudit est un module PowerShell open-source basé sur PSPKI. Il a été conçu pour analyser automatiquement (ou manuellement) les serveurs d’autorité de certification ADCS, afin de détecter des failles de configuration connues.
Le module évalue en profondeur la configuration pour détecter si la CA est vulnérable aux attaques connues (ESC) :
Code
Nom / Type de faille
Description
ESC1
Misconfigured Certificate Templates
Modèle permettant l’émission de certificats avec des identités arbitraires (e.g., Subject Name = Supply).
ESC2
Misconfigured Certificate Templates
Modèle permettant l’auto-inscription pour des utilisateurs non restreints avec des privilèges étendus.
ESC3
Misconfigured Enrollment Agent Templates
Utilisateur pouvant demander un certificat pour un autre compte sans contrôle suffisant.
ESC4
Vulnerable Certificate Template ACL
Les ACL sur le modèle de certificat permettent à des utilisateurs non autorisés de le modifier ou l’utiliser.
ESC5
Vulnerable PKI AD Object ACL
Les objets liés à la PKI dans l’AD (modèles, services) ont des droits d’écriture dangereux.
ESC6
EDITF_ATTRIBUTESUBJECTALTNAME2
La CA autorise les clients à spécifier un SAN arbitraire (Subject Alternative Name), ouvrant à l’usurpation.
ESC7
Vulnerable CA ACL
Les ACL sur le serveur de certification lui-même permettent à un utilisateur de devenir CA manager.
ESC8
NTLM Relay to AD CS HTTP Endpoints
La CA expose une interface web (e.g., certsrv) vulnérable aux attaques par relai NTLM.
Misc
Explicit Mappings
Des mappings Keberos explicites comptes et des certificats, pouvant être abusés.
Le module PSPKIAudit repose principalement sur deux commandes majeures :
Invoke-PKIAudit : lance un scan automatique de l’environnement AD CS pour auditer les paramètres actuels.
Get-CertRequest : permet d’examiner manuellement les certificats émis par une autorité de certification, en interrogeant directement sa base de données. Contrairement au scan automatique, cette approche requiert une analyse manuelle. C’est à l’administrateur de croiser les données et d’identifier les éventuelles anomalies ou mauvaises pratiques. Nous verrons cela ensemble dans les sections suivantes.
B. Installation
Avant d’utiliser le module PSPKIAudit, quelques prérequis sont nécessaires. Il n’est pas obligatoire de l’exécuter directement sur un serveur de certification.
Un poste tiers suffit, à condition d’avoir :
Le module PSPKI
La suite RSAT pour les certificats et Active Directory
Un compte disposant des droits de lecture sur la CA est également requis.
Par défaut, un compte administrateur sera utilisé, mais il est tout à fait possible d’utiliser un compte de service si les autorisations sont correctement définies.
Commençant par installer les prérequis sur le serveur :
Get-WindowsCapability -Online -Name “Rsat.*” | where Name -match “CertificateServices|ActiveDirectory” | Add-WindowsCapability -Online
Ensuite, installez le module PSPKI (prérequis) :
Install-Module -Name PSPKI –Scope CurrentUser -Force
Nous pouvons ensuite télécharger et utiliser notre module.
Téléchargez le contenu en format ZIP à partir du GitHub du projet, et décompressez-le dans un dossier, pour ma part, j’opte à regrouper les modules dans un dossier Temp.
Le contenu se présente sous la forme suivante.
Il faudra ensuite débloquer le contenu à l’aide de la commande Unblock-File en ciblant le répertoire du script.
cd c:\Temp\PSPKIAudiit-main
Get-ChildItem -Recurse | Unblock-File
Si vous n’obtenez pas d’erreur, c’est que le module s’est bien importé.
C. Analyse automatique
Nous allons commencer par lancer un scan automatique. À partir de votre fenêtre PS1 ou l’éditeur ISE, importez tout d’abord le module PSPKI pour éviter tout problème, puis lancez l’analyse à l’aide de la commande suivante :
Invoke-PKAudit
Cette commande cherche les serveurs de certificats inscrits dans l’Active Directory, et effectue une analyse à tour de rôle. Vous pouvez indiquer un serveur ou Autorité de certificat spécifique à l’aide du paramètre -ComputerName ou -CAName.
Pour explorer d’autres paramètres et options avancées, vous pouvez vous référer à la page du module PKIAudit sur GitHub.
Une fois la commande lancée, patientez quelques instants : les informations pour chaque autorité de certification seront affichées à l’écran.
Si aucun résultat ne s’affiche ou si la colonne Misconfiguration reste vide, cela signifie qu’aucune vulnérabilité connue n’a été détectée lors de l’analyse.
Ici, nous constatons une vulnérabilité et mauvaise configuration sur un module de certificat, cela a été volontaire dans notre cas : ESC4.
D’après la documentation, la vulnérabilité ESC4 concerne les autorisations (ACL) mal configurées sur les modèles de certificats
Elle se manifeste lorsqu’un utilisateur ou un groupe non autorisé dispose de droits d’inscription (Enroll) ou d’auto-inscription (Autoenroll) sur un modèle sensible, ouvrant ainsi la voie à une élévation de privilèges via l’émission de certificats malveillants.
Nous pouvons vérifier cela au niveau de la Template. Ici, les utilisateurs authentifiés possèdent des droits excessifs !
En cas d’autres erreurs, prenez le temps d’analyser le résultat. Dans notre lab, c’était la seule alerte remontée.
D. Analyse manuelle
Le module PSPKIAudit permet également une analyse manuelle, basée sur l’interprétation des certificats émis et des paramètres internes de la CA.
Cette approche est particulièrement utile pour les architectes sécurité et les experts Windows, car elle offre une vision plus fine des faiblesses potentielles, au-delà des vulnérabilités détectées automatiquement.
En croisant les informations issues de la base de données de la CA (via la commande Get-CertRequest) avec les bonnes pratiques en matière de sécurité PKI, il devient possible de :
Détecter des certificats émis avec des usages inappropriés (ex. : Client Authentication pour des comptes à privilèges)
Identifier des durées de validité anormalement longues
Repérer des certificats émis sans contrôle via des agents d’enregistrement (Enrollment Agents)
Ou encore vérifier les extensions critiques comme Subject Alternative Name.
Cette analyse manuelle, bien que plus technique, est essentielle pour établir un plan de remédiation solide et adapté à l’environnement.
À présent, lancez le scan des certificats à l’aide de la commande suivante :
Get-CertRequest
Dans un grand parc, je vous suggère de limiter la recherche ou la découper. Exportez aussi le résultat dans un fichier CSV pour une meilleure interprétation ou dans une variable, à la limite tout est relatif à la taille de la base, on parle ici de + 10 000 certificats.
En procédant à une analyse approfondie des extensions SAN des certificats émis par la CA, nous avons identifié un certificat suspect.
Concrètement, un utilisateur standard « mehdi » a réussi à générer une demande avec un Subject Alternative Name (SAN) au nom d’un compte administrateur. Ce type de configuration est hautement problématique, car il permet à un utilisateur non privilégié d’usurper l’identité d’un administrateur via un certificat qui semble légitime.
Ce cas indique clairement une faille liée à la vulnérabilité ESC6 (EDITF_ATTRIBUTESUBJECTALTNAME2 activé), qui autorise les requêtes avec des SAN arbitraires.
Risques et conséquences :
Authentification détournée (Kerberos / LDAPS) au nom de l’administrateur.
Contournement des contrôles d’accès basés sur l’identité.
Création de certificats “golden” pour maintenir ou étendre les privilèges.
Altération de la confiance au sein des infrastructures AD.
Nous devrions révoquer immédiatement ce certificat, même s’il ne s’agissait ici que d’un test contrôlé. Ce type de configuration représente une faille critique si elle est présente en production.
Il est également possible d’analyser la provenance des demandes de certificats, en identifiant le processus qui a soumis chaque requête. Cela peut permettre de détecter des anomalies : par exemple, une requête envoyée via PowerShell ISE, Certify.exe, ou un navigateur web (certsrv) peut être légitime dans un contexte, mais suspect dans un autre selon les pratiques de votre entreprise.
Listez les provenances des demandes à l’aide de la commande suivante :
$var = Get-CertRequest
$var | Group-Object RequesterProcessName | Sort-Object Count –Descending
Ici, nous constatons que la plupart des demandes sont générées à partir de PowerShell ISE, ce qui est normal dans mon lab.
L’utilisation de l’outil PKIReport permet aussi d’avoir une vision et un inventaire sur les Top utilisateurs/comptes ayant émis des demandes de certificats et le Top 5 du nom de certificats, ainsi que les protocoles de signature utilisés et d’autres informations. Cet outil sera bientôt disponible et sera présenté dans un futur article.
E. Constat
Beaucoup de configurations concentrent les efforts de supervision sur Active Directory (via le SOC, les logs, les contrôles d’accès), en négligeant complètement les chaînes de confiance, pourtant tout aussi sensibles.
Dans ce contexte, une requête malveillante de certificat avec un SAN usurpé ou un usage détourné peut facilement passer inaperçue, échapper à la détection classique, et permettre des actions malveillantes comme l’élévation de privilèges, l’usurpation d’identité ou la persistance.
IV. Conclusion
Les vulnérabilités liées aux infrastructures PKI ne cessent d’évoluer, et deviennent de plus en plus un terrain d’exploration privilégié pour les attaquants.
Lors de mes audits et missions de hardening, je constate que de nombreuses organisations restent figées dans des choix historiques, par crainte de perturber un système en apparence stable. Pourtant, dans le domaine de la PKI, l’immobilisme constitue souvent un risque bien plus grand que le changement.
Il est donc essentiel de considérer l’audit de la PKI comme une brique à part entière de la sécurité des identités, au même titre que les contrôles sur l’annuaire Active Directory, suivez aussi les changements et faites des inventaires réguliers.
Consultant et formateur expert Windows Server et Cloud Azure. Chercheur en Cybersécurité.