Attaque par usurpation du support IT sur Microsoft Teams : comment les certificats AD CS sont détournés pour voler des données

En novembre 2026, Microsoft a publié un rapport détaillant deux intrusions où des attaquants se sont fait passer pour le service d’assistance technique d’une entreprise via Microsoft Teams. Ils ont convaincu les employés de leur donner le contrôle à distance de leur poste de travail, puis ont exploité des configurations vulnérables du service de certificats Active Directory (AD CS) pour obtenir des certificats d’authentification de comptes privilégiés, dont un contrôleur de domaine. Dans un cas, les données de l’entreprise ont été copiées vers un serveur externe. Cette attaque Microsoft Teams AD CS illustre la dangerosité d’une combinaison d’ingénierie sociale et de faiblesses de configuration rarement corrigées. Cet article décortique le mode opératoire, les techniques utilisées (ESC1, ESC8, PetitPotam) et vous fournit les mesures de protection concrètes à mettre en œuvre dès aujourd’hui.

Le mode opératoire : de l’appel Teams au contrôle total

L’usurpation du support IT via Microsoft Teams

Dans les deux intrusions rapportées par Microsoft, les attaquants ont contacté les employés par messagerie et appels sur Microsoft Teams en se faisant passer pour le service informatique interne. Ils utilisaient des locataires Teams externes dont le nom évoquait le support technique, rendant la sollicitation familière. Aucune faille technique de Teams n’a été exploitée : il s’agit d’une pure ingénierie sociale. Les attaquants ont convaincu chaque cible d’ouvrir l’outil Quick Assist, une fonctionnalité intégrée à Windows permettant le contrôle à distance, et de leur lire le code de connexion affiché à l’écran. En quelques secondes, l’attaquant obtenait un accès direct et interactif à la machine.

L’exploitation de Quick Assist

Une fois le contrôle établi, l’attaquant déposait une archive dans le dossier Téléchargements, la décompressait dans un dossier nommé de manière à ressembler à une mise à jour Windows, puis exécutait son contenu à l’aide d’un environement portable Python, Bun ou Java. Les noms de fichiers étaient délibérément trompeurs : une copie renomée conservait les informations de version du runtime légitime. L’objet était de déployer un script d’accès initial, capable de lancer les étapes suivantes de l’attaque sans éveiller les soupçons.

« Les attaquants n’ont exploité aucune vulnérabilité de Teams. Ils se sont appuyés sur l’ingénierie sociale et sur des services de certificats Active Directory configurés de manière non sécurisée. » - Microsoft, rapport d’intrusion 2026.

Pourquoi les certificats Active Directory (AD CS) sont une cible de choix

Le rôle d’AD CS dans l’authentification

Active Directory Certificate Services (AD CS) est le service qui délivre les certificats utilisés par les utilisateurs et les ordinateurs pour s’authentifier sur le réseau Windows. Lorsqu’un certificat est émis à partir d’un modèle mal configuré, quiconque le détient peut se connecter en tant que le compte qu’il représente. Un certificat compromis reste valable même après une réinitialisation de mot de passe ou le nettoyage de la machine initiale, ce qui rend la menace particulièrement persistante.

Les faiblesses ESC1 et ESC8

Les chercheurs en sécurité ont identifié dès 2021 plusieurs classes de vulnérabilités dans la configuration d’AD CS, appelées ESC (Escalation of privilege via Certificate Services). L’attaque Microsoft Teams AD CS a utilisé deux d’entre elles :

• ESC1 : un modèle de certificat permet au demandeur de spécifier le nom du compte pour lequel le certificat est émis. Un utilisateur non privilégié peut ainsi demander un certificat pour un compte administrateur.
• ESC8 : le point de terminaison d’inscription web d’AD CS accepte l’authentification NTLM sans protection Extended Protection for Authentication (EPA). Un attaquant peut relayer une authentification NTLM capturée (par exemple via PetitPotam) pour obtenir un certificat au nom d’un système cible, comme un contrôleur de domaine.

L’impact d’un certificat compromis

Avec un certificat pour un compte privilégié, l’attaquant peut se connecter à distance sans mot de passe, copier la base d’authentification Active Directory via des outils comme DCSync, et se déplacer latéralement dans le réseau. Une fois le ticket Kerberos obtenu, il reste utilisable même si le certificat est révoqué, ce qui complique la remédiation.

Deux cas concrets analysés par Microsoft

Cas 1 : exploitation d’ESC1 avec exfiltration de données

Dans le premier cas, l’attaquant a trouvé un modèle de certificat vulnérable à ESC1. Une première vague a ciblé trois utilisateurs et un poste de travail, produisant des certificats pour trois comptes hautement privilégiés. La fonction de perturbation automatique de Microsoft Defender a immédiatement révoqué ces certificats et clos les sessions actives, mais un des comptes privilégiés avait été omis de la réponse automatique. L’attaquant a donc continué à utiliser ce compte.

