Attaque par usurpation du support IT sur Microsoft Teams : comment l'abus d'AD CS permet le vol de données sensibles en 2026

En 2026, selon une enquête de Microsoft, deux intrusions ont exploité une combinaison redoutable d’ingénierie sociale et de faiblesses dans les services de certificats Active Directory (AD CS). Les assaillants se sont fait passer pour le support IT sur Microsoft Teams, ont obtenu le contrôle à distance des postes des victimes via Quick Assist, puis ont dérobé des certificats pour des comptes privilégiés, y compris pour un contrôleur de domaine. Cet article décrypte les mécanismes de cette attaque par usurpation du support IT sur Microsoft Teams, expose les vulnérabilités AD CS exploitées et détaille les mesures de protection essentielles pour les organisations françaises. L’objectif est de vous fournir une compréhension exhaustive du risque et des actions concrètes à mettre en œuvre.

Pourquoi l’usurpation du support IT sur Microsoft Teams est une menace croissante

L’ingénierie sociale reste le vecteur d’attaque le plus efficace car elle cible le maillon humain, souvent le moins protégé. En 2026, Microsoft a rapporté deux incidents où des assaillants ont contacté des employés via Microsoft Teams en se faisant passer pour le service IT interne. Ils utilisaient des locataires (tenants) externes avec des noms évocateurs (“Support IT”, “Help Desk”) pour paraître légitimes. La conversation se déroulait dans l’interface familière de Teams, ce qui abaissait la méfiance et augmentait les chances de succès.

La séquence d’attaque typique

Voici les étapes observées lors de ces intrusions :

1. Premier contact : l’assaillant envoie un message instantané et passe un appel vocal via Teams en se présentant comme un technicien du service IT.
2. Mise en confiance : il explique qu’il doit résoudre un problème urgent (mise à jour, panne de réseau) et demande à l’utilisateur d’ouvrir Quick Assist, l’outil d’assistance à distance intégré à Windows.
3. Prise de contrôle : la victime lit le code de connexion à six chiffres, ce qui donne à l’attaquant un contrôle direct du poste, comme s’il était assis devant.
4. Déploiement des outils : une fois connecté, l’attaquant dépose une archive dans le dossier Téléchargements, la décompresse dans un dossier nommé pour ressembler à une mise à jour Windows (par exemple “WinUpdate-2026-11”), puis exécute son contenu à l’aide d’un runtime Python, Bun ou Java portable.

La simplicité de cette technique est déconcertante : elle ne nécessite aucune faille logicielle, juste un peu de persuasion. Microsoft elle-même le souligne :

Il n’y a pas de correctif, car rien ici n’était une faille logicielle. - Microsoft

Pourquoi Microsoft Teams est un vecteur idéal

Teams est devenu un outil central dans les entreprises françaises. Sa large adoption, associée à la possibilité de contacter des utilisateurs depuis des tenants externes, en fait une plateforme de choix pour les campagnes d’ingénierie sociale. Contrairement au téléphone ou à l’email, où les utilisateurs sont plus méfiants, un message sur Teams peut paraître spontané et moins suspect. De plus, l’interface affiche le nom du tenant (par exemple “societe-support@externaltenant”), ce que l’attaquant peut manipuler pour ressembler au service interne. En 2026, l’ANSSI a d’ailleurs publié une alerte sur l’augmentation des attaques ciblant les outils de collaboration.

Les faiblesses AD CS exploitées : ESC1 et ESC8

Une fois le poste compromis, l’objectif de l’attaquant est d’élever ses privilèges et de se déplacer latéralement dans le réseau. Pour cela, les services de certificats Active Directory (AD CS) sont une cible de choix. AD CS est le composant Windows qui délivre les certificats X.509 utilisés pour l’authentification des utilisateurs et des machines dans l’environnement Active Directory. Lorsque la configuration est trop permissive, il devient possible d’obtenir des certificats pour des comptes à privilèges, contournant ainsi les mécanismes de mot de passe.

