ESC17 - Au-delà de WSUS : introduction et modèle de menace

Une série de recherche par Alexis MARTIN (qu35t) et Alexis PARET (nnino). Chaque technique présentée dans cette série a été reproduite de bout en bout dans un environnement de laboratoire entièrement à jour.

Pourquoi cette série

En janvier 2026, DigiTrace a formalisé une mauvaise configuration de modèle de certificat sous le numéro d’escalade ESC17, en s’appuyant sur les travaux antérieurs d’Austin Coontz (TrustedSec) concernant l’attaque de WSUS en HTTPS. À ce jour, la technique ne dispose que d’un seul chemin d’exploitation public documenté de bout en bout : WSUS.

Le problème, pourtant, n’est pas WSUS. WSUS n’est que le premier service à avoir été décortiqué en public. La cause racine se situe une couche plus bas, dans Active Directory Certificate Services (ADCS) et, plus précisément, dans la confiance implicite que chaque machine jointe au domaine accorde aux certificats émis par l’autorité de certification d’entreprise.

Récemment, nous avons repris ESC17 depuis ses fondements et posé une question simple : si la primitive est une identité TLS malveillante mais pleinement approuvée pour un nom d’hôte arbitraire, quels autres protocoles héritent de la même faiblesse ? La réponse est « beaucoup ». Les prochains volets de cette série documentent, protocole par protocole, comment ESC17 peut être instrumentalisé contre :

• HTTPS (applications web internes, intranets, interfaces d’administration)
• LDAP / LDAPS
• RDP

Cette liste n’est pas figée : d’autres protocoles viendront s’ajouter à la recherche et à l’outil au fil du temps, à mesure que nous étendons la couverture d’ESC17.

Pour chaque protocole, nous détaillons l’attaque concrète, les limitations imposées par Windows qui façonnent (et parfois brisent) l’exploitation, et la manière dont adecrypt, l’outil que nous avons développé pour automatiser ESC17 protocole par protocole, met cette attaque en œuvre.

Ce premier article pose les fondations : ce qu’est ESC17, pourquoi il existe, et pourquoi il s’agit d’un problème de confiance PKI plutôt que d’un problème WSUS.

Rappel sur ADCS et le modèle de confiance PKI du domaine

ADCS est l’infrastructure à clés publiques (PKI) de Microsoft. Dans la plupart des entreprises, elle fonctionne en CA d’entreprise : une autorité de certification en ligne, intégrée à Active Directory, qui émet des certificats pour l’authentification des utilisateurs, l’authentification des machines, les services TLS, la signature de code, et plus encore. Ce que la CA est autorisée à émettre, et à qui, est régi par les modèles de certificat.

La propriété la plus importante pour cette série est la suivante : les machines Windows jointes au domaine font automatiquement confiance à la CA d’entreprise interne. Lorsque ADCS est déployé, le certificat racine de la CA est publié dans Active Directory et propagé au magasin Autorités de certification racines de confiance de chaque membre du domaine via une stratégie de groupe (GPO). La conséquence pratique est que tout certificat émis par cette CA est approuvé, par défaut, par chaque machine du domaine, sans invite supplémentaire, avertissement, ni interaction de l’utilisateur.

Cette confiance est exactement ce qui fait d’ADCS une surface d’attaque aussi riche. Si un attaquant parvient à convaincre la CA d’émettre un certificat pour une identité qu’il ne possède pas légitimement, ce certificat est instantanément approuvé à l’échelle du domaine.

Les mauvaises configurations d’ADCS sont recensées sous une nomenclature « ESC » (pour Escalation), numérotée depuis ESC1, chaque numéro désignant un scénario d’abus distinct. C’est cette taxonomie que suit ESC17, et pour la comprendre il faut d’abord revenir sur son point de départ : ESC1.

Rappel : le modèle ESC1

L’attaque classique ESC1, introduite par SpecterOps dans Certified Pre-Owned (2021), abuse d’un modèle qui combine :

1. Enrollee Supplies Subject : le flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT (affiché comme « Supply in the request » dans l’interface), qui permet au demandeur de spécifier lui-même le sujet / SAN.
2. un Extended Key Usage (EKU) qui autorise l’authentification au domaine : typiquement Client Authentication (1.3.6.1.5.5.7.3.2), Smart Card Logon, PKINIT Client Authentication, ou le fourre-tout Any Purpose.
3. des droits d’enrôlement permissifs (par exemple les utilisateurs du domaine peuvent s’enrôler).
4. aucun garde-fou tel que l’approbation d’un gestionnaire.

Avec ces quatre ingrédients, un utilisateur à faibles privilèges demande un certificat en fournissant un UPN qu’il ne possède pas, par exemple administrator@corp.local, et s’authentifie en tant que cet utilisateur. Compromission complète du domaine, chaîne courte, impact dévastateur.

