Usurpation du support IT sur Microsoft Teams : une campagne exploitant AD CS pour voler des données

En novembre 2026, Microsoft a levé le voile sur une campagne d’attaques ciblées où des assaillants, se faisant passer pour le service informatique interne via Microsoft Teams, ont réussi à dérober des certificats d’authentification en exploitant des configurations vulnérables d’Active Directory Certificate Services (AD CS). Sur deux intrusions documentées, l’une a abouti à la copie de données d’entreprise vers un serveur externe. Cet incident illustre une convergence redoutable entre ingénierie sociale et faiblesses techniques de l’infrastructure de gestion des identités.

Dans cet article, nous détaillons le mode opératoire, les vulnérabilités exploitées (ESC1 et ESC8), les leçons tirées des deux cas, et les mesures concrètes que toute organisation peut déployer pour se protéger contre ce type d’attaque.

Comment l’attaque commence : l’usurpation sur Microsoft Teams

Les deux intrusions partagent un même point d’entrée : l’usurpation du support IT par messagerie et appels vocaux sur Microsoft Teams. Les attaquants, opérant depuis des locataires Teams externes avec des noms à consonance support (ex. « Aide informatique », « HelpDesk Pro »), contactent des employés et se font passer pour le véritable service d’assistance.

« Bonjour, nous avons détecté un problème sur votre poste. Pour le résoudre, nous avons besoin que vous lanciez l’outil Quick Assist et nous donniez le code de connexion. »

L’outil Quick Assist comme porte dérobée

Quick Assist est un outil de contrôle à distance intégré à Windows, légitime et souvent utilisé par les équipes IT. Les attaquants exploitent cette légitimité. L’utilisateur, croyant parler au service IT, ouvre l’outil et lit le code à six chiffres qui permet la connexion. En quelques secondes, l’assaillant prend le contrôle total du poste de travail.

Une fois ce contrôle acquis, une archive est déposée dans le dossier Téléchargements. Extraite dans un dossier nommé pour ressembler à une mise à jour Windows (« Update_Win_2026 »), elle contient des scripts exécutés via Python, Bun ou Java portables. Les noms de fichiers, bien que parfois modifiés, conservent les versions des runtimes, offrant un faible signal mais pas assez pour déclencher une alerte.

Pourquoi Teams est un vecteur idéal

Microsoft Teams autorise par défaut les communications provenant de locataires externes. Les assaillants ont créé des locataires avec des noms support, rendant l’appel familier. Aucune faille dans Teams elle-même n’est exploitée : c’est la confiance humaine qui est ciblée. Selon le rapport de Microsoft, les attaquants ont contacté et appelé les victimes, parfois à plusieurs reprises, pour gagner leur confiance avant de demander l’accès à Quick Assist.

L’exploitation des faiblesses d’AD CS : ESC1 et ESC8

Après avoir pris le contrôle du poste, les attaquants ont utilisé des techniques connues depuis 2021 pour abuser des services de certificats Active Directory. AD CS délivre les certificats que les utilisateurs et machines présentent lors des authentifications. Deux vulnérabilités de configuration, référencées ESC1 et ESC8, ont été exploitées.

ESC1 : Le demandeur choisit l’identité

Un modèle de certificat mal configuré peut permettre au demandeur de spécifier le nom du compte pour lequel le certificat est émis. C’est l’ESC1. Un attaquant disposant d’un accès peu privilégié peut ainsi demander un certificat pour un compte administrateur. Microsoft a constaté que, dans la première intrusion, le modèle présentait exactement cette faiblesse. Les certificats ainsi obtenus continuent de fonctionner même après la réinitialisation du mot de passe ou la suppression du poste initial : l’accès persiste.

ESC8 : Relais d’authentification NTLM vers AD CS

Dans la deuxième intrusion, le modèle de certificat n’était pas vulnérable à ESC1. Les attaquants ont alors utilisé PetitPotam, une technique de coercion qui force un contrôleur de domaine à s’authentifier (NTLM) sur une machine contrôlée par l’attaquant. Cette authentification est relayée vers la page d’inscription web d’AD CS, sans mot de passe nécessaire : c’est l’ESC8. L’attaquant obtient ainsi un certificat pour le contrôleur de domaine lui-même, puis via Kerberos (PKINIT), un ticket granting ticket valide. Une seule authentification relayée se transforme en accès permanent au domaine.

Étude de cas : deux intrusions, deux issues

Le rapport de Microsoft détaille deux scénarios qui se différencient par la réaction des défenses.

Cas n°1 : Containment partiel et fuite de données

Dans la première intrusion, les attaquants ont ciblé d’abord trois utilisateurs et un poste, obtenant des certificats pour trois comptes très privilégiés. Microsoft Defender a automatiquement disrupté ces identités en coupant leurs sessions actives. Cependant, un compte privilégié avait été exclu de la réponse automatisée. Il est resté actif.

Environ 90 minutes plus tard, une seconde vague a touché 16 utilisateurs et un deuxième poste, produisant des certificats pour huit comptes supplémentaires. Plus de 1 000 tentatives ultérieures d’accès via SMB ou de connexion ont été bloquées. Mais l’attaquant, utilisant le compte exclu, a réussi à atteindre un serveur de fichiers et à exécuter une copie renommée de Rclone, exfiltrant des données vers un serveur SFTP externe. Microsoft n’a pas communiqué le volume de données dérobées.

