Certighost (CVE-2026-54121) : quand AD CS fait confiance à un faux contrôleur de domaine

Un compte utilisateur standard, sans le moindre droit d’administration, qui finit par récupérer le hash krbtgt de ton domaine Active Directory. Pas de phishing, pas d’exploit mémoire exotique : juste une requête de certificat mal validée. C’est ce que permet Certighost (CVE-2026-54121), une faille dans Active Directory Certificate Services corrigée par Microsoft en juillet 2026, mais qui reste exploitable sur tous les parcs qui n’ont pas encore appliqué ce correctif précis.

Le détail qui fait mal : le CVSS est de 8,8, pas 9,8 ou 10 comme les failles qui font les gros titres. Mais l’impact, lui, est maximal — une compromission complète du domaine depuis un compte de domaine ordinaire, sans interaction utilisateur. Si tu gères une infrastructure AD CS, cet article t’explique exactement comment ça marche, qui est concerné, et ce que tu dois vérifier dès aujourd’hui.

Le mécanisme de repli qui ne vérifie rien

AD CS prévoit un cas de figure particulier : quand l’autorité de certification (CA) ne parvient pas à récupérer les informations d’identité d’un demandeur auprès du contrôleur de domaine par défaut, elle peut suivre un mécanisme de repli, appelé « chase », vers un autre hôte désigné par la requête elle-même via l’attribut cdc (Client DC). Jusqu’en juillet 2026, la CA contactait cet hôte en SMB (port 445) et LDAP (port 389) sans jamais vérifier qu’il s’agissait réellement d’un contrôleur de domaine du domaine. Elle faisait simplement confiance à ce que le demandeur affirmait.

Concrètement, l’attaque se déroule en six étapes :

• L’attaquant crée un compte machine, en s’appuyant sur le quota par défaut ms-DS-MachineAccountQuota fixé à 10 — accessible à n’importe quel utilisateur de domaine standard — ou réutilise un compte qu’il contrôle déjà.
• Il monte une infrastructure LSA et LDAP falsifiée sur sa propre machine, en écoute sur les ports 445 et 389.
• Il envoie une demande de certificat sur le modèle Machine par défaut, avec l’attribut cdc pointant vers sa propre machine plutôt que vers un vrai contrôleur de domaine.
• La CA suit cet hôte sans vérification et relaie la demande d’authentification via Netlogon vers le véritable contrôleur de domaine, récupérant au passage son objectSid et son dNSHostName.
• Le compte machine contrôlé par l’attaquant fournit alors l’identité valide nécessaire, et la CA émet un certificat qui porte l’identité du contrôleur de domaine ciblé — mais utilisable par le compte de l’attaquant.
• Avec ce certificat, l’attaquant s’authentifie via PKINIT en se faisant passer pour un contrôleur de domaine, puis lance un DCSync pour extraire les secrets du domaine, krbtgt en tête.

Aucune élévation de privilèges locale, aucun malware, aucun clic de l’utilisateur. Juste une CA qui fait confiance à la mauvaise source.

Qui est concerné

Selon la fiche NVD de la CVE, les versions affectées couvrent Windows Server 2012 jusqu’à Windows Server 2025, éditions Server Core incluses, ainsi que Windows 10 version 1607 et 1809. Les chercheurs qui ont publié l’analyse technique (dont Aniq Fakhrul) ont validé leurs tests sur une forêt Windows Server 2016 ou plus récente, avec une CA d’entreprise intégrée à Active Directory en configuration par défaut — exactement la configuration qu’on retrouve dans la majorité des environnements d’entreprise.

La faille a été signalée à Microsoft le 14 mai 2026, confirmée le 22 mai, corrigée le 14 juillet (Patch Tuesday du mois) et divulguée publiquement le 24 juillet. Du code de preuve de concept circule librement sur GitHub depuis cette date. À ce jour, elle ne figure pas dans le catalogue KEV de la CISA et aucune exploitation active confirmée n’a été rapportée publiquement — mais l’historique des failles AD CS (ESC1 à ESC15) montre que ce genre de scénario finit presque toujours par être industrialisé dans des frameworks d’attaque une fois le mécanisme bien documenté, comme ça a été le cas pour BadSuccessor quelques mois plus tôt.

Le correctif de Microsoft, et sa nuance importante

Le patch de juillet ajoute une validation stricte de la cible du mécanisme de repli avant que la CA ne la contacte : rejet des adresses IP brutes, rejet des noms trop longs, filtrage de certains caractères LDAP, et surtout exigence d’un objet ordinateur unique dont l’attribut userAccountControl inclut bien le flag SERVER_TRUST_ACCOUNT (valeur 8192). Une comparaison de SID en sortie bloque ensuite toute substitution d’objet au dernier moment.

Il y a cependant un détail technique à connaître : cette protection passe par un interrupteur de fonctionnalité interne (identifié par les chercheurs comme Feature_3185813818). Si ce flag se retrouve désactivé — configuration héritée, stratégie de groupe particulière, ou simple erreur — le comportement vulnérable d’origine peut potentiellement réapparaître même avec le correctif installé. Ne te contente donc pas de vérifier la présence de la mise à jour de juillet 2026 : vérifie aussi, si tu as un outil de gestion de configuration en place, que ce comportement de validation est bien actif sur tes serveurs AD CS.

Si tu ne peux pas patcher immédiatement