Les chercheurs en sécurité ont identifié plusieurs faiblesses dans les implémentations d’AD CS. En 2021, l’équipe de SpecterOps a publié des travaux détaillant les attaques dites “ESC”. Dans les incidents de 2026, les assaillants ont utilisé deux d’entre elles : ESC1 et ESC8.

Le tableau ci-dessous les compare :

Comment ESC8 fonctionne en détail

Le PetitPotam est une technique de coercion qui force une machine Windows à s’authentifier via le protocole SMB vers un serveur contrôlé par l’attaquant. En envoyant une requête spécifique, l’attaquant oblige le contrôleur de domaine à initier une connexion NTLM vers sa machine. Cette authentification, normalement éphémère, est ensuite relayée vers l’interface web d’enrôlement AD CS (souvent exposée sur le port 443). Si l’interface accepte NTLM sans EPA, l’attaquant peut demander un certificat pour le contrôleur de domaine sans jamais connaître son mot de passe. Une fois le certificat obtenu, il peut l’utiliser avec l’extension PKINIT de Kerberos pour obtenir un ticket granting ticket (TGT) pour le contrôleur de domaine, transformant ainsi une authentification ponctuelle en un accès permanent.

Pourquoi le certificat est plus dangereux qu’un mot de passe volé

Un mot de passe peut être changé, et les sessions actives peuvent être terminées. Un certificat, en revanche, continue de fonctionner même après la réinitialisation du mot de passe du compte qu’il représente. Comme le souligne Microsoft, “aucune de ces étapes ne met fin à l’accès de l’attaquant” si le certificat n’est pas révoqué. De plus, la révocation du certificat n’invalide pas les tickets Kerberos déjà émis ; il faut les supprimer manuellement. Cette persistance en fait un outil redoutable pour les assaillants.

Deux cas d’école en 2026

Microsoft a présenté deux scénarios distincts qui illustrent l’impact de ces faiblesses et l’importance d’une réponse rapide et exhaustive.

Cas n°1 : Confinement partiel, fuite de données

Dans la première intrusion, les assaillants ont identifié un modèle de certificat vulnérable à ESC1. En une première vague, ils ont ciblé trois utilisateurs et un poste de travail, obtenant des certificats pour trois comptes hautement privilégiés. Les mécanismes automatiques de Microsoft Defender for Identity ont immédiatement révoqué ces identités et mis fin à leurs sessions actives. Cependant, un compte privilégié n’était pas inclus dans cette réponse automatisée - une omission qui s’est avérée cruciale. Ce compte exclu est resté utilisable.

Environ 90 minutes plus tard, une seconde vague d’appels a touché 16 utilisateurs et un second poste de travail, produisant des certificats pour huit comptes privilégiés supplémentaires. Microsoft a observé plus de 1 000 tentatives ultérieures d’accès par SMB ou d’authentification, toutes bloquées. Cependant, quelques secondes après avoir obtenu un certificat pour le compte exclu, l’attaquant s’est connecté à un contrôleur de domaine et a exécuté l’outil DCSync pour copier le hash des mots de passe depuis l’Active Directory. La fuite avait déjà commencé lorsque le confinement s’est mis en place.

Le compte exclu a ensuite servi de porte d’entrée persistante : l’attaquant l’a utilisé pour atteindre un serveur de fichiers et exécuter une copie renommée de l’outil Rclone afin de transférer des données vers un serveur SFTP externe. Le volume exact des données dérobées n’a pas été communiqué par Microsoft, mais l’incident démontre la rapidité avec laquelle une exfiltration peut avoir lieu.

Le confinement partiel des identités peut réduire l’attaque tout en laissant une voie privilégiée viable. - Microsoft

Cas n°2 : Intervention rapide, attaque stoppée

Dans le second incident, la faiblesse ESC1 n’était pas exploitable (les modèles étaient correctement configurés). L’attaquant a donc utilisé PetitPotam pour forcer un contrôleur de domaine à s’authentifier sur une machine qu’il contrôlait, puis a relayé cette authentification NTLM vers l’interface web d’enrôlement AD CS (ESC8). Il a ainsi obtenu un certificat pour le contrôleur de domaine lui-même, sans mot de passe. Grâce à ce certificat et PKINIT, il a pu demander un TGT pour le contrôleur de domaine, transformant une authentification ponctuelle en identité persistante.

