Attaque par ingénierie sociale via Microsoft Teams et AD CS : comment les assaillants contournent les défenses

En novembre 2026, Microsoft a dévoilé une campagne d’attaques où des cybercriminels se faisaient passer pour le service informatique des cibles sur Microsoft Teams. En moins de deux heures, ils ont obtenu des certificats de connexion pour des comptes privilégiés en exploitant des configurations non sécurisées d’Active Directory Certificate Services (AD CS). L’une des intrusions a permis l’exfiltration de données sensibles vers un serveur externe. Cette attaque par ingénierie sociale via Microsoft Teams et AD CS illustre une convergence de méthodes bien connues, mais rarement documentée ensemble. Décryptage des mécanismes, des cas réels et des mesures de protection que toute organisation française devrait adopter.

Pourquoi cette attaque est-elle particulièrement dangereuse ?

Un vecteur initial simple mais redoutable

Les assaillants n’ont exploité aucune faille logicielle. Ils ont simplement contacté des employés sur Teams en se faisant passer pour le support IT de l’entreprise. En utilisant des tenants externes dont le nom ressemblait à celui du service interne (« Service-IT », « HelpDesk-Entreprise »), ils ont gagné la confiance des victimes. À chaque fois, ils ont demandé d’ouvrir Quick Assist, un outil d’assistance à distance intégré à Windows, puis de leur communiquer le code de connexion. Ce geste anodin a offert un accès direct et complet au poste de travail.

Le simple fait de partager son écran ou de laisser un tiers prendre le contrôle est l’une des techniques d’ingénierie sociale les plus anciennes, mais elle reste redoutablement efficace. Selon le Verizon Data Breach Investigations Report 2026, près de 74 % des brèches impliquent un facteur humain. Dans ce cas précis, la vraisemblance du scénario - un appel Teams d’une personne censée résoudre un problème informatique - rend la manipulation presque invisible.

L’exploitation des certificats AD CS : le vrai danger

Une fois le poste contrôlé, les attaquants ont déposé une archive légitime (ressemblant à une mise à jour Windows) dans le dossier Téléchargements. Ils ont ensuite exécuté un script portable (Python, Bun ou Java) qui a sondé l’environnement Active Directory. L’objectif : détecter une mauvaise configuration des services de certificats AD CS pour obtenir des certificats d’authentification de comptes privilégiés.

Microsoft a décrit deux schémas distincts, correspondant à deux faiblesses connues : ESC1 et ESC8. Ces vulnérabilités de configuration ont été exposées dès 2021 par des chercheurs en sécurité, mais elles persistent dans de nombreuses infrastructures.

« Aucun correctif ne peut résoudre ces failles, car ce ne sont pas des bugs logiciels, mais des choix de paramétrage. » - Microsoft, Rapport d’investigation, novembre 2026.

Cas concrets : deux intrusions, deux issues différentes

Premier cas : ESC1 et la fuite de données

Le premier incident a débuté par une vague d’appels vers trois utilisateurs. Les assaillants ont produit des certificats pour trois comptes hautement privilégiés. Microsoft Defender a automatiquement perturbé l’attaque en révoquant les accès de deux de ces comptes. Mais un compte a été exclu de cette réponse automatique, probablement en raison d’une règle de configuration. Ce compte laissé de côté est devenu une porte ouverte.

Environ 90 minutes plus tard, une seconde vague a ciblé 16 utilisateurs et un deuxième poste, générant des certificats pour huit autres comptes privilégiés. Microsoft a bloqué plus de 1 000 tentatives ultérieures d’accès aux fichiers via SMB ou d’ouverture de session. Cependant, immédiatement après l’obtention du premier certificat, l’attaquant s’est connecté à un contrôleur de domaine et a exécuté DCSync, un outil de copie des bases de mots de passe Active Directory. Bien que la containment ait rapidement limité l’étendue, les assaillants ont réussi à exfiltrer des données via un outil de copie renommé (Rclone) vers un serveur SFTP externe. Microsoft n’a pas divulgué le volume exact de données volées.

Ce cas montre que la containment partielle des identités (révocation de certains certificats mais pas tous) peut laisser une voie privilégiée active.

Deuxième cas : ESC8 et le contrôleur de domaine devient un atout

Dans le second incident, le modèle de certificat ne présentait pas la faille ESC1. Les attaquants ont alors utilisé PetitPotam, une technique de coercition d’authentification NTLM, pour forcer le contrôleur de domaine à s’authentifier sur une machine qu’ils contrôlaient. Ce faisant, ils ont relayé l’authentification vers le portail d’enrôlement web d’AD CS (technique ESC8) et obtenu un certificat pour le contrôleur de domaine lui-même. Avec ce certificat et l’extension PKINIT de Kerberos, ils ont pu obtenir un ticket d’octroi de ticket, transformant une simple authentification relayée en un identifiant persistant.

Ici, la détection a fonctionné : Microsoft Defender a émis des alertes ESC8, le client a isolé le poste de travail, et l’attaque s’est arrêtée. La différence ? Une réponse rapide et complète, sans compte laissé de côté.

Enseignement clé : la qualité de la réponse aux incidents - qu’elle soit automatique ou manuelle - fait la différence entre une fuite de données et une alerte sans conséquence.

Analyse technique des faiblesses AD CS exploitées

ESC1 : le demandeur choisit l’identité du certificat

Dans cette configuration, un modèle de certificat permet à toute personne autorisée à faire une demande de spécifier le Subject Alternative Name du certificat. Ainsi, un utilisateur standard peut demander un certificat au nom d’un administrateur. L’attaquant, une fois sur le poste de la victime, peut donc générer un certificat valide pour un compte privilégié sans jamais connaître son mot de passe.