Pour les serveurs où le correctif ne peut pas être déployé tout de suite — fenêtre de maintenance à planifier, validation de changement en cours — il existe un contournement temporaire : désactiver le drapeau EditFlags qui active le chase côté CA.

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force

Attention : ce contournement n’a été validé qu’en laboratoire par les chercheurs à l’origine de la découverte, pas par Microsoft lui-même. Il peut casser des flux d’inscription de certificats légitimes qui dépendent justement de ce mécanisme de repli, notamment dans les environnements multi-forêts ou multi-sites avec de la latence réseau entre contrôleurs de domaine. Teste-le d’abord en pré-production, sur un CA de test, avant d’y toucher en production.

Pour les systèmes qui ne reçoivent plus de mises à jour officielles (Windows Server 2008 R2, 2012 et 2012 R2 en fin de support), 0patch a publié des micropatches logiquement identiques au correctif Microsoft, appliqués sans redémarrage sur les machines qui disposent de l’agent.

Détecter une tentative d’exploitation

Microsoft Defender signale les requêtes malveillantes sous deux alertes dédiées : « Potential Certighost (CVE-2026-54121) AD CS abuse » et « Active Directory Certificate Services attack tool activity ». Si tu n’as pas Defender for Identity déployé sur tes serveurs AD CS, trois réflexes à adopter dès cette semaine :

• Active l’audit des services de certificats (succès et échecs) sur la CA, et configure le filtre d’audit pour couvrir les événements de cycle de vie des certificats.
• Surveille les événements de sécurité 4886 et 4887 (demande de certificat et émission) à la recherche de volumes ou de patterns inhabituels, en particulier des émissions issues du modèle Machine qui portent des données d’identité de contrôleur de domaine inattendues.
• Audite la valeur de ms-DS-MachineAccountQuota sur ton domaine — la valeur par défaut de 10 autorise n’importe quel utilisateur standard à créer jusqu’à dix comptes machine, ce qui est la première brique de cette attaque (et de pas mal d’autres). La ramener à 0 pour les utilisateurs non-admin, avec des exceptions ciblées via délégation, ferme cette porte sans casser les joiners légitimes gérés par un compte de service dédié.

Pour un audit plus poussé de ta hiérarchie PKI, l’outil open source PSPKIAudit (cité par plusieurs analyses de la faille) permet de repérer les templates de certificats mal configurés et les CA exposées à ce type de scénario de relais, dans la même veine que les vulnérabilités ESC1 à ESC15 déjà documentées.

Pourquoi un 8.8 mérite autant d’attention qu’un 9.8

On a tendance à classer les priorités de patch par score CVSS brut, et à reléguer un 8.8 derrière les zero-days à 9.8 ou 10 qui font la une des bulletins mensuels. C’est une erreur dans ce cas précis. Un 9.8 typique touche souvent un service exposé qu’on peut isoler ou filtrer en attendant le correctif. Certighost, lui, touche le cœur de confiance de ton infrastructure d’identité, depuis un compte de domaine banal, sans qu’aucune segmentation réseau classique ne t’en protège — si l’utilisateur a accès au réseau du contrôleur de domaine et de la CA, l’attaque est jouable. Le score reflète la complexité d’exploitation (il faut une CA d’entreprise, un modèle Machine accessible, et une connectivité SMB/LDAP spécifique), pas la gravité du résultat une fois l’attaque réussie.

FAQ

Faut-il désactiver AD CS en attendant de tout vérifier ?

Non, ce serait disproportionné pour la quasi-totalité des environnements. Priorise la vérification du patch de juillet 2026 sur tes serveurs AD CS, et si ce n’est pas possible immédiatement, applique le contournement EditFlags après test en pré-production.

Un pare-feu entre les sites suffit-il à me protéger ?

Seulement si l’attaquant n’a pas accès réseau à la fois à la CA et au vrai contrôleur de domaine. Dans la plupart des topologies d’entreprise avec des contrôleurs de domaine accessibles depuis le réseau utilisateur, ce n’est pas une protection suffisante — le patch ou le contournement reste nécessaire.

Le correctif de juillet 2026 est-il inclus dans les mises à jour cumulatives suivantes ?

Oui, comme tout correctif de sécurité Windows, il est intégré aux cumulative updates ultérieures. Si tu es à jour sur ton Patch Tuesday depuis juillet 2026, tu l’as déjà. L’enjeu réel pour la plupart des équipes est de vérifier les serveurs AD CS isolés ou en retard de patch, pas les postes clients.

Comment savoir si le flag Feature_3185813818 est actif chez moi ?

Microsoft n’a pas publié de commande officielle pour l’interroger directement à ce jour. Le plus fiable reste un test fonctionnel en environnement de pré-production : tenter de reproduire le scénario d’attaque documenté par les chercheurs et vérifier que la demande de certificat est bien rejetée après le patch de juillet.

En pratique, cette semaine

Vérifie que tes serveurs AD CS ont bien reçu la mise à jour de juillet 2026, audite ta valeur de ms-DS-MachineAccountQuota, et active l’audit des événements 4886/4887 si ce n’est pas déjà fait. Trois actions concrètes, aucune ne demande de fenêtre de maintenance longue, et elles réduisent une surface d’attaque qui touche directement krbtgt — le cœur de la confiance Kerberos de ton domaine, le même mécanisme qui a justifié la bascule forcée de RC4 vers AES quelques semaines plus tôt.