Certighost (CVE-2026-54121) : n'importe quel compte AD peut se faire passer pour un Domain Controller

Cybersécurité il y a 22 hAjouter aux favoris

Certighost (CVE-2026-54121) : n'importe quel compte AD peut se faire passer pour un Domain Controller
Illustration : Momiji Shirogane

CVE-2026-54121, CVSS 8.8. Un compte de domaine sans aucun privilège suffit à obtenir un certificat AD CS signé pour l'identité d'un Domain Controller, puis à s'authentifier via PKINIT et à extraire krbtgt via DCSync. Patché le 14 juillet 2026, exploit public depuis aujourd'hui.

Les faits

Les chercheurs H0j3n et Aniq Fakhrul publient ce 24 juillet 2026 la mécanique complète de Certighost - CVE-2026-54121, CVSS 8.8 - une élévation de privilèges à l'échelle de la forêt Active Directory, qui exploite un chemin de repli du protocole d'enrôlement de Active Directory Certificate Services (AD CS).

Chronologie officielle :

  • 14 mai 2026 - rapport à Microsoft (MSRC).
  • 22 mai 2026 - Microsoft confirme la faille.
  • 14 juillet 2026 - patch livré dans le Patch Tuesday.
  • 24 juillet 2026 - publication technique + exploit fonctionnel.

Systèmes affectés : Windows Server 2012 à 2025, Windows 10 versions 1607 et 1809. Autant dire : la quasi-totalité du parc AD CS déployé aujourd'hui.

Analyse - la mécanique « chase »

L'enrôlement AD CS permet à une machine de demander un certificat pour son propre objectSid et dNSHostName. Lorsque la CA (Certificate Authority) ne dispose pas des informations end-entity nécessaires, elle utilise un fallback interne baptisé « chase » dans le code Microsoft. Ce fallback autorise le demandeur à spécifier :

  • cdc - le host du Domain Controller à interroger,
  • rmd - l'objet machine à résoudre.

La faille tient en une ligne : la CA suivait le cdc fourni par le demandeur via SMB et LDAP sans vérifier au préalable qu'il s'agissait d'un vrai Domain Controller. Autrement dit, elle acceptait de dialoguer avec n'importe quel host reachable comme s'il faisait autorité.

Chaîne d'attaque

Un utilisateur du domaine, sans privilège admin, procède ainsi :

  1. Il crée (ou réutilise) un computer account - dans un tenant par défaut, ms-DS-MachineAccountQuota = 10 permet à tout user de créer jusqu'à dix machines.
  2. Il lance des services LSA et LDAP rogue sur son poste, reachable par la CA.
  3. Il déclenche une requête d'enrôlement avec cdc pointant sur son propre host.
  4. La CA se connecte à son service SMB, relaie le challenge d'authentification vers le vrai DC via Netlogon, et l'attaquant renvoie les objectSid + dNSHostName du DC cible.
  5. La CA délivre un certificat signé pour l'identité du Domain Controller cible.
  6. L'attaquant s'authentifie via PKINIT avec ce certificat - il est maintenant le DC aux yeux du domaine.
  7. DCSync : il extrait la clé krbtgt. Game over.

Prérequis : accès réseau vers la CA depuis les écouteurs SMB/LDAP de l'attaquant, un compte de domaine valide, une CA d'entreprise avec le chemin de chase vulnérable, template Machine par défaut activé pour l'enrôlement.

Qui est impacté

  • Toute forêt AD avec AD CS déployé et un template Machine (ou équivalent) accessible aux utilisateurs authentifiés - ce qui reste la config par défaut dans énormément de tenants.
  • Vecteur interne : ne se déclenche qu'avec un compte de domaine valide, mais sans aucun privilège élevé.
  • Cible finale : domain compromise complet via krbtgt.

Le fix Microsoft

Le patch de juillet ajoute la routine CRequestInstance::_ValidateChaseTargetIsDC, qui rejette :

  • les littéraux IP dans cdc,
  • les noms anormalement longs ou contenant des métacaractères LDAP,
  • et exige un match exact sur un objet computer Active Directory avec le flag SERVER_TRUST_ACCOUNTet vérification de son SID.

Autrement dit : la CA ne fait plus confiance à ce que raconte le client, elle vérifie qu'elle parle bien à un DC légitime enregistré dans AD.

À faire maintenant

  1. Appliquez le Patch Tuesday de juillet 2026 sur tous vos serveurs AD CS. C'est la seule vraie réponse.
  2. En attendant le patch, workaround labo-testé uniquement, à ne pas déployer en prod sans validation :
    certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
    Restart-Service CertSvc -Force

    Cette clé désactive le comportement chase côté CA. Vérifiez l'impact sur vos flux d'enrôlement legacy avant.

  3. Réduisez ms-DS-MachineAccountQuota à 0 pour les users standard - bonne pratique générale, indépendamment de Certighost.
  4. Monitorez vos logs CA (EventID 4886/4887 dans Windows Security) pour toute requête d'enrôlement inhabituelle sur le template Machine.

À faire maintenant - l'essentiel

Patch Tuesday juillet 2026 + baisse de MachineAccountQuota à 0. Le PoC est public, la fenêtre d'exploitation opportuniste s'ouvre maintenant.

Certighost rejoint la famille des attaques AD CS post-Certipy (ESC1 à ESC15) qui font de l'infrastructure PKI Windows l'un des chemins d'escalation les plus fiables sur un domaine mal durci. Le message n'a pas changé depuis SpecterOps : auditez vos templates AD CS.

Article produit par intelligence artificielle, relu sous contrôle éditorial humain.

Notre rédaction
Cet article vous a-t-il été utile ?

3 personnes ont aimé cet article

J'aime
K
Kenji AraiExpert cybersécurité
Expert cybersécurité, veilleur méthodique, jamais alarmiste, toujours actionnable.
Partager :
LIVERadio Geek Kitsune
Clique pour écouter, le même son pour tout le monde
0··
// Programme
// toutes les stations
// partager un titre →
Rubriques
Explorer
Informations