ESC8 reste la découverte AD CS la plus courante que nous voyons

Dans les rapports soumis au site public de statistiques de Netwrix PingCastle via le bouton « comparer avec les statistiques », A-CertEnrollHttp a été signalé 6 487 fois en novembre 2026. C’est plus que tout autre chemin d’escalade de Active Directory Certificate Services (AD CS) que nous suivons.

Avec A-CertEnrollChannelBinding, il couvre ESC8. ESC8 est bien documenté et reste aussi courant car il commence par une configuration par défaut non sécurisée.

Qu'est-ce que ESC8 ?

ESC8 est une attaque de relais NTLM contre l'interface d'inscription web AD CS. Lorsque le rôle Certification Authority Web Enrollment est installé et que son point de terminaison HTTP (certsrv) accepte l'authentification NTLM sans protections telles que Extended Protection for Authentication (EPA) ou le channel binding, un attaquant peut relayer une tentative d'authentification NTLM capturée vers ce point de terminaison et demander un certificat au nom de quelqu'un d'autre.

Si un attaquant contraint un contrôleur de domaine à s’authentifier auprès de lui, en utilisant une technique comme PetitPotam, il peut relayer cette authentification vers le point d’inscription web et recevoir un certificat qui s’authentifie en tant que ce contrôleur de domaine. De là, il n’y a qu’un pas vers DCSync et la compromission complète du domaine.

MITRE suit cela sous T1557 (Adversary-in-the-Middle) pour le mécanisme de coercition et de relais, et T1649 (Steal or Forge Authentication Certificates) pour ce qui se passe une fois que l'attaquant a ce certificat en main.

Pourquoi ESC8 est-il si courant ?

L’installation du rôle Web Enrollment active l’authentification HTTP et NTLM par défaut, tandis que HTTPS avec EPA nécessite une configuration supplémentaire. Les équipes qui ignorent cette nécessité restent exposées par défaut.

Personne ne décide de laisser l'inscription des certificats ouverte au relais NTLM. Quelqu'un installe une CA et active Web Enrollment, et six mois plus tard, personne ne se souvient que le rôle est actif, encore moins qu'il nécessite l'activation de l'EPA.

Cette découverte apparaît même dans des environnements renforcés, bien moins souvent maintenant que la sensibilisation à ESC8 s’est répandue.

Que peut faire un attaquant avec un certificat ESC8 ?

ESC8 est de haute gravité en raison de ce que l’attaquant détient une fois que la relaye réussit. Une session NTLM se termine rapidement, mais le certificat délivré reste valide jusqu’à son expiration ou sa révocation, ce qui est souvent d’un an ou plus.

Le certificat fonctionne également à travers les protocoles. L’attaquant peut s’authentifier avec Kerberos ou Schannel (connexion TLS basée sur certificat), ce qui contourne toutes les restrictions NTLM dans l’environnement.

Combinée à une technique de coercition, la chaîne nécessite uniquement un accès réseau à un point d'inscription web vulnérable et une machine que l'attaquant peut forcer à s'authentifier. C'est une barrière basse pour un chemin qui se termine par un accès équivalent à Domain Admin.

Comment PingCastle détecte-t-il ESC8 ?

PingCastle analyse chaque autorité de certification et serveur d’enregistrement qu’il trouve sur le réseau. Pour chacun, il envoie une requête à deux points de terminaison : la page web d’enregistrement (certsrv/certrqxt.asp) et le point de terminaison du Certificate Enrollment Service (CES). Si l’un des deux répond avec succès en HTTP non sécurisé, PingCastle signale le domaine, car un attaquant sur le réseau peut relayer l’authentification NTLM vers un point d’enregistrement non chiffré.

A-CertEnrollChannelBinding couvre le côté HTTPS. Il signale les points d'inscription qui acceptent HTTPS mais n'appliquent pas le channel binding, car une session NTLM relayée peut toujours passer via HTTPS.

Comment réparer ESC8 sans interrompre l'inscription ?

Avez-vous vraiment besoin de Web Enrollment ? Si personne dans votre environnement ne dépend de l'interface certsrv pour les demandes de certificats, supprimez le rôle. C'est la solution la plus simple et celle à vérifier en premier.

Si vous en avez besoin, HTTPS seul ne ferme pas ESC8. Le point d'inscription doit également appliquer EPA ou le binding de canal, car une session NTLM relayée peut toujours être transmise via une connexion HTTPS.Les recommandations de Microsoft pour atténuer les attaques par relais NTLM contre AD CS (KB5005413) expliquent la configuration.

Autres mesures : restreindre l'accès réseau à l'interface web du CA, désactiver NTLM lorsque Kerberos est suffisant, et appliquer des correctifs contre les techniques de coercition connues. Pour le reste de l'exposition de votre CA, examinez les paramètres AD CS risqués qui apparaissent avec ESC8.

Ma recommandation

Je recommande de vérifier si vous avez besoin de Web Enrollment avant de le sécuriser. Si c’est le cas, exigez HTTPS et EPA, et suivez KB5005413.

Pour vérifier si vous êtes exposé, effectuez une analyse gratuite avec PingCastle. Cela signale directement ESC8, ainsi que le reste de la surface de risque AD CS. Recherchez dans le rapport "The certificate enrollment interface is accessible by unencrypted HTTP" et "Channel Binding is not enforced for the HTTPS Certificate Enrollment Interface", les deux constats indiquant un risque ESC8.