Retour au blog
CVEActive DirectoryAD CSDCSyncagents IA

Certighost CVE-2026-54121 : AD CS jusqu'au DCSync

Publié le 2026-07-24 · Mis à jour le 2026-10-295 min de lecture
En bref : CVE-2026-54121, surnommée Certighost, est une faille d'autorisation dans Active Directory Certificate Services (CVSS 8.8, « improper authorization » selon Microsoft), corrigée le 14 juillet 2026. Un compte de domaine à faible privilège peut obtenir un certificat identifiant un contrôleur de domaine, s'authentifier comme lui par PKINIT, puis récupérer le secret krbtgt par DCSync. Les chercheurs H0j3n et Aniq Fakhrul ont publié un exploit fonctionnel le 24 juillet. Microsoft n'a pas confirmé d'exploitation par des acteurs malveillants, mais a prévenu que l'exploit public augmente le risque.

Quel est le mécanisme de Certighost ?

Selon l'analyse publiée par The Hacker News, la faille se situe dans un mécanisme de repli de l'inscription AD CS appelé « chase ». L'autorité de certification suivait un hôte cdc fourni par le demandeur, en SMB et en LDAP, sans vérifier qu'il s'agissait d'un vrai contrôleur de domaine. Un attaquant se faisait passer pour ce contrôleur, relayait le défi de l'autorité vers le vrai contrôleur via Netlogon, et obtenait un certificat identifiant la machine cible.

Ce certificat permet l'authentification PKINIT en tant que contrôleur de domaine. Les comptes de contrôleur détiennent les droits de réplication d'annuaire, donc DCSync devient possible et le secret krbtgt est récupérable. Qui le possède peut forger des tickets Kerberos pour n'importe quel utilisateur, y compris administrateur du domaine. La compromission du domaine part d'un simple compte utilisateur.

Quelles sont les conditions et quelles versions sont touchées ?

Les prérequis rapportés sont un compte de domaine à faible privilège, capable de créer un compte machine (le quota ms-DS-MachineAccountQuota vaut 10 par défaut) ou d'en réutiliser un qu'il contrôle, une autorité de certification d'entreprise qui emprunte le chemin vulnérable, l'inscription via le modèle Machine par défaut, et une connectivité réseau de l'autorité vers les écouteurs de l'attaquant. Aucun droit d'administrateur ni interaction d'utilisateur n'est requis.

La fiche NVD, citée par The Hacker News, liste Windows Server 2012 à 2025 (y compris Server Core) ainsi que Windows 10 versions 1607 et 1809. L'exploit public a été testé sur une forêt Windows Server 2016 ou plus récent avec une autorité d'entreprise. Chronologie : signalement à Microsoft le 14 mai, confirmation le 22 mai, correctif le 14 juillet, divulgation publique avec exploit le 24 juillet.

Comment détecter une tentative ?

  1. Activez l'audit de l'autorité de certification et surveillez les événements de sécurité 4886 (demande reçue) et 4887 (certificat émis), en repérant les certificats émis pour des noms de contrôleurs de domaine à partir de comptes utilisateurs ou de comptes machine récents.
  2. Cherchez les comptes machine créés par des utilisateurs standards peu avant une émission de certificat.
  3. Surveillez les connexions sortantes de l'autorité vers des hôtes qui ne sont pas des contrôleurs de domaine, en SMB, LDAP ou Netlogon.
  4. Repérez les DCSync : demandes de réplication d'annuaire venant d'une machine qui n'est pas un contrôleur.
  5. Utilisez les alertes Microsoft Defender nommées « Potential Certighost (CVE-2026-54121) AD CS abuse » si vous avez la licence.