ESC1 est aujourd’hui largement connu et corrigé dans la plupart des environnements. C’est justement de cette correction que naît ESC17.

La mauvaise configuration ESC17 : un ESC1 incomplètement corrigé

Lorsque les équipes remédient à ESC1, elles disposent de plusieurs options : désactiver les sujets fournis par l’enrôlé, restreindre l’enrôlement, exiger l’approbation d’un gestionnaire, ou changer l’EKU. Cette dernière est tentante car elle a généralement le plus faible impact métier. Ces modèles vulnérables sont fréquemment utilisés pour émettre des certificats de serveur web, ce qui est précisément pourquoi le flag « supply in the request » avait été activé en premier lieu (un administrateur doit demander un certificat pour webserver.corp.local, pas pour lui-même).

Le correctif « évident » consiste donc à retirer l’EKU d’authentification et à ne laisser que celui dont un serveur web a réellement besoin : Server Authentication (1.3.6.1.5.5.7.3.1). Le modèle ne peut plus être utilisé pour s’authentifier en tant qu’utilisateur, l’outillage ESC1 cesse de le signaler, et tout le monde passe à autre chose.

C’est le piège. Un modèle qui autorise toujours un enrôlé à fournir le sujet/SAN, accorde toujours un enrôlement permissif, et porte un EKU Server Authentication n’est pas sûr. Il a simplement troqué la capacité d’usurper un utilisateur contre celle d’usurper un serveur, et dans un domaine où chaque machine fait confiance à la CA, usurper un serveur est en soi une primitive d’escalade.

Cette configuration, à savoir SAN fourni par l’enrôlé + EKU Server Authentication + enrôlement permissif (sans garde-fou effectif), c’est ESC17.

La distinction avec ESC1 est subtile mais décisive :

	ESC1	ESC17
Identité fournie	UPN (un utilisateur)	Nom DNS (un serveur)
EKU	Client Auth, Any Purpose, Smart Card Logon	Server Authentication
Effet direct	S’authentifier comme un utilisateur arbitraire	Présenter une identité TLS approuvée pour un hôte arbitraire
Type d’escalade	Direct (souvent DA immédiat)	Indirect (via interception / manipulation d’un canal de confiance)

Dans certipy, un certificat exploitable pour ESC17 est demandé non pas avec un -upn forgé, mais avec une valeur -dns forgée pointant vers le FQDN du service cible. La CA le signe volontiers, et le certificat résultant est approuvé par chaque client joint au domaine pour ce nom d’hôte.

La mécanique de l’attaque

ESC17 ne forge pas, à lui seul, une authentification. Il forge une identité de serveur approuvée, que l’attaquant exploite ensuite depuis une position d’homme du milieu (MitM). La chaîne d’attaque générique ressemble à ceci :

1. Énumérer les modèles et identifier celui qui est exploitable pour ESC17 (fournit le sujet + EKU Server Authentication + vous pouvez vous enrôler).
2. Demander un certificat pour le nom DNS du service cible (-dns target.corp.local). Comme la CA est approuvée à l’échelle du domaine, ce certificat l’est aussi.
3. Se positionner sur le chemin entre le client victime et le serveur légitime. Les techniques courantes incluent l’ARP spoofing, l’abus des annonces de routeur IPv6 (mitm6), l’empoisonnement DNS, ou tout contrôle de l’infrastructure réseau.
4. Usurper le serveur légitime, en terminant la session TLS de la victime avec votre certificat émis par ADCS. Aucun avertissement de certificat n’est levé, car le certificat est réellement valide et réellement approuvé.

Depuis cette position, trois classes de capacités s’ouvrent :

• Interception passive : lire des données que la victime croyait protégées par TLS. Pensez aux jetons de session, aux données d’API internes, aux identifiants.
• Manipulation active : altérer le trafic à la volée. Dans le cas de WSUS, cela signifie injecter une mise à jour « signée » malveillante qui s’exécute avec les privilèges SYSTEM, transformant l’interception en exécution de code directe.
• Relais : transférer une authentification coercée (p. ex. NTLM) de la victime vers une cible choisie par l’attaquant.

Que le résultat final soit un déplacement latéral ou une véritable escalade de domaine dépend des privilèges du service usurpé et de l’identité des victimes prises dans l’interception, un peu comme ESC8 (relais HTTP) et ESC11 (relais RPC), où l’impact est fonction de quelle authentification vous pouvez coercer et où vous pouvez l’envoyer. C’est précisément pourquoi les auteurs de DigiTrace ont argué qu’ESC17 méritait son propre numéro : l’escalade est réelle, mais elle est indirecte, s’appuyant sur une mauvaise configuration de modèle ADCS.

Pourquoi c’est un problème de PKI, pas un problème de WSUS