Cependant, les alertes ESC8 de Microsoft Defender ont été déclenchées, et le client a immédiatement isolé le poste de travail compromis. Aucune activité ultérieure n’a été détectée. La différence entre les deux cas réside dans la rapidité et l’exhaustivité de la réponse : ici, l’isolement d’un seul poste a suffi à bloquer l’attaque, tandis que dans le premier cas, le confinement partiel a laissé une voie ouverte.

Analyse comparative des deux incidents

Enseignements pour la sécurité : l’importance du confinement exhaustif

L’analyse de ces deux incidents met en lumière plusieurs leçons essentielles pour les équipes de cybersécurité :

• Les réponses automatisées doivent être exhaustives. L’exclusion d’un compte d’une réponse de confinement automatique peut ruiner l’efficacité de celle-ci. Microsoft recommande de traiter toute exclusion comme une décision délibérée nécessitant une action manuelle de remplacement (désactivation du compte, rotation de mot de passe, analyse forensique). En pratique, nous observons que de nombreuses organisations configurent des exceptions pour certains comptes sans évaluer le risque.
• Les certificats ne sont pas invalidés par la révocation des tickets Kerberos. Même si un certificat est révoqué, les tickets déjà émis restent valides jusqu’à leur expiration. Il est donc crucial d’auditer également les tickets Kerberos actifs après une révocation.
• La configuration par défaut d’AD CS est insuffisante. Les paramètres de sécurité comme l’Extended Protection for Authentication (EPA) ou la désactivation de NTLM sur les endpoints d’enrôlement ne sont pas activés par défaut avant Windows Server 2025. Sur les versions antérieures (2022, 2019), l’administrateur doit les configurer manuellement. Selon le rapport de Microsoft, les deux environnements ciblés utilisaient des versions antérieures.
• L’importance de la détection comportementale. Les alertes ESC8 sont levées par des solutions comme Microsoft Defender for Identity, mais elles doivent être intégrées dans un processus de réponse clair. Dans le cas n°2, l’isolement rapide a été décisif.

En France, l’ANSSI rappelle régulièrement l’importance de sécuriser Active Directory. Son guide de sécurisation des annuaires AD (2019, mis à jour en 2021) insiste sur l’audit des modèles de certificats et la limitation des droits d’enrôlement. En outre, la norme ISO 27001 exige une gestion rigoureuse du cycle de vie des certificats, incluant la révocation et la rotation.

Mesures de protection concrètes en 2026

Face à ces menaces, les organisations doivent mettre en œuvre une série de contrôles techniques et organisationnels. Voici les recommandations essentielles, basées sur le retour d’expérience de Microsoft et les bonnes pratiques du marché :

1. Vérifier systématiquement toute demande de support IT. Mettez en place une règle simple : tout contact non sollicité via Teams ou autre messagerie doit être confirmé par un canal interne (téléphone filaire, email connu). Les employés ne doivent jamais partager un code d’accès à distance sans validation. Organisez des campagnes de sensibilisation régulières.
2. Contrôler les locataires Teams autorisés. Limitez les tenants externes pouvant entrer en contact avec vos utilisateurs. Autorisez uniquement les outils d’assistance distante approuvés (et désactivez Quick Assist si non indispensable). Configurez Teams pour bloquer les appels entrants de locataires non autorisés.
3. Auditer et durcir les modèles de certificats AD CS. Identifiez les modèles qui permettent au demandeur de spécifier le nom du compte (type ESC1) et réduisez les droits d’enrôlement aux seuls utilisateurs ou machines qui en ont réellement besoin. Utilisez les alertes de posture de Microsoft Defender for Identity pour détecter les expositions. Revoyez également les modèles où le paramètre “Use for Authentication” est activé.
4. Sécuriser l’interface web d’enrôlement AD CS. Activez HTTPS, exigez l’Extended Protection for Authentication (EPA) et désactivez l’authentification NTLM. Le document Microsoft KB5005413 détaille la configuration précise. Depuis Windows Server 2025, EPA est actif par défaut, mais les versions antérieures nécessitent une intervention manuelle. Vérifiez que l’interface n’est pas exposée inutilement sur le réseau.
5. Activer l’audit des certificats et des tickets Kerberos. Configurez la journalisation des émissions de certificats (via les logs AD CS) et surveillez les anomalies : volume inhabituel, horaires anormaux, origines inattendues. En cas de certificat frauduleux, révoquez-le immédiatement, mais n’oubliez pas de lister et supprimer les tickets Kerberos déjà distribués (utilisez des commandes comme klist -s sur les machines concernées et ldapsearch pour les tickets AD).
6. Préparer des procédures de confinement manuelles. Ne comptez pas uniquement sur les réponses automatiques. Pour tout compte exclu des mécanismes automatisés, planifiez une action manuelle : désactivation du compte, rotation du mot de passe, mise en quarantaine du poste. Intégrez ces scénarios dans vos exercices de crise.