Comment corriger ?

  1. Installez les mises à jour du 14 juillet 2026 sur chaque hôte AD CS. Le correctif de Microsoft valide la cible du « chase » avant que l'autorité ne la contacte.
  2. Si le correctif attend, les chercheurs indiquent que l'on peut effacer l'indicateur EDITF_ENABLECHASECLIENTDC puis redémarrer les services de certificats. Ils ne l'ont validé qu'en laboratoire et il peut casser des inscriptions légitimes : testez-le d'abord.
  3. Réduisez `ms-DS-MachineAccountQuota` à 0 si vos utilisateurs n'ont pas à joindre des machines.
  4. Limitez les modèles de certificat ouverts à l'inscription par les utilisateurs authentifiés.
  5. Revoyez la posture AD CS dans son ensemble, car la classe de faille revient : voir aussi notre article sur la sécurité cloud et les erreurs IAM pour la même logique de privilèges excessifs.

Que change un agent IA branché sur l'identité d'entreprise ?

Dans une entreprise sous Active Directory, un agent IA agit rarement avec une identité isolée. Il utilise un compte de service ou une identité déléguée pour lire des boîtes mail, des partages de fichiers, des tickets ou des annuaires. Les scénarios ci-dessous sont des hypothèses de test, pas des faits rapportés sur cette CVE.

Un domaine compromis rend toutes les identités d'agent forgeables. Avec krbtgt, un attaquant peut produire des tickets pour le compte de service de l'agent, et agir avec ses droits sans toucher à l'agent lui-même. Les journaux du côté de l'agent paraîtront normaux.

Le compte de service de l'agent est souvent surdimensionné. Pour que l'agent soit pratique, on lui donne de larges droits de lecture, parfois d'écriture. Dans un domaine tombé, ces droits deviennent immédiatement exploitables. Le principe de moindre privilège est le premier contrôle à tester.

Les secrets d'agent vivent dans le contexte. Jetons d'API, clés de connecteurs, identifiants de bases accessibles à l'agent sont lisibles par quiconque contrôle l'hôte ou le compte. Notre page sécurité des agents IA décrit comment les cloisonner.

Les actions automatiques n'ont pas de garde-fou. Un agent qui crée des comptes, change des droits ou envoie des documents sans validation humaine est un levier de persistance pour l'attaquant. Un compte créé ou des droits modifiés sans contrôle relèvent de l'excès d'autonomie (LLM06, OWASP Top 10 for LLM Applications 2025) : l'agent devient un levier de persistance.

L'attaquant peut aussi viser l'agent par le contenu. Une fois dans le domaine, déposer un document piégé dans un partage lu par l'agent revient à une injection de prompt indirecte (voir prompt injection), avec en prime la confiance accordée aux fichiers internes.

Contrôles à poser : comptes de service d'agent à portée minimale et sans privilège de domaine, jetons courts, segmentation entre l'agent et les contrôleurs, validation humaine des actions de gestion d'identité, journalisation séparée.

Comment tester cette surface sur un agent d'entreprise ?

On part du compte de l'agent : droits réels, groupes, secrets accessibles, actions possibles sans approbation, et ce qu'un contenu injecté peut lui faire faire. On teste aussi la reprise d'identité : ce que permet un ticket ou un jeton volé hors du contexte normal. Chaque point est documenté avec une preuve reproductible.

Pour un agent qui touche à l'annuaire et à ses certificats, notre Red Team Agent Express vérifie en 5 jours (1 900 €) jusqu'où une identité obtenue par ce biais peut aller, après un rendez-vous découverte gratuit de 30 minutes.

Votre produit embarque un agent IA ? CleanIssue teste ce qu’un inconnu peut lui faire faire avec le Red Team Agent Express (5 jours, 1 900 €), ou un red team sur mesure pour plusieurs agents et serveurs MCP. Premier échange : un rendez-vous découverte de 30 minutes, gratuit.

Sachez ce que votre agent peut faire avant un attaquant.

Rendez-vous découverte de 30 minutes, gratuit : vous décrivez votre agent, je vous dis ce que je testerais et à quel prix. Cinq études de cas sont publiées.

Prendre rendez-vous