ESC8 : relais NTLM vers le portail d’enrôlement

Cette technique exploite l’absence de Extended Protection for Authentication (EPA) sur le point de terminaison web d’AD CS. L’attaquant relaie l’authentification NTLM (obtenue par coercion) vers ce portail, qui délivre un certificat sans nécessiter de mot de passe. Le contrôleur de domaine est alors certifié, et l’attaquant accède à ses privilèges.

Microsoft a renforcé la sécurité par défaut dans Windows Server 2025 en activant l’EPA pour AD CS. Mais les serveurs exécutant Windows Server 2022 ou 2019 restent vulnérables si l’administrateur n’a pas activé manuellement cette protection.

Cas fréquent en France : selon l’ANSSI (Guide de sécurisation d’Active Directory, 2025), de nombreuses organisations - notamment les PME et collectivités - conservent les paramètres par défaut des modèles de certificats proposés par Windows Server, sans restreindre les droits d’enrôlement. Ces configurations constituent une porte d’entrée pour ce type d’attaque.

Recommandations aux équipes sécurité et IT

1. Renforcer la vérification d’identité pour toute demande d’assistance

• Établir un canal de confirmation : toute demande inattendue de support IT doit être vérifiée via un canal interne connu (email, intranet, chat interne) avant d’exécuter la moindre action.
• Limiter les tenants externes : sur Microsoft Teams, bloquer par défaut les communications provenant de tenants externes non approuvés. N’autoriser que les outils de support à distance validés par la DSI (par exemple, TeamViewer ou une solution de prise en main avec authentification forte).
• Former les utilisateurs : organiser des simulations d’ingénierie sociale au moins deux fois par an. Expliquer que le support IT ne demande jamais de partager un code Quick Assist sans avoir ouvert un ticket officiel.

« Dans la pratique, nous avons observé que la formation seule ne suffit pas ; il faut associer des contrôles techniques bloquants. » - Extrait d’un retour d’expérience d’un grand groupe français post-incident.

2. Durcir la configuration d’Active Directory Certificate Services

• Analyser les modèles de certificats : identifier ceux qui autorisent le demandeur à spécifier le Subject Alternative Name (SAN). Désactiver les droits d’enrôlement pour les utilisateurs non autorisés. S’appuyer sur l’outil de détection de Microsoft Defender pour Identity (vérifications postures) ou sur des scripts maison.
• Activer l’HTTPS et l’EPA : pour tout point de terminaison web d’AD CS (interface d’enrôlement), exiger HTTPS et activer Extended Protection for Authentication. Suivre les instructions de Microsoft KB5005413. Sur Windows Server antérieur à 2025, l’activation manuelle est impérative, car l’option est désactivée par défaut.
• Désactiver l’authentification NTLM sur les endpoints critiques là où c’est possible, ou du moins restreindre son utilisation aux protocoles signés.

3. Mettre en place des mécanismes de détection et de réponse

• Activer l’audit des certificats : journaliser toutes les émissions de certificats. Si un certificat malveillant est identifié, le révoquer immédiatement. Attention : la révocation d’un certificat ne révoque pas les tickets Kerberos déjà délivrés ; il faut aussi forcer le renouvellement des tickets (par exemple en redémarrant le service Kerberos ou en attendant la prochaine demande).
• Surveiller les accès aux contrôleurs de domaine : les commandes DCSync ou les accès inhabituels à un contrôleur de domaine doivent déclencher une alerte prioritaire.
• Prévoir une réponse automatisée complète : l’exemple du compte exclu montre que la containment partielle est dangereuse. Revoir les règles de Defender pour qu’aucun compte privilégié ne soit exclu d’une réponse automatique sans une validation manuelle explicite. Traiter tout compte non contenu comme une décision délibérée : affecter une action manuelle immédiate.

Conclusion : vers une défense en profondeur face à l’ingénierie sociale

L’attaque par ingénierie sociale via Microsoft Teams et AD CS n’est pas une vulnérabilité technique classique, mais le fruit d’une combinaison de faiblesses humaines et de configurations. Les organisations françaises doivent intégrer ce scénario dans leur plan de réponse. Une politique de vérification d’identité stricte, un durcissement systématique des services AD CS et une surveillance continue des certificats sont les piliers d’une défense efficace.

Microsoft n’a pas attribué ces intrusions à un groupe spécifique, mais les méthodes utilisées sont à la portée de multiples acteurs malveillants. En 2026, le RGPD impose de notifier toute violation de données à la CNIL sous 72 heures. Une attaque comme celle du premier cas - avec exfiltration avérée - peut entraîner des sanctions financières et une perte de confiance.

Agissez dès maintenant : auditez vos modèles de certificats AD CS, activez l’EPA, formez vos utilisateurs à ne jamais céder à une demande d’assistance non vérifiée. Chaque organisation doit considérer ce type d’attaque non pas comme une exception, mais comme une tendance lourde de l’année 2026.

« La sécurité repose sur l’humain, la technique et les processus. Négliger l’un des trois, c’est offrir une porte d’entrée aux attaquants. » - ANSSI, Guide de sécurisation des infrastructures critiques, 2025.

Indicateurs de compromission (IoC) fournis par Microsoft :

• Scripts d’accès initial :
  • 85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17 (JavaScript)
  • f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001 (Python)
  • 06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7 (Python)

Sources : Microsoft Threat Intelligence, rapport novembre 2026 ; Verizon DBIR 2026 ; ANSSI guides.