Détection des attaques ESC1 et ESC8

Microsoft a partagé quatre requêtes de chasse avancées comme points de départ pour l’investigation. Voici un exemple de logique de détection pour les demandes de certificats suspectes (à adapter selon votre solution SIEM) :

// Exemple de requête KQL pour détecter les demandes ESC1
IdentityDirectoryEvents
| where EventType == "CertificateRequest"
| where CertificateTemplateName contains "User" or CertificateTemplateName contains "Machine"
| where RequestedSubject contains "CN=admin" or RequestedSubject contains "CN=dc"
| where SourceUser != "SYSTEM"
| where Timestamp > ago(30d)

Les indicateurs de compromission suivants ont été associés aux scripts d’accès initial utilisés dans ces attaques :

SHA256 (script JavaScript) : 85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17
SHA256 (script Python)    : f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001
SHA256 (script Python)    : 06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7

Conclusion : une vigilance accrue sur l’ingénierie sociale et la configuration AD CS

Les attaques de 2026 démontrent que les techniques d’ingénierie sociale, combinées à des faiblesses de configuration dans des services critiques comme AD CS, peuvent conduire au vol de données sensibles en quelques dizaines de minutes. L’usurpation du support IT sur Microsoft Teams est une menace concrète, et l’abus des certificats Active Directory permet des escalades de privilèges silencieuses si les bonnes pratiques ne sont pas appliquées.

Pour les DSI et RSSI français, il est impératif de :

• Former les utilisateurs à reconnaître les signes d’une tentative d’usurpation du support IT (appel inattendu, demande d’accès à distance). Les simulations d’attaque (phishing et vishing) sont un excellent moyen de renforcer la vigilance.
• Réviser la configuration des services AD CS en priorité, en s’appuyant sur les recommandations de Microsoft (KB5005413) et de l’ANSSI. Un audit des modèles de certificats doit être mené trimestriellement.
• Mettre en place une réponse aux incidents qui combine automates et actions manuelles, afin qu’aucun compte privilégié ne reste exposé en cas d’exception.
• Simuler régulièrement des scénarios d’attaque (tabletop exercises) pour tester la réactivité des équipes et l’efficacité des procédures de confinement.
• Adopter une approche Zero Trust : ne faire confiance à aucune identité sans vérification continue, et limiter les capacités de déplacement latéral.

En 2026, la sécurité ne peut plus reposer uniquement sur la détection des correctifs. Elle exige une approche systémique où la configuration, la formation et les processus de réponse sont continuellement améliorés. L’attaque par usurpation du support IT sur Microsoft Teams est un signal fort : les failles humaines et les mauvaises configurations restent les portes d’entrée privilégiées des assaillants. Il est temps d’agir.

Pour aller plus loin, consultez les ressources suivantes : le guide ANSSI sur la sécurisation d’Active Directory, le document Microsoft KB5005413, et les rapports de Microsoft sur les menaces 2026. Enfin, n’oubliez pas que la prévention commence par la sensibilisation : chaque employé doit savoir qu’un support IT ne demande jamais un code d’accès à distance par Teams sans une confirmation préalable.