« La containment partielle peut réduire l’activité malveillante tout en laissant une voie privilégiée viable » - Microsoft.

Cas n°2 : ESC8 stoppée par l’isolation du poste

Dans la seconde intrusion, l’attaque a commencé de la même manière mais, face à l’ESC8, les alertes Defender ont immédiatement signalé le relais. Le client a isolé le poste de travail concerné. Aucune activité ultérieure n’a été constatée. L’isolation précoce a empêché toute exfiltration.

Tableau comparatif des deux intrusions

Leçons pour les défenseurs : configuration et réponse

Microsoft précise qu’il n’y a pas de correctif, car il ne s’agit pas d’une faille logicielle mais de mauvaises configurations et d’erreurs humaines. Les recommandations s’articulent autour de quatre axes.

1. Réduire la surface d’attaque humaine

• Former les employés à ne jamais donner le contrôle de leur poste sans avoir vérifié la demande via un canal interne (téléphone, chat validé).
• Limiter les locataires Teams externes autorisés à contacter les utilisateurs.
• N’autoriser que les outils de support à distance approuvés par l’entreprise.

2. Renforcer la configuration d’AD CS

• Réviser les modèles de certificats : vérifier qu’aucun modèle ne permet au demandeur de spécifier le nom du compte (ESC1). Supprimer les droits d’inscription superflus.
• Activer HTTPS et Extended Protection for Authentication (EPA) sur les points de terminaison d’inscription web. EPA est activé par défaut sur Windows Server 2025, mais doit être configuré manuellement sur Server 2022 et 2019.
• Désactiver l’authentification NTLM sur les points d’inscription AD CS, ou à défaut, la restreindre.

3. Mettre en place une surveillance et des alertes

• Activer l’audit des certificats : tout certificat suspect doit être révoqué immédiatement. Attention, la révocation n’invalide pas les tickets Kerberos déjà émis : il faut aussi vérifier les tickets actifs.
• Configurer Microsoft Defender for Identity pour détecter les modèles exposés à ESC1 et ESC8, et les points d’inscription non sécurisés.
• Utiliser les requêtes de chasse avancées (advanced hunting queries) publiées par Microsoft pour rechercher des indicateurs d’intrusion.

4. Améliorer la réponse aux incidents

• Ne pas exclure de comptes de la réponse automatisée sans une raison impérieuse et un remplacement manuel. Tout compte exclu devient une cible prioritaire.
• En cas de détection d’un relais ESC8, isoler immédiatement le poste concerné.
• Vérifier que les tickets Kerberos délivrés après une attaque sont révoqués.

Indicateurs de compromission (IoCs) partagés par Microsoft

Microsoft a publié trois empreintes SHA-256 de scripts utilisés lors de la phase d’accès initial :

85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17 (JavaScript)
f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001 (Python)
06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7 (Python)

Ces scripts sont des « points de départ pour l’investigation » selon Microsoft. Leur présence dans les journaux ou les dossiers Téléchargements doit déclencher une analyse approfondie.

Ce que cette campagne nous apprend sur la persistance

Un point crucial souligné par ce rapport est la persistance offerte par les certificats AD CS. Contrairement à un mot de passe qui peut être changé, ou un poste qui peut être réinstallé, un certificat valide continue de fonctionner. Les attaquants l’ont exploité pour conserver un accès même après la suppression des sessions initiales.

Selon une étude de l’ANSSI sur les attaques contre l’authentification Active Directory (2025), la gestion des certificats reste un angle mort dans de nombreuses organisations. Les recommandations françaises (guide RGS, mesures de sécurité pour l’administration) insistent sur l’importance de la validation des modèles de certificats et de l’activation de l’EPA.

Conclusion : une vigilance renforcée sur les certificats et l’ingénierie sociale

Cette campagne d’usurpation du support IT sur Microsoft Teams exploitant AD CS démontre que les attaquants combinent avec succès l’ingénierie sociale et des faiblesses de configuration connues. Les organisations doivent adopter une approche en profondeur :

1. Sensibiliser les utilisateurs à ne jamais accorder d’accès à distance sans vérification indépendante.
2. Durcir la configuration d’AD CS : modèles de certificats, activation de l’EPA, désactivation de NTLM.
3. Mettre en place une détection et une réponse automatisées mais en veillant à ne pas laisser de comptes non couverts.
4. Auditer régulièrement les certificats émis et les tickets Kerberos.

Microsoft n’a pas attribué ces intrusions à un groupe connu, mais les techniques employées (ESC1, ESC8, PetitPotam) sont bien documentées depuis 2021. Ce qui est nouveau, c’est leur convergence dans des attaques réelles, avec un succès partiel lié à un défaut de containment. La leçon est claire : la sécurité ne peut reposer uniquement sur l’automatisation ; une supervision humaine, des configurations rigoureuses et une formation continue restent indispensables.

Pour aller plus loin : consultez le guide de l’ANSSI sur la sécurisation des Active Directory et les bulletins de Microsoft sur la configuration d’AD CS (KB5005413). Mettez à jour vos procédures de réponse aux incidents pour inclure la révocation des certificats et la vérification des tickets Kerberos.

Cet article a été rédigé sur la base du rapport de Microsoft publié en novembre 2026 et des recommandations de l’ANSSI.