Vulnérabilités de Microsoft Active Directory Certificate Services (ADCS) : analyse complète de sécurité

Introduction

Active Directory Certificate Services (ADCS) est un rôle Windows Server qui permet aux organisations de créer et gérer une infrastructure à clé publique (PKI), afin d’émettre et de gérer des certificats numériques utilisés pour sécuriser les communications et l’authentification. Bien qu’ADCS fournisse des services cryptographiques essentiels aux environnements d’entreprise, une configuration incorrecte peut créer une surface d’attaque importante.

Selon l’article d’origine, en août 2025, des chercheurs avaient identifié 16 techniques distinctes d’élévation de privilèges (ESC1–ESC16) exploitant des erreurs de configuration ADCS. Ce chiffre et cet état reflètent la date de publication de l’article. Ces chemins d’attaque ont été utilisés pour passer d’un compte de domaine standard à des privilèges élevés, notamment en usurpant des comptes importants.

Cette analyse examine les risques ADCS, en particulier Web Enrollment et Network Device Enrollment Service (NDES), et formule des recommandations pour limiter l’exposition et gérer la PKI de manière sécurisée.

Surface d’attaque ADCS : comprendre les risques

Les vulnérabilités ADCS proviennent principalement de mauvaises configurations, plutôt que de défauts inhérents au logiciel. Les modèles de certificats, les autorisations d’inscription et les paramètres de service peuvent créer des chemins d’attaque. Des outils publics comme Certipy peuvent servir à détecter et exploiter certaines configurations.

La surface d’attaque comprend :

• Modèles de certificats : ADCS fournit 32 modèles par défaut ; certains peuvent accorder des autorisations trop larges. Les modèles laissant le demandeur définir le nom du sujet peuvent créer les conditions d’ESC1.
• Services d’inscription : les points de terminaison HTTP d’inscription peuvent exposer l’organisation aux attaques de relais NTLM.
• Autorisations des objets PKI : des contrôles d’accès trop permissifs sur les objets de domaine liés à la PKI peuvent compromettre l’infrastructure PKI.

Les conséquences peuvent inclure une élévation de privilèges depuis un compte standard et une persistance au moyen de techniques telles que « Golden Certificate ». Dans les environnements hybrides, une mauvaise configuration locale peut également affecter l’infrastructure cloud.

Web Enrollment : un risque critique à éviter

Qu’est-ce que Web Enrollment ?

Web Enrollment est un service ADCS facultatif qui fournit une interface Web (généralement à `/certsrv`) permettant aux utilisateurs et aux ordinateurs de demander des certificats via HTTP. Bien qu’il facilite les demandes pour des utilisateurs de forêts séparées ou sans accès direct au domaine, il peut introduire des vulnérabilités importantes.

Vulnérabilité ESC8

Le principal risque de Web Enrollment est ESC8, une attaque de relais NTLM visant les points de terminaison HTTP d’ADCS. Avec la configuration par défaut, deux conditions critiques peuvent se présenter :

• HTTP prend en charge l’authentification NTLM mais ne protège pas contre les attaques de relais au moyen de la signature d’authentification.
• Les modèles par défaut Machine et DomainController peuvent permettre à un attaquant qui force l’authentification d’un ordinateur de demander un certificat représentant cet ordinateur.

Exemple de chaîne d’exploitation

1. Forcer l’authentification : avec des outils comme Coercer ou PetitPotam, un attaquant pousse un contrôleur de domaine à s’authentifier via NTLM.
2. Relayer : la tentative d’authentification est relayée vers le service Web Enrollment d’ADCS au moyen d’outils comme ntlmrelayx.
3. Demander un certificat : l’attaquant demande un certificat à partir du modèle Domain Controller.
4. Compromettre le domaine : le certificat obtenu peut servir à une attaque de réplication (dcsync) et faciliter la prise de contrôle complète du domaine.

L’article indique que cette chaîne ne nécessite ni logiciel malveillant ni exploit zero-day et peut partir d’un compte de domaine standard. PetitPotam peut permettre à un utilisateur du domaine de forcer l’authentification d’ordinateurs actifs, y compris des contrôleurs de domaine.

Pourquoi la désactivation de NTLM ne suffit pas