Environ 90 minutes plus tard, une seconde vague a touché 16 utilisateurs et un autre poste, générant huit certificats supplémentaires pour des comptes privilégiés. Microsoft indique que plus de 1 000 tentatives ultérieures d’accès aux fichiers via SMB ou de connexion ont été bloquées. Néanmoins, l’attaquant a utilisé le compte non coupé pour se connecter à un contrôleur de domaine, exécuter DCSync (pour copier les mots de passe Active Directory), puis accéder à un serveur de fichiers et lancer une copie renommée de l’outil Rclone afin d’exfiltrer les données d’un partage vers un serveur SFTP externe. L’ampleur des données volées n’a pas été précisée. Ce cas illustre, selon Microsoft, qu’un confinement partiel des identités peut réduire l’activité malveillante tout en laissant une voie privilégiée viable.

Cas 2 : tentative d’obtention d’un certificat pour le contrôleur de domaine (ESC8)

Dans la seconde intrusion, le modèle ESC1 n’étant pas présent, l’attaquant a utilisé la technique PetitPotam pour forcer un contrôleur de domaine à s’authentifier auprès d’une machine contrôlée, puis a relayé cette authentification NTLM vers la page d’inscription web d’AD CS (abus connu sous le nom d’ESC8) afin d’obtenir un certificat pour le contrôleur de domaine lui-même. Ce certificat, combiné à PKINIT, permet d’obtenir un ticket Kerberus de niveau contrôleur de domaine.

Heureusement, la réponse a été rapide : Defender a levé une alerte ESC8, le client a isolé le poste de travail, et Microsoft confirme qu’aucune autre activité malveillante n’a été constatée. La différence entre les deux cas tient au confinement : dans le second, l’isolement immédiat du poste a stoppé l’attaque, tandis que le premier a souffert d’une exclusion partielle de la réponse automatique.

Comment se protéger contre ce type d’attaque ?

Mesures préventives sur Teams et l’accès à distance

Aucun correctif n’existe, car il ne s’agit pas d’une faille logicielle. Les recommandations de Microsoft portent sur la configuration et la réponse :

• Formation des utilisateurs : tout employé doit confirmer toute demande de support inattendue via un canal interne connu avant d’accorder le contrôle à distance à quiconque.
• Restriction des locataires Teams : limiter les locataires externes autorisés à contacter les employés aux seuls partenaires de confiance.
• Outils de support approuvés : n’autoriser que les outils de prise en main à distance validés par la DSI, et bloquer l’exécution de Quick Assist version publique si le contexte ne le justifie pas.

Sécurisation des services de certificats AD CS

1. Analyser les modèles de certificat : identifier ceux qui permettent au demandeur de spécifier le nom du compte (ESC1) ou qui sont accessibles en inscription à un trop grand nombre d’utilisateurs. Supprimer les droits d’inscription superflus.
2. Activer HTTPS et l’Extended Protection for Authentication (EPA) sur les points de terminaison d’inscription web. La KB5005413 de Microsoft couvre cette configuration. Désactiver l’authentification NTLM sur ces points si possible.
3. Activer l’audit des certificats : journaliser toute émission de certificat. En cas de certificat malveillant, le révoquer, mais rappeler que la révocation n’annule pas les tickets Kerberos déjà émis - il faut aussi revoir les tickets actifs.
4. Posture de sécurité : les vérifications de posture de Defender for Identity signalent les modèles et points de terminaison exposés à ESC1 et ESC8.

« Si un certificat frauduleux a été émis, révoquez-le. Mais n’oubliez pas que la révocation n’annule pas les tickets Kerberos déjà délivrés ; examinez les tickets actifs séparément. » - Microsoft, guide de réponse aux incidents AD CS.

Surveillance et réaction

Microsoft a publié des alertes Defender couvrant Teams, les postes et l’identité, ainsi que quatre requêtes avancées de chasse aux menaces. Les équipes SOC doivent intégrer ces détections et envisager un confinement manuel pour tout compte exclu d’une réponse automatique, afin d’éviter les trous comme dans le cas 1.

Indicateurs de compromission et détection

Microsoft a partagé trois empreintes SHA-256 de scripts d’accès initial (JavaScript, Python) utilisés dans ces intrusions :

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

Ces éléments ne constituent pas une preuve en eux-mêmes, mais des points de départ pour une investigation. Il est conseillé de rechercher ces fichiers dans l’historique des téléchargements et d’analyser tout dossier nommé de manière suspecte, imitant des mises à jour système.

Conclusion : une vigilance renforcée sur la chaîne d’attaque

L’attaque Microsoft Teams AD CS démontre que la sécurité ne se limite pas aux correctifs. Ici, l’ingénierie sociale et une configuration AD CS laxiste ont suffi à compromettre des infrastructures entières. Les mesures de défense sont connues : formation des utilisateurs, restriction des accès Teams, durcissement des services de certificats, et surtout traitement systématique de chaque identité dans les réponses automatiques. Pour les entreprises françaises soumises au RGPD et aux recommandations de l’ANSSI, ce cas doit inciter à auditer rapidement les configurations AD CS (modèles ESC1, points d’inscription ESC8) et à mettre en place des procédures de vérification des demandes de support. N’attendez pas qu’une intrusion se produise : chaque compte non protégé est une porte ouverte vers vos données les plus sensibles.