Dans deux intrusions menées par des opérateurs humains, une session Quick Assist approuvée par un utilisateur a débouché sur des certificats d’authentification pour des comptes privilégiés. La cause n’est pas une faille Teams : ce sont des modèles de certificats trop permissifs (ESC1) et un point d’inscription web exposé au relais NTLM (ESC8). Ce guide d’audit détaille les contrôles à mener sur Active Directory Certificate Services (AD CS), la requête de détection associée et l’ordre de remédiation.
Comment une session Quick Assist devient un accès par certificat
Microsoft Threat Intelligence a analysé deux intrusions qui suivent le même scénario d’entrée. Des attaquants se font passer pour le support IT par messages et appels Microsoft Teams, puis guident l’utilisateur pour ouvrir Quick Assist et communiquer le code de connexion. L’activité n’est attribuée à aucun acteur précis.
Une fois la session ouverte, l’attaquant dépose une archive dans le dossier Téléchargements, crée un répertoire préfixé « KB » dans le profil de l’utilisateur, l’extrait et lance la charge utile avec un runtime portable Python, Bun ou Java. Le code collecte ensuite des informations sur l’hôte et le réseau, puis évalue AD CS. Les deux incidents divergent à ce stade : ESC1 dans le premier cas, ESC8 dans le second.
Un exécutable renommé n’est pas un indicateur fiable
Dans une variante JavaScript, un exécutable renommé conservait les métadonnées de version du runtime Bun. Une autre variante utilisait un runtime Java pour lancer un fichier source.
Le nom du fichier ne prouve donc rien. Le signal exploitable est un runtime portable lancé depuis un répertoire récent, inscriptible par l’utilisateur, juste après une session de support non autorisée.
Les commandes de découverte (version de Windows, configuration réseau, processus) sont banales en administration. Elles deviennent significatives lorsqu’un runtime renommé les exécute depuis un emplacement inhabituel. Le poste compromis se connectait aussi à l’infrastructure de domaine en LDAPS et SMB.
ESC1 et ESC8 : ce que votre audit doit trouver
Les deux techniques ciblent des maillons différents d’AD CS. Elles ont toutefois le même effet : un certificat d’authentification émis pour une identité privilégiée, utilisable indépendamment du mot de passe du compte initial.
| Critère | ESC1 | ESC8 |
|---|---|---|
| Nature | Abus d’un modèle de certificat mal configuré | Relais NTLM vers l’inscription web AD CS |
| Condition d’exploitation | Modèle permettant l’authentification, identité fournie par le demandeur et droits d’inscription étendus | Point d’inscription acceptant NTLM sans protection contre le relais |
| Identité obtenue | Compte privilégié choisi par l’attaquant | Compte relayé, ici le compte machine d’un contrôleur de domaine |
| Cible de l’audit | Modèles de certificats | Points de terminaison IIS (CES et Certsrv) |
| Contrôle principal | Désactiver Supply in the request, restreindre l’inscription | HTTPS et Extended Protection for Authentication (EPA) |
Le point commun est la durabilité. Réinitialiser le mot de passe ou réinstaller le premier poste ne révoque aucun certificat émis et n’invalide pas les tickets Kerberos déjà délivrés.
Auditer les modèles de certificats : exposition ESC1
Un modèle ESC1 combine trois éléments : une capacité d’authentification, une identité fournie dans la requête et des droits d’inscription larges. Un compte peu privilégié peut alors demander un certificat représentant un administrateur.
Contrôles à mener sur chaque modèle d’authentification
- L’option « Supply in the request » est-elle désactivée ?
- Le modèle porte-t-il des EKU d’authentification dont il n’a pas besoin ?
- Authenticated Users ou Everyone disposent-ils du droit d’inscription ?
- L’approbation d’un gestionnaire de certificats est-elle exigée lorsque c’est pertinent ?
- Le modèle inutilisé est-il dépublié ?
Ces mesures de remédiation sont celles que recommande Microsoft. Les évaluations de posture de Defender for Identity portant sur les modèles sont disponibles pour tous les clients disposant d’AD CS. Celles qui portent sur l’autorité de certification exigent un capteur installé sur le serveur AD CS.
L’évaluation ESC1 est toujours en préversion
La documentation Microsoft Learn marque l’évaluation de posture ESC1 comme « Preview ». Utilisez-la comme point de départ, pas comme seul contrôle, et complétez-la par une revue manuelle des droits d’inscription.
Ce que coûte un modèle ESC1 en production
Dans le premier incident, trois comptes ont été visés par une première vague Teams, avec un poste compromis. L’attaquant a obtenu des certificats pour trois comptes hautement privilégiés. Environ 90 minutes après la première session interrompue, une seconde vague a touché 16 utilisateurs et un autre poste. Huit comptes privilégiés supplémentaires ont alors reçu un certificat.
L’attack disruption de Microsoft Defender a restreint les identités concernées : connexions distantes et accès SMB limités, sessions actives déconnectées. Plus de 1 000 tentatives d’accès SMB ont été bloquées lors de la seconde vague. Quelques secondes après l’obtention d’un certificat privilégié, l’attaquant avait toutefois déjà lancé un DCSync sur un contrôleur de domaine.
Une exclusion de confinement laisse la porte ouverte
Un compte privilégié exclu de la réponse automatisée est resté utilisable. L’attaquant s’en est servi pour atteindre un serveur de fichiers et lancer une copie renommée de Rclone (SearchApp.exe) vers une destination SFTP externe, avec 20 transferts simultanés. Traitez chaque exclusion comme une décision d’incident et affectez-lui une action manuelle compensatoire, dont vous vérifiez l’exécution.
Auditer les points d’inscription : exposition ESC8
Dans le second incident, le chemin ESC1 n’était pas disponible. L’attaquant a utilisé PetitPotam, qui envoie des requêtes EFSRPC (Encrypting File System Remote Protocol) pour forcer un contrôleur de domaine à s’authentifier auprès d’un système qu’il contrôle. Il a ensuite relayé cette authentification NTLM vers l’inscription web AD CS, sans connaître le mot de passe du compte machine.
Le serveur AD CS a authentifié le compte machine du contrôleur de domaine alors que la connexion provenait d’un autre appareil. Cette incohérence entre identité et source est le meilleur pivot d’investigation. Corrélez le compte machine, l’appareil source, la requête d’inscription, l’enregistrement d’émission de l’autorité de certification et l’activité Kerberos qui suit.
L’attaquant a ensuite demandé et récupéré un certificat avec le modèle Domain Controller, via les chemins de soumission et de récupération sous /certsrv. Un accès isolé à cette URL n’est pas malveillant en soi. Seule la corrélation avec l’identité, l’appareil, le processus et la requête CA compte.
Le certificat a servi à une authentification Kerberos PKINIT qui a produit un TGT pour le contrôleur de domaine. Le succès de PKINIT est le seuil de réponse.
Contrôles à mener sur l’inscription web
- Inventoriez les points Web Enrollment et Certificate Enrollment Web Service ; supprimez ceux qui ne servent pas.
- Exigez HTTPS et activez EPA : HTTPS protège la confidentialité, EPA apporte le channel binding qui résiste au relais NTLM.
- Désactivez NTLM sur les services d’inscription quand c’est possible, après validation d’une authentification Kerberos seule.
- Pour l’interface RPC (ESC11), activez le drapeau IF_ENFORCEENCRYPTICERTREQUEST avec certutil, puis redémarrez certsvc et mettez à jour les clients concernés.
- Activez la sous-catégorie d’audit avancé Certification Services (succès et échec) et configurez le filtre d’audit de l’autorité de certification.
Le guide de référence est KB5005413 de Microsoft Support, consacré à la limitation des attaques par relais NTLM contre AD CS.
Requête de détection KQL pour ESC1, ESC8 et PKINIT
La requête suivante regroupe, dans Microsoft Defender XDR, les alertes de relais NTLM, d’abus AD CS, de PKINIT et de DCSync. Elle liste pour chaque alerte les comptes et machines impliqués.
1AlertInfo2| where Timestamp > ago(30d)3| where Title has_any ('NTLM relay', 'Certificate Services', 'PKINIT', 'Kerberos ticket request', 'DCSync')4| join kind=inner (5 AlertEvidence6 | where Timestamp > ago(30d)7 | project AlertId, AccountName, DeviceName8) on AlertId9| summarize PremiereAlerte = min(Timestamp),10 Comptes = make_set(AccountName),11 Machines = make_set(DeviceName)12 by AlertId, Title13| order by PremiereAlerte descLes noms d’alertes dépendent de la configuration et des capteurs activés. Ajustez la fenêtre de temps et les filtres, et traitez chaque résultat comme une piste à investiguer.
Pour repérer le début de la chaîne, cette seconde requête cherche Bun ou Java qui exécutent des scripts depuis un dossier préfixé « KB » du profil.
1DeviceProcessEvents2| where Timestamp > ago(7d)3| where ProcessVersionInfoOriginalFileName =~ 'bun.exe'4 or FileName in~ ('bun.exe', 'java.exe', 'javaw.exe')5| where ProcessCommandLine contains '.js'6 or ProcessCommandLine contains '.java'7| where FolderPath matches regex @'(?i)\\AppData\\Roaming\\KB[0-9]+\\'8| order by Timestamp descAlertes Defender for Identity, capteurs et réponse
Depuis octobre 2026, Defender for Identity propose des alertes AD CS dédiées au format Defender XDR : ESC1, ESC8, ESC11 et requête de certificat suspecte. S’y ajoutent l’authentification PKINIT suspecte et l’alerte « Potential Certighost (CVE-2026-54121) AD CS abuse ». La liste des alertes XDR en donne les identifiants de détecteur et les techniques MITRE.
| Étape de l’attaque | Alerte à rechercher |
|---|---|
| Découverte AD CS | Possible Active Directory Certificate Services enumeration |
| Demande de certificat | Suspicious Active Directory Certificate Services (AD CS) certificate request |
| ESC1 | Suspicious AD CS misconfigured certificate template abuse (ESC1) |
| Relais NTLM | Possible NTLM relay attack |
| ESC8 | Suspicious AD CS machine certificate issuance abuse (ESC8) |
| PKINIT | Suspicious certificate usage over Kerberos protocol (PKINIT) |
| Réplication d’annuaire | Suspected DCSync attack (replication of directory services) |
Juin 2026
Protection Teams contre l’usurpation de marque
Teams avertit pendant l’appel lorsqu’un appelant se fait passer pour une marque de confiance, comme un help desk. Les appels VoIP et PSTN suspects peuvent aussi être signalés.
Septembre 2026
Capteur v3.x en préversion
Le capteur Defender for Identity v3.x prend en charge les serveurs AD CS, AD FS et Entra Connect qui ne sont pas des contrôleurs de domaine.
Octobre 2026
Disponibilité générale sans Defender for Endpoint
L’activation sans Defender for Endpoint est disponible sur Windows Server 2019 ou ultérieur, pour les nouveaux déploiements v3.x uniquement.
Révoquer le certificat, pas seulement le mot de passe
Un certificat ESC8 émis reste valable environ un an et permet l’authentification PKINIT. En cas d’émission non autorisée, relevez le numéro de série et l’empreinte, révoquez le certificat, publiez la révocation et vérifiez que les systèmes dépendants la récupèrent. La révocation n’invalide pas les TGT et tickets de service déjà émis : examinez-les séparément, comme dans notre analyse du token replay et du session hijacking.
Réduire la porte d’entrée Quick Assist
Pour une organisation dans un seul tenant Microsoft Entra, la documentation Windows recommande de passer à Intune Remote Help. Il apporte accès conditionnel, RBAC, journalisation des sessions et isolation du tenant. Bloquer le point de terminaison remoteassistance.support.services.microsoft.com désactive Quick Assist, mais perturbe aussi Remote Help. Pour limiter les runtimes non approuvés, consultez notre guide sur le blocage des installations logicielles non autorisées avec Intune.
Questions fréquentes
Faut-il un capteur sur le serveur AD CS pour auditer ESC1 et ESC8 ?
Pas pour les évaluations de posture portant sur les modèles de certificats, disponibles pour tous les clients ayant AD CS. Les évaluations portant sur l’autorité de certification exigent un capteur sur le serveur AD CS. Le capteur v3.x sans Defender for Endpoint est disponible sur Windows Server 2019 ou ultérieur, pour les nouveaux déploiements v3.x.
Réinitialiser le mot de passe du compte compromis suffit-il ?
Non. Un certificat émis reste valide indépendamment du mot de passe, et un certificat ESC8 dure environ un an. Il faut révoquer le certificat, publier la révocation et examiner séparément les tickets Kerberos déjà émis.
Les alertes Defender ont-elles suffi à stopper les attaquants ?
Cela dépend de la réponse. Dans le cas ESC8, l’isolation du poste par le client après les alertes a arrêté la progression. Dans le cas ESC1, un compte privilégié exclu du confinement automatique est resté exploitable et a servi à l’exfiltration.
Par où commencer : trois contrôles dans l’ordre
Commencez par ce qui ferme le plus de portes le plus vite, puis passez à la détection continue.
Plan d’audit AD CS
- Exécutez la requête KQL sur 30 jours et traitez chaque alerte ESC1, ESC8 ou PKINIT comme un incident potentiel.
- Listez les modèles d’authentification et corrigez ceux qui acceptent Supply in the request ou une inscription large.
- Inventoriez les points CES et Certsrv, puis imposez HTTPS et EPA.
- Activez l’audit Certification Services et le filtre d’audit de la CA.
- Passez en revue toutes les exclusions de confinement automatique.
Si vos serveurs AD CS ne sont pas couverts par un capteur, déployez d’abord le capteur v3.x sur Windows Server 2019 ou ultérieur. Sinon, vous n’aurez ni les évaluations liées à la CA ni les alertes d’émission côté serveur.
Pour aller plus loin
- Évaluation de posture des certificats dans Defender for Identity : détection et correction des expositions ESC1, ESC8 et ESC11.
- Alertes de sécurité XDR de Defender for Identity : les alertes AD CS actuelles avec leurs techniques MITRE.
- Securing AD CS : le capteur Defender for Identity : chaque abus AD CS et les étapes de remédiation.
- Utiliser Quick Assist pour aider les utilisateurs : désactivation de Quick Assist et migration vers Intune Remote Help.
- KB5005413 : limiter le relais NTLM contre AD CS : configuration sécurisée des points d’inscription.