Désactiver NTLM spécifiquement sur le site Web Enrollment peut traiter une partie du problème, mais le service reste une surface d’attaque inutile lorsque des solutions plus sûres peuvent fournir les mêmes fonctions. L’article recommande de ne pas déployer Web Enrollment, sauf nécessité métier absolue ne pouvant être satisfaite autrement.

Network Device Enrollment Service (NDES) : un composant à haut risque

Présentation de NDES

NDES est l’implémentation Microsoft du Simple Certificate Enrollment Protocol (SCEP). Il est conçu pour émettre des certificats à des équipements réseau tels que routeurs, pare-feu et téléphones qui ne peuvent pas s’authentifier avec Active Directory. NDES sert d’intermédiaire entre les appareils non joints au domaine et Microsoft Certificate Authority.

Risques de sécurité liés à NDES

1. Abus de Subject Alternative Name (SAN)

Les modèles NDES exigent souvent que le client fournisse un Subject Alternative Name (SAN) et incluent généralement un Extended Key Usage (EKU) d’authentification client. Cette combinaison peut permettre à une personne disposant d’un mot de passe NDES de demander un certificat représentant l’utilisateur de son choix et de s’authentifier en son nom via PKINIT ou SChannel.

2. Voies d’élévation de privilèges

Par défaut, NDES génère des mots de passe à usage unique (OTP) valables 60 minutes, avec au maximum cinq mots de passe inutilisés par heure. Les administrateurs peuvent toutefois modifier ces paramètres dans le registre pour :

• Augmenter la taille du cache de mots de passe.
• Définir des mots de passe statiques au lieu d’OTP aléatoires.
• Désactiver entièrement le mot de passe NDES.

Désactiver les mots de passe NDES peut créer une voie d’attaque allant de l’absence d’accès à la compromission de la forêt.

3. Vulnérabilité de relais NTLM

Les serveurs NDES exposés en HTTPS sans Channel Binding peuvent aussi être vulnérables aux attaques de relais NTLM de type ESC8.

4. Défi d’authentification des appareils

NDES émet des certificats à des appareils qui n’ont pas de comptes réseau. Cela crée un compromis délicat entre facilité d’utilisation et sécurité, et complique la prévention des émissions vers des acteurs malveillants.

Reconnaissance des risques par Microsoft

Microsoft reconnaît ces risques et recommande d’utiliser un module de stratégie NDES pour ajouter une authentification. Même avec ce module, NDES reste un service complexe à sécuriser. L’article cite Microsoft : « le point essentiel pour exploiter NDES de manière sécurisée est que, comme pour la plupart des solutions de sécurité, le travail n’est pas terminé lorsque l’inscription des certificats fonctionne comme prévu ». Il recommande d’éviter NDES sauf nécessité absolue et d’appliquer des contrôles complets si son déploiement est inévitable.

Cause fondamentale : complexité de configuration d’ADCS

Les risques décrits reflètent une réalité plus générale : ADCS peut être difficile à configurer de manière sécurisée. Le grand nombre d’options, de modèles et de dépendances augmente les risques d’erreur. Exemples :

• Autorisations d’inscription trop larges sur les modèles de certificats.
• Modèles permettant au demandeur de définir le nom du sujet (ESC1).
• Points de terminaison HTTP d’inscription insuffisamment protégés (ESC8).
• Paramètres cryptographiques faibles sur les certificats et les CA.
• Contrôles d’accès insuffisants sur les objets de domaine liés à la PKI (ESC5).
• Modèles de schéma version 1 permettant au demandeur de spécifier des politiques d’application (CVE-2024-49019).

L’article indique que ces erreurs sont fréquemment observées lors de tests d’intrusion et d’évaluations de sécurité.

Alternatives modernes : sécuriser la PKI avec les solutions Securetron

PKI Trust Cloud (SaaS)

PKI Trust Cloud est une solution SaaS de gestion PKI qui peut réduire le besoin de maintenir une infrastructure ADCS sur site. Les capacités décrites comprennent :

• Agilité cryptographique et préparation post-quantique.
• MFA résistante au phishing.
• Automatisation du cycle de vie TLS de 47 jours.
• Découverte avancée des certificats.
• Service intelligent de notification d’expiration.