La généralisation critique est la suivante : tout protocole qui s’appuie sur le magasin de certificats système de la machine pour établir la confiance, et n’impose pas de vérification plus stricte comme l’épinglage de certificat, est candidat à l’abus ESC17.

WSUS n’était que la première démonstration, et la plus spectaculaire, parce que WSUS ne dispose d’aucune protection de type HSTS ou trust-on-first-use et parce qu’une mise à jour manipulée aboutit à une exécution de code immédiate au niveau SYSTEM. Mais l’hypothèse sous-jacente de WSUS, « si le certificat TLS est émis par notre CA interne de confiance, alors le point d’accès est authentique », est partagée par un grand nombre de services du domaine.

Les prochains volets s’attaquent à trois d’entre eux, chacun avec ses propres subtilités : les applications HTTPS internes, LDAPS et RDP. Ce n’est qu’un point de départ : beaucoup d’autres protocoles reposent sur la même hypothèse de confiance et rejoindront la série au fil du temps. Chacun se comporte différemment sous attaque, et cette différence est largement dictée par les limitations imposées par Windows.

Les limitations qui comptent vraiment

ESC17 n’est pas une baguette magique, et une grande partie de cette série porte sur les contraintes qui séparent « théoriquement vulnérable » de « exploitable de manière fiable ». Les thèmes récurrents que nous examinerons par protocole incluent :

• Épinglage de certificat (pinning) : lorsqu’un client valide un certificat ou une clé spécifique plutôt que « tout ce que la CA de confiance a signé », ESC17 est neutralisé indépendamment de l’hygiène du modèle. Les paires client/serveur gérées centralement sont l’endroit naturel où s’attendre à cela.
• Extended Protection for Authentication / channel binding : qui peut déjouer un relais naïf d’authentification sur TLS.
• Particularités de Schannel et de l’application des EKU : la rigueur avec laquelle un client Windows donné vérifie l’EKU Server Authentication, la correspondance du SAN, et les contraintes de nom.
• Exigences de coercition et de sondage (polling) : certains protocoles n’initient pas de connexion à la demande (le polling WSUS peut prendre jusqu’à une journée), de sorte que le timing et la coercition font partie de l’attaque.
• Le prérequis MitM lui-même : chaque variante d’ESC17 suppose une position d’interception viable, ce qui est une contrainte opérationnelle à part entière.

Tout ce que nous présentons a été validé sur un laboratoire entièrement à jour au 25 juillet 2026, précisément pour que ces limitations soient reflétées avec exactitude plutôt qu’évacuées par hypothèse.

Présentation d’adecrypt

Demander le certificat est la partie facile. Le transformer en attaque fonctionnelle diffère substantiellement d’un protocole à l’autre : l’encapsulation TLS, la coercition, la charge utile, la logique de manipulation et le nettoyage sont tous spécifiques au protocole.

adecrypt est l’outil que nous avons construit pour automatiser cette exploitation. Plutôt que de réassembler à la main, pour chaque service, le même montage d’interception et d’usurpation, adecrypt prend un certificat éligible ESC17 et pilote l’attaque de bout en bout : il gère l’interception et la manipulation propres au protocole visé, et laisse l’opérateur se concentrer sur l’objectif. Chaque article suivant associe la théorie au workflow adecrypt exact utilisé pour reproduire le résultat en laboratoire.

La suite de la série

Partie	Sujet
1	Introduction & modèle de menace (cet article)
2	Applications HTTPS internes : interception, capture d’identifiants et relais NTLM
3	LDAP / LDAPS : capture d’identifiants et détournement de session
4	RDP
…	D’autres protocoles s’ajouteront au fil du temps

Chaque entrée suit la même structure : l’attaque, les limitations de Windows, et l’automatisation via adecrypt.

Crédits & travaux antérieurs

ESC17 s’appuie sur une grande quantité de recherche publique, et nous tenons à la nommer clairement :

• SpecterOps : Certified Pre-Owned (2021), qui a introduit la taxonomie ESC et ESC1.
• Austin Coontz (TrustedSec) : l’intuition originale qu’un certificat ADCS pouvait servir à attaquer WSUS en HTTPS, et la recherche sur le relais NTLM WSUS sur laquelle elle s’est construite.
• Alexander Neff & Phil Knüfer (DigiTrace) : qui ont généralisé l’idée, proposé la désignation ESC17, et contribué la logique de détection à certipy.

L’enseignement à retenir pour la suite de la série est simple, et c’est le même avertissement sur lequel DigiTrace a conclu : cessez de vous fier à une valeur d’EKU pour juger qu’un modèle est sûr. Tout modèle qui permet à une partie non approuvée de fournir le sujet et d’obtenir un certificat approuvé par le domaine mérite un examen, Server Authentication très largement inclus.

Gardez l’œil sur ESC17.