<p>Un code d'exploitation prêt à l'emploi a été publié le 27 juillet 2026 pour une faille des Services de certificats Active Directory. Un simple...
Le 27 juillet 2026, deux chercheurs en sécurité, H0j3n et Aniq Fakhrul, ont publié les détails techniques et un code d'exploitation prêt à l'emploi pour une faille baptisée « Certighost », référencée CVE-2026-54121. Elle touche les Services de certificats Active Directory (AD CS), le composant qui délivre les certificats d'authentification dans un domaine Windows. Microsoft a corrigé le problème le 8 juillet 2026. Le risque porte donc désormais sur les serveurs qui n'ont pas encore reçu cette mise à jour — une situation banale en pleine période estivale, quand les fenêtres de maintenance se réduisent. Dans un domaine Active Directory, le contrôleur de domaine est l'autorité qui décide qui est qui. Le rôle AD CS, lui, distribue les certificats qui servent de pièces d'identité numériques. Certighost permet à un simple compte utilisateur du domaine, sans aucun privilège particulier, de se faire passer pour un contrôleur de domaine auprès de cette autorité de certification.
Le déroulé technique tient en quelques étapes. L'attaquant crée d'abord un compte machine — une opération autorisée par défaut à tout utilisateur, via le paramètre ms-DS-MachineAccountQuota réglé à 10 dans une installation standard de Windows. Il abuse ensuite du mécanisme de délivrance pour obtenir un certificat émis au nom d'un contrôleur de domaine, s'authentifie avec ce certificat via PKINIT, puis récupère le condensat NT du compte usurpé.
L'exploit publié ne s'arrête pas là: il enchaîne automatiquement sur une attaque DCSync, qui extrait le secret du compte krbtgt. Ce compte est la clé maîtresse du domaine. Avec ce secret, un attaquant peut fabriquer des tickets Kerberos valides pour n'importe quel compte, administrateur du domaine compris, et conserver cet accès même après un changement généralisé de mots de passe.
Pourquoi une PME est concernée
Le point important n'est pas la sophistication de l'attaque, mais son point de départ: elle ne demande aucun privilège élevé. Un seul compte compromis suffit. Un mot de passe récupéré par hameçonnage, l'accès d'un stagiaire, le compte d'un prestataire, un poste infecté: à partir de là, on passe d'un « accès utilisateur banal » à un contrôle total du système d'information.
Toute organisation qui dispose d'un serveur Windows avec un domaine Active Directory et le rôle AD CS installé est exposée. Or ce rôle est plus répandu qu'on ne l'imagine dans les PME: il est activé dès qu'on émet des certificats internes pour le Wi-Fi en 802.1X, un VPN, des services Bureau à distance (RDS), une messagerie interne ou des cartes à puce.
Aucune exploitation en environnement réel n'est confirmée à ce jour. Mais la publication d'un code d'exploitation fonctionnel fait basculer cette faille du statut « théorique » à « exploitable par un attaquant peu qualifié dans les jours qui viennent ». L'historique des vulnérabilités AD CS — PetitPotam, la série ESC1 à ESC8 — montre que le délai entre la publication d'un exploit et son exploitation à grande échelle se compte généralement en jours. 1. Appliquer le correctif, en priorité absolue. Vérifiez que les mises à jour Microsoft de juillet 2026 (Patch Tuesday du 8 juillet) sont bien installées sur tous les contrôleurs de domaine ainsi que sur le ou les serveurs hébergeant le rôle AD CS, puis redémarrez. C'est la seule correction définitive: Microsoft y ajoute la vérification que le serveur annoncé est bien un contrôleur de domaine légitime.
2. Savoir si vous êtes concerné. Si vous ne savez pas si le rôle AD CS est présent sur votre infrastructure, votre prestataire informatique peut le déterminer en quelques minutes. Cette question doit être posée cette semaine, pas au retour des congés.
3. Si la mise à jour ne peut pas être appliquée immédiatement. Sur un serveur critique dont la fenêtre de maintenance est en août, une mesure temporaire existe sur le serveur AD CS: désactiver le mécanisme de repli avec certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC puis Restart-Service CertSvc -Force. À tester d'abord hors production: les chercheurs précisent que ce contournement n'a pas été validé en environnement de production. Il doit être suivi de la mise à jour dès que possible.
4. Réduire la surface d'attaque durablement. Passez le paramètre ms-DS-MachineAccountQuota de 10 à 0 dans Active Directory. Un utilisateur standard n'a aucune raison légitime de créer des comptes machine, et cette valeur par défaut sert de tremplin à de nombreuses attaques AD, pas seulement Certighost. À valider au préalable avec votre prestataire si vous utilisez des outils automatisés de déploiement de postes.
5. Surveiller les signaux d'alerte. Sur le serveur AD CS, repérez dans le journal de sécurité les demandes de certificat émises pour un compte machine se terminant par « $ » et provenant d'un demandeur inhabituel (événements 4886 et 4887). Sur les contrôleurs de domaine, surveillez les authentifications PKINIT anormales et toute réplication d'annuaire (DCSync) initiée depuis une machine qui n'est pas un contrôleur de domaine (événement 4662 avec le GUID de réplication).
6. Préparer le plan de repli. Si une compromission est suspectée, la fuite du secret krbtgt impose une double rotation du mot de passe de ce compte, espacée de la durée de vie maximale des tickets — 10 heures par défaut, un délai qu'il ne faut pas précipiter sous peine de couper toutes les authentifications. L'opération est délicate: ne l'improvisez pas, faites appel à un prestataire. En cas d'incident avéré, déposez plainte et rapprochez-vous de cybermalveillance.gouv.fr.
7. Verrouiller la porte d'entrée. Activez l'authentification multifacteur sur tous les accès distants: VPN, RDS, messagerie. L'attaque suppose au départ un compte du domaine valide. Empêcher le vol de ce premier compte reste la meilleure barrière.
Ce que cette faille rappelle
Certighost illustre un principe que les PME ont tout intérêt à intégrer: dans un domaine Active Directory, la distance entre un compte utilisateur ordinaire et le contrôle total de l'infrastructure est souvent bien plus courte qu'on ne le croit. La faille elle-même est corrigée depuis trois semaines. Ce qui fait le risque aujourd'hui, ce n'est pas la vulnérabilité de Microsoft, c'est le délai entre la publication d'un correctif et son application réelle.
Deux réflexes se dégagent, valables bien au-delà de cette CVE: traiter les mises à jour des contrôleurs de domaine comme une opération prioritaire et non comme une tâche de fond, et réduire les permissions accordées par défaut aux comptes utilisateurs — le quota de comptes machine en étant l'exemple le plus parlant. Si vous n'êtes pas certain de la configuration de votre Active Directory, c'est le bon moment pour faire le point.
- Publication technique et code de démonstration des chercheurs H0j3n et Aniq Fakhrul, 27 juillet 2026 (description de la chaîne d'attaque et de l'outil de démonstration).
- Bulletin de sécurité Microsoft relatif à CVE-2026-54121, corrigé dans les mises à jour cumulatives du 8 juillet 2026 (msrc.microsoft.com) — référence à vérifier auprès de Microsoft pour la liste exacte des versions concernées avant toute décision de maintenance.
- Pour la conduite à tenir en cas de compromission suspectée: cybermalveillance.gouv.fr et les recommandations de l'ANSSI sur la sécurisation d'Active Directory (cyber.gouv.fr).
Cet article est une synthèse rédactionnelle originale de TICLIC, établie à partir de notre veille de sécurité du 28 juillet 2026. Aucune exploitation en environnement réel n'était confirmée à cette date. Les éléments techniques (identifiants d'événements, commandes, paramètres) sont donnés à titre indicatif et doivent être validés sur votre propre infrastructure, idéalement avec votre prestataire, avant toute application en production.