PKI Trust Manager (sur site)

Pour les organisations nécessitant une PKI sur site, PKI Trust Manager offre des fonctions qui complètent et améliorent les déploiements ADCS :

• Gestion intelligente du cycle de vie des certificats.
• Création et renouvellement automatisés des certificats.
• Intégration multiplateforme, notamment entre la PKI sur site et Azure Key Vault.
• Application des politiques d’entreprise dans les environnements hybrides.
• Automatisation via SCEP, EST, ACME et des API RESTful.

PKI Trust Auditor : évaluation continue de la sécurité

PKI Trust Auditor permet d’auditer les infrastructures ADCS et propose notamment :

• Découverte automatique des autorités de certification dans Active Directory.
• Audits de connectivité, configuration, cryptographie, modèles et exploitation.
• Plus de 28 contrôles pour les environnements PKI multiniveaux.
• Rapports JSON, CSV, Web et console.
• Rapports exécutifs avec constats, preuves et recommandations de remédiation.
• Intégration SIEM via les sorties JSON ou CSV pour la surveillance et les alertes.

PKI Trust Auditor est proposé gratuitement comme outil communautaire. L’article le présente pour des évaluations ponctuelles et le suivi des tendances de sécurité PKI dans le temps.

Actions recommandées

1. Auditer immédiatement l’environnement PKI existant

Utilisez PKI Trust Auditor pour évaluer l’infrastructure ADCS et repérer :

• Les modèles de certificats mal configurés.
• Les services d’inscription vulnérables.
• Les faiblesses cryptographiques.
• Les risques opérationnels.
• Les écarts de conformité.

2. Supprimer Web Enrollment

Si Web Enrollment est déployé, désactivez-le sauf nécessité métier absolue. L’article identifie ESC8 comme un risque critique associé à ce service.

3. Évaluer et retirer NDES

Déterminez si NDES est réellement nécessaire. Si oui, mettez en place des contrôles robustes, notamment :

• Un module de stratégie obligatoire avec authentification supplémentaire.
• Channel Binding sur HTTPS.
• Une gestion stricte des OTP.
• Des revues de sécurité régulières.

L’article recommande de préférence d’éviter le déploiement de NDES lorsque c’est possible.

4. Mettre en place une gestion PKI moderne

• Organisations cloud-first : évaluez PKI Trust Cloud (SaaS) pour gérer la PKI sans infrastructure sur site.
• Environnements hybrides ou sur site : évaluez PKI Trust Manager pour automatiser et sécuriser le cycle de vie des certificats.

5. Mettre en place une surveillance continue

Utilisez PKI Trust Auditor pour des évaluations régulières. Transmettez les données JSON ou CSV à votre SIEM pour générer des alertes et analyser les tendances.

Étapes suivantes

La sécurité d’Active Directory Certificate Services est trop importante pour être laissée au hasard. Les erreurs de configuration ADCS peuvent créer des surfaces d’attaque critiques et exploitées. Évaluez votre environnement, identifiez et corrigez Web Enrollment, NDES et les autres configurations à haut risque, envisagez PKI Trust Cloud ou PKI Trust Manager selon vos besoins et mettez en place une surveillance continue.

N’attendez pas un test d’intrusion ou, pire, une compromission pour découvrir les faiblesses de votre PKI. Une évaluation et une remédiation proactives aident à anticiper les attaquants qui recherchent des erreurs ADCS.

Contactez-nous pour en savoir plus sur PKI Trust Cloud, PKI Trust Manager et PKI Trust Auditor, l’outil communautaire gratuit.

Conclusion

Microsoft ADCS fournit des fonctions PKI essentielles, mais une mauvaise configuration peut entraîner des risques sérieux. Web Enrollment et NDES nécessitent une attention particulière et sont à éviter sauf nécessité ; s’ils sont déployés, des contrôles complets sont indispensables. Des solutions comme PKI Trust Cloud et PKI Trust Manager offrent une gestion moderne des certificats, tandis que PKI Trust Auditor aide à évaluer en continu la sécurité. Une gestion proactive renforce la posture PKI et réduit les risques opérationnels.