Certighost est l’exploit qui transforme un simple compte Active Directory en contrôleur de domaine : un utilisateur non privilégié obtient un certificat lui permettant de s’authentifier comme un DC, puis de rejouer les privilèges les plus élevés du domaine. Un PoC public circule déjà. Pour une PME-ETI dont l’annuaire pilote la messagerie, les partages et le VPN, Certighost revient à donner les clés du domaine à n’importe quel salarié — ou à n’importe quel attaquant ayant volé un seul mot de passe.
Certighost : comment un compte standard devient contrôleur de domaine
La faille exploite la chaîne de confiance entre Active Directory Certificate Services (AD CS) et l’authentification Kerberos. Le principe est brutalement simple :
- Un utilisateur du domaine, sans droit particulier, demande un certificat via un modèle mal restreint.
- Le champ d’identité du certificat est manipulé pour désigner un compte machine de contrôleur de domaine et non l’utilisateur demandeur.
- L’autorité de certification interne signe le certificat sans revalider l’identité réelle.
- Le certificat est présenté à Kerberos (PKINIT), qui délivre un ticket au nom du DC.
- L’attaquant dispose alors des droits de réplication : extraction complète de la base d’annuaire, y compris les empreintes de mots de passe.
Autrement dit, aucune vulnérabilité mémoire, aucun malware, aucun 0-day exotique : Certighost est un abus de configuration légitime. C’est ce qui le rend redoutable — le trafic ressemble à de l’usage normal d’AD CS, et les outils de détection classiques restent muets.
Pourquoi les PME-ETI sont particulièrement exposées
Les autorités de certification internes sont souvent déployées une fois, pour un projet précis (Wi-Fi 802.1X, VPN, signature de postes), puis oubliées. Les modèles de certificats gardent alors leurs paramètres d’origine, généreux par défaut. Trois facteurs aggravants reviennent systématiquement dans nos audits :
- Le serveur AD CS est installé sur un contrôleur de domaine, ce qui supprime toute barrière d’isolement.
- Les modèles autorisent l’inscription à Utilisateurs du domaine avec un nom de sujet fourni par le demandeur.
- Personne ne surveille les journaux de l’autorité de certification, considérés comme du bruit d’infrastructure.
Détecter Certighost avant l’extraction de l’annuaire
La bonne nouvelle : l’attaque laisse des traces exploitables, à condition de les collecter. Priorisez ces signaux de détection.
Journaux à activer immédiatement
- Événement 4886 / 4887 sur le serveur AD CS : demande et émission de certificat. Alertez sur tout certificat émis à un compte utilisateur mais portant un Subject Alternative Name correspondant à un compte machine.
- Événement 4768 sur les contrôleurs de domaine : ticket Kerberos accordé via certificat. Croisez l’identité demandée avec l’origine réseau du poste.
- Événement 4662 avec les GUID de réplication (DS-Replication-Get-Changes-All) : toute réplication initiée depuis une adresse qui n’est pas un DC légitime est un incident, pas une anomalie.
Requête de chasse à lancer aujourd’hui
Extrayez la liste des certificats émis sur les 90 derniers jours et isolez ceux dont le sujet ne correspond pas au demandeur. Sur une infrastructure saine, le résultat doit être vide. Toute ligne retournée mérite une investigation immédiate, y compris rétroactive : Certighost a pu être exploité avant la publication du PoC.
Corriger : durcir AD CS en quatre actions
La remédiation ne dépend pas d’un correctif éditeur, mais de votre configuration. Ces quatre actions ferment la porte :
- Interdire le nom de sujet fourni par le demandeur. Sur chaque modèle de certificat, forcez la construction du sujet à partir de l’annuaire (Build from this Active Directory information). C’est la mesure qui neutralise directement l’exploit.
- Exiger l’approbation d’un gestionnaire pour tout modèle permettant l’authentification client.
- Activer le mappage fort des certificats (extension SID) et passer les contrôleurs de domaine en mode d’application stricte, afin qu’un certificat sans lien fort soit rejeté par Kerberos.
- Sortir l’autorité de certification des contrôleurs de domaine et la traiter comme un actif de niveau 0 : administration dédiée, MFA, journalisation externalisée.
Et si la compromission est déjà avérée ?
Un attaquant ayant obtenu un certificat conserve son accès même après un changement de mot de passe : le certificat reste valide jusqu’à son expiration. La réponse à incident impose donc de révoquer les certificats suspects, publier une nouvelle liste de révocation, puis effectuer un double changement du mot de passe du compte krbtgt. Sans cette étape, la persistance survit à la remédiation.
Certighost s’inscrit dans la bascule vers les attaques d’identité
Cet exploit confirme une tendance de fond : les attaquants ne forcent plus le périmètre, ils empruntent des identités valides. Nous l’avons documenté à propos des attaques par identité devenues la porte d’entrée des ransomwares et du phishing par device code sur Microsoft 365. Certighost pousse la logique à son terme : l’identité usurpée n’est plus celle d’un utilisateur, mais celle de l’infrastructure elle-même.
La priorité pour une PME-ETI est donc claire : auditer les modèles de certificats cette semaine, activer le mappage fort, et instrumenter les journaux AD CS dans votre SOC. Un Certighost détecté en quelques minutes reste un incident maîtrisé ; non détecté, il devient une reconstruction complète de l’annuaire.