ESC9 vs. ESC16 : même faille, rayon d'impact différent

ESC9 et ESC16 sont deux des techniques d'escalade numérotées (ESC) répertoriées pour Active Directory Certificate Services (AD CS), et il s'agit de la même vulnérabilité à des niveaux différents. Les deux suppriment l'extension de sécurité de l'identificateur de sécurité (SID) des certificats émis, ce qui permet à un attaquant d'usurper un autre compte via un mappage de certificat faible. ESC9 le fait sur un seul modèle de certificat. ESC16 le fait sur chaque certificat émis par une autorité de certification (CA).

Si vous avez corrigé ESC9 il y a quelques années, cela ne vous renseigne en rien sur ESC16.

Qu'est-ce que ESC9 ?

ESC9 est un paramètre de modèle. Lorsque CT_FLAG_NO_SECURITY_EXTENSION est défini dans l'attribut msPKI-Enrollment-Flag d'un modèle, les certificats émis à partir de ce modèle ne comportent pas l'extension SID (szOID_NTDS_CA_SECURITY_EXT). Cette extension permet à un contrôleur de domaine (DC) d'associer un certificat à un compte spécifique. Sans elle, le DC revient à la correspondance sur le nom principal de l'utilisateur (UPN).

L'attaque nécessite trois éléments : un attaquant avec un accès en écriture au UPN d'un compte victime (GenericWrite suffit), des droits d'inscription sur un modèle de client-authentication avec le drapeau activé, et un DC qui n'applique pas un mappage fort des certificats. L'attaquant modifie le UPN de la victime pour correspondre à un compte privilégié, s'inscrit, remet le UPN en place et s'authentifie avec le certificat en tant qu'utilisateur privilégié.

Oliver Lyak a documenté ESC9 en août 2022, et de nombreux scanners peuvent le détecter, y compris Netwrix PingCastle. La liste de contrôle ci-dessous montre comment vérifier vos propres modèles.

Qu'est-ce que ESC16 ?

ESC16 atteint le même résultat sans toucher à un modèle. Si l'OID 1.3.6.1.4.1.311.25.2, qui est l'extension de sécurité szOID_NTDS_CA_SECURITY_EXT SID, est listé dans la valeur du registre DisableExtensionList du module de politique de la CA, la CA cesse d'ajouter l'extension SID à tout ce qu'elle émet. Chaque modèle derrière cette CA se comporte désormais comme si le drapeau ESC9 était activé, y compris les modèles que personne n'a examinés depuis des années.

Un environnement peut se retrouver avec ce paramètre pour plusieurs raisons : une correction de compatibilité pour un outil tiers, une migration ou une application héritée qui ne gère pas l'extension. Il s'agit d'une seule entrée de registre facilement négligée, qui annule discrètement la protection que vous avez construite modèle par modèle.

Le paramètre n'est pas un attribut de modèle. C'est une configuration CA, et de nombreuses revues d'hygiène des certificats n'ouvrent jamais les paramètres du module de politique de la CA elle-même. Une organisation peut être propre sur chaque modèle, avoir le rapport pour le prouver, et être néanmoins exposée via la CA. Si vous avez scanné pour ESC9 il y a des années et que vous n'avez pas regardé vos CA depuis, un attaquant pourrait toujours mener la même attaque d'usurpation via ESC16.

La correspondance forte des certificats vous protège-t-elle ?

En partie. Les deux techniques dépendent de l'acceptation par le DC de mappages faibles, et les DC appliquant un lien fort de certificat les neutralisent toutes les deux. Depuis les mises à jour Windows de septembre 2025, les DC patchés appliquent la politique en totalité et le mode compatibilité n'est plus pris en charge, donc un domaine entièrement patché bloque ESC9 et ESC16 nus. Il reste cependant deux failles : tout DC n'ayant pas reçu ces mises à jour et les chaînes où l'attaquant peut fournir son propre SID dans la demande de certificat, comme ESC16 combiné avec ESC6 ou ESC15. Vérifiez l'application sur chaque DC et vérifiez également la CA.

Comment vérifiez-vous et corrigez-vous les deux ?

Vous avez besoin de deux vérifications, car ESC9 se trouve dans les modèles et ESC16 dans le CA.

Vérifier ESC9 (modèles de certificats)

1. Lancez une analyse PingCastle.
2. Ouvrez le rapport et recherchez CT_FLAG_NO_SECURITY_EXTENSION (le risque est A-CertTempNoSecurity). Recherchez le texte « Au moins un modèle de certificat a le drapeau CT_FLAG_NO_SECURITY_EXTENSION défini. »
3. Si ce texte n’est pas présent, aucun des modèles scannés ne porte le drapeau. S’il est présent, retirez le drapeau des modèles concernés.

Vérifiez ESC16 (la CA)

Sur chaque CA, exécutez :

      certutil -getreg policy\DisableExtensionList
      

Si l'OID 1.3.6.1.4.1.311.25.2 apparaît dans la sortie, cette CA supprime l'extension SID de tout ce qu'elle émet. Retirez-le de la liste sauf si vous avez une raison documentée.

Pour corriger cela, supprimez l'OID et redémarrez Certificate Services afin que la modification prenne effet :

      certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2
net stop certsvc
net start certsvc
      

Exécutez à nouveau certutil -getreg policy\DisableExtensionList pour confirmer que l'OID a disparu. Les certificats déjà émis sans l'extension restent ainsi, donc vérifiez-les si vous suspectez un abus de ce paramètre. Si une application avait besoin de ce paramètre, testez-la avant de le déployer largement.

Confirmez ensuite l'application : vérifiez que vos DC appliquent une cartographie forte des certificats, car cela atténue les deux techniques. Sur un DC avec les mises à jour actuelles, c'est la valeur par défaut. Pour le reste de l'exposition de votre CA, y compris ESC8 lors de l'inscription web, examinez les paramètres risqués de AD CS qui apparaissent souvent avec ces deux.

Comment détectez-vous le prochain changement ?

Pour ESC9 à venir : le drapeau de modèle se trouve dans Active Directory, ce qui signifie qu'une modification de celui-ci est une modification d'un objet AD. Netwrix Threat Prevention surveille les modifications AD en temps réel et peut les bloquer, donc quelqu'un qui définit CT_FLAG_NO_SECURITY_EXTENSION sur un modèle peut être arrêté avant qu'il ne prenne effet, et non détecté lors de la prochaine évaluation.

Pour ESC16 à venir : le paramètre se trouve dans le registre sur le serveur CA, pas dans AD, il nécessite donc une couverture spécifique : audit du registre sur les hôtes CA alimentant votre SIEM, ainsi que la vérification périodique ci-dessus. Netwrix corrèle également les connexions basées sur certificat avec l'émission et signale les scénarios d'extension SID manquante, de sorte que l'abus du paramètre apparaît même si la modification du registre passe inaperçue.