CVE-2026-54121 « Certighost » : comment un compte machine ordinaire forge un certificat de contrôleur de domaine dans AD CS

Rapport CTI technique du 15 août 2026

Résumé exécutif

CVE-2026-54121, baptisée « Certighost » par les chercheurs Aniq Fakhrul et Muhammad Ali qui l'ont découverte et signalée à Microsoft en mai 2026, touche Active Directory Certificate Services (AD CS), le rôle Windows Server qui fait office d'autorité de certification interne pour l'authentification, le chiffrement et la signature sur un domaine. Une faille d'autorisation incorrecte, notée CVSS 8.8, permet à n'importe quel compte de domaine authentifié, sans droit d'administration, de manipuler les attributs d'un compte machine et d'obtenir de l'autorité de certification un certificat qui authentifie comme un contrôleur de domaine via PKINIT. Microsoft a corrigé le problème en juillet 2026 ; les chercheurs ont publié un PoC complet et une analyse technique le 27 juillet, sans preuve d'exploitation active à cette date.

L'intérêt du bug pour un red teamer tient à son point d'entrée : le mécanisme de résolution d'identité en environnement multi-contrôleur de domaine de l'autorité de certification accepte, sans validation suffisante, un hôte et un principal fournis par le demandeur lui-même dans sa requête d'enrôlement. Un compte machine ordinaire, créé via le quota par défaut ms-DS-MachineAccountQuota qu'un utilisateur standard peut exploiter pour joindre des machines au domaine, suffit à faire passer les contrôles d'identité de l'autorité de certification. Le certificat obtenu ouvre la voie à une authentification PKINIT en tant que contrôleur de domaine, puis à un DCSync pour extraire le secret krbtgt, la clé maîtresse de tout le Kerberos du domaine. Un compte utilisateur banal devient ainsi la porte d'entrée vers une compromission totale de l'annuaire.

Chronologie

Date	Événement
Mai 2026	Aniq Fakhrul et Muhammad Ali signalent CVE-2026-54121 à Microsoft
14 juillet 2026	Microsoft publie le correctif dans les mises à jour de juillet pour Windows Server et Windows 10 ; le bug est jugé « moins probable » à être exploité
27 juillet 2026	Les chercheurs publient le PoC public et l'analyse technique complète (« Certighost »), accompagnés d'un contournement par flag de stratégie
15 août 2026	Aucun rapport public d'exploitation confirmée en conditions réelles à la date de rédaction ; le PoC reste disponible publiquement depuis trois semaines

Fiche vulnérabilité (format fiche CTI)

CVE-2026-54121 | CVSS 8.8 | Active Directory Certificate Services (rôle Certification Authority), Windows Server

Description technique : lorsque l'autorité de certification AD CS traite une requête d'enrôlement, elle doit résoudre l'identité du demandeur en recherchant un objet annuaire correspondant. Dans certains scénarios d'enrôlement inter-contrôleurs de domaine, la CA effectue une seconde recherche (« chase ») en contactant un autre hôte pour récupérer cet objet. Deux attributs fournis dans la requête de certificat pilotent cette recherche : cdc (Client DC), qui désigne l'hôte que la CA doit contacter, et rmd (Remote Domain), qui désigne le principal à rechercher. Lorsque les deux sont présents, la CA ouvre des connexions SMB et LDAP vers l'hôte désigné par cdc, potentiellement contrôlé par l'attaquant, recherche le principal désigné par rmd, puis construit le certificat à partir des données d'identité reçues. L'hôte factice passe les contrôles d'authentification de la CA parce qu'un compte machine créé via le quota par défaut est lui-même un principal de domaine valide, ce qui suffit à satisfaire les vérifications requises même s'il ne s'agit pas du contrôleur de domaine réellement usurpé. CWE-863 (Incorrect Authorization) et CWE-290 (Authentication Bypass by Spoofing) couvrent le mécanisme ; la logique de « chase » non validée s'apparente également à un scénario de type SSRF côté serveur (CWE-918).

Conditions d'exploitation : accès réseau au contrôleur de domaine et à l'autorité de certification, compte de domaine authentifié standard, sans droit d'administration. L'attaquant doit pouvoir héberger le service SMB/LDAP factice que la CA va contacter, généralement via un compte machine qu'il contrôle.

PoC disponible : oui, publié par les chercheurs (github.com/aniqfakhrul/CVE-2026-54121), accompagné d'une analyse technique complète.

Patch/mitigation : mise à jour de juillet 2026 pour Windows Server et Windows 10, qui valide la cible du « chase » avant d'engager la recherche. À défaut de pouvoir déployer immédiatement le correctif, la fonctionnalité de « chase » optionnelle peut être désactivée par stratégie : certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC, suivi d'un redémarrage du service (Restart-Service CertSvc -Force).

Diagramme de la chaîne d'attaque

De la requête d'enrôlement forgée au DCSync sur le secret krbtgt. Sources : Help Net Security, dépôt GitHub des chercheurs.

Analyse technique

Étape 1 : préparation du compte machine attaquant

L'attaquant, muni d'un compte de domaine standard, crée un compte machine via le quota ms-DS-MachineAccountQuota, disponible par défaut à tout utilisateur authentifié dans la plupart des déploiements Active Directory. Ce compte machine sert de point d'appui : il constitue un principal de domaine valide, condition suffisante pour passer les contrôles d'identité que la CA applique à l'hôte contacté lors du « chase ».

Étape 2 : requête d'enrôlement avec attributs cdc et rmd forgés

L'attaquant soumet une requête de certificat à l'autorité de certification AD CS en renseignant l'attribut cdc avec l'adresse de son propre hôte (le compte machine préparé à l'étape 1) et l'attribut rmd avec le principal qu'il souhaite usurper, typiquement le compte d'un contrôleur de domaine cible.

Étape 3 : la CA exécute le chase vers l'hôte contrôlé par l'attaquant

En traitant la requête, la CA ouvre des connexions SMB et LDAP vers l'hôte désigné par cdc. Comme ce dernier est un principal de domaine valide, les vérifications d'authentification de la CA passent sans déclencher d'alerte, même si l'hôte contacté n'est pas le contrôleur de domaine légitime.

Étape 4 : émission du certificat usurpant l'identité du contrôleur de domaine

La CA construit le certificat en utilisant les données d'identité renvoyées par l'hôte factice, en l'occurrence celles du principal désigné par rmd. Le certificat signé qui en résulte authentifie comme le contrôleur de domaine ciblé, alors qu'il a été délivré à un compte utilisateur ordinaire.

Étape 5 : authentification PKINIT et DCSync

Le certificat forgé sert à une authentification Kerberos PKINIT en tant que compte de contrôleur de domaine. Ce compte disposant des droits de réplication d'annuaire, l'attaquant lance une opération DCSync pour extraire le secret krbtgt, transformant un compte utilisateur banal en compromission complète du domaine Active Directory.

Indicateurs de compromission

Type	Valeur
Requête d'enrôlement suspecte	Requête de certificat contenant simultanément les attributs cdc et rmd renseignés par un compte non-administrateur
Connexions réseau anormales	Connexions SMB/LDAP sortantes de la CA vers un hôte correspondant à un compte machine récemment créé
Réplication anormale	Requête DCSync (DRSGetNCChanges) émise par un compte contrôleur de domaine ne correspondant pas à un DC physique connu
Comptes machines	Création récente de comptes machines par des comptes utilisateurs standards, à corréler avec les journaux d'événements 4741/4742

Aucun IOC réseau spécifique à une campagne active n'a été publié à la date de rédaction, faute d'exploitation confirmée en conditions réelles.

MITRE ATT&CK

Tactique	Technique	ID	Justification
Privilege Escalation	Steal or Forge Authentication Certificates	T1649	Obtention d'un certificat AD CS usurpant l'identité d'un contrôleur de domaine via manipulation de la requête d'enrôlement
Credential Access	OS Credential Dumping: DCSync	T1003.006	Extraction du secret krbtgt via réplication d'annuaire une fois l'identité de contrôleur de domaine obtenue
Persistence / Lateral Movement	Valid Accounts: Domain Accounts	T1078.002	Le certificat forgé permet une authentification PKINIT persistante en tant que compte de domaine privilégié
Defense Evasion	Impersonation	T1656	Usurpation de l'identité d'un contrôleur de domaine légitime sans compromission préalable de ses identifiants

Cette cartographie est une lecture technique construite par la rédaction à partir de l'analyse publiée par les chercheurs, pas une attribution vendeur officielle.

Remédiation : checklist opérationnelle

Déployer la mise à jour de juillet 2026 sur tous les contrôleurs de domaine et serveurs hébergeant le rôle AD CS.
Si le correctif ne peut être appliqué immédiatement, désactiver la fonctionnalité de « chase » optionnelle via certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC puis redémarrer le service CertSvc.
Auditer la valeur de ms-DS-MachineAccountQuota et l'abaisser à 0 si la création libre de comptes machines par des utilisateurs standards n'est pas un besoin métier justifié.
Mettre en place une surveillance des requêtes d'enrôlement de certificats contenant les attributs cdc et rmd, en particulier lorsqu'elles émanent de comptes non-administrateurs.
Corréler les opérations DCSync avec la liste des contrôleurs de domaine physiques connus et alerter sur toute réplication émise par un compte hors de cette liste.
Revoir les permissions déléguées sur les modèles de certificats AD CS pour limiter les templates permettant l'authentification comme compte machine ou contrôleur de domaine aux seuls comptes strictement nécessaires.