Usurpation du support IT sur Microsoft Teams : comment les attaquants exploitent AD CS pour dérober vos données

Hook : selon un rapport de Microsoft publié fin 2026, les attaquants ont réussi à dérober des données sensibles d’une entreprise en se faisant passer pour le service IT via Microsoft Teams, puis en abusant des services de certificat Active Directory (AD CS). Cette technique combine l’ingénierie sociale la plus élémentaire et des failles de configuration connues depuis 2021 - un cocktail redoutable qui contourne la plupart des protections traditionnelles. Comprendre ce scénario est crucial pour toute organisation souhaitant renforcer sa cybersécurité en 2026.

Comment se déroule l’attaque ? Du hameçonnage vocal à la compromission d’AD CS

L’appel Teams frauduleux

L’attaque commence par un message ou un appel Microsoft Teams provenant d’un locataire externe dont le nom évoque le support IT ou le helpdesk de l’entreprise cible. L’attaquant se fait passer pour un technicien et demande à la victime d’activer Quick Assist, outil de contrôle à distance intégré à Windows. En lisant le code de connexion affiché, l’utilisateur donne un accès direct et complet à sa machine.

« Aucune vulnérabilité dans Teams n’a été exploitée ; tout repose sur l’ingénierie sociale et une configuration laxiste d’AD CS. » - extrait du rapport Microsoft.

L’exécution du script malveillant

Une fois le contrôle obtenu, l’attaquant dépose une archive dans le dossier Téléchargements, l’extrait dans un dossier nommé pour ressembler à une mise à jour Windows, puis exécute son contenu via un runtime portable (Python, Bun ou Java). Les noms de fichiers, bien que trompeurs, conservent les métadonnées de version du runtime légitime. Ce premier stade permet de prendre pied sur le poste de travail sans déclencher d’alerte immédiate.

L’exploitation d’AD CS : deux chemins, deux configurations

Microsoft a décrit deux intrusions distinctes. Dans la première, l’attaquant a utilisé une faiblesse de modèle de certificat nommée ESC1 : le modèle permet au demandeur de spécifier l’identité que le certificat représentera. Ainsi, un compte sans privilèges peut demander un certificat pour un compte administrateur. Dans la seconde, la faille ESC8 a été exploitée : l’attaquant a forcé un contrôleur de domaine à s’authentifier via NTLM sur une machine contrôlée, puis a relayé cette authentification vers le portail d’inscription web d’AD CS pour obtenir un certificat pour le contrôleur de domaine lui-même.

ESC1 et ESC8 : les failles de configuration d’Active Directory Certificate Services

Active Directory Certificate Services (AD CS) est le service qui délivre les certificats utilisés par les comptes et les machines pour s’authentifier sur le réseau Windows. Un certificat obtenu sur un modèle mal configuré permet à son détenteur de se connecter comme le compte qu’il représente - même après une réinitialisation du mot de passe ou le wipe de la machine initiale. Cette persistence en fait une cible de choix pour les attaquants.

Tableau comparatif : ESC1 vs ESC8

Ces deux faiblesses ont été documentées par des chercheurs en 2021, mais leur combinaison avec l’ingénierie sociale via Teams est inédite dans la nature, souligne Microsoft.

Deux cas concrets analysés par Microsoft

Premier cas : la brèche partiellement contenue

Dans la première intrusion, l’attaquant a ciblé trois utilisateurs et un poste de travail, obtenant des certificats pour trois comptes hautement privilégiés. Microsoft Defender a automatiquement interrompu les sessions de ces comptes, mais un compte a été exclu de la réponse automatique. L’attaquant a continué à l’utiliser, atteignant un serveur de fichiers et exécutant Rclone (renommé) pour copier des données partagées vers un serveur SFTP externe. Microsoft n’a pas précisé le volume de données dérobées.

« La réponse partielle peut réduire l’activité de l’attaque tout en laissant une voie privilégiée viable » - résumé de Microsoft.

Environ 90 minutes plus tard, une seconde vague a touché 16 utilisateurs et un second poste, produisant 8 certificats supplémentaires. Plus de 1 000 tentatives ultérieures d’accès SMB ou de connexion ont été bloquées. Cependant, l’attaquant avait déjà accédé au contrôleur de domaine et exécuté DCSync pour copier les mots de passe du domaine. La contre-mesure a limité mais n’a pas empêché la fuite.

Second cas : une réponse rapide stoppe tout

Dans la seconde intrusion, le modèle de certificat n’était pas vulnérable à ESC1. L’attaquant a utilisé PetitPotam pour forcer un contrôleur de domaine à s’authentifier (NTLM) sur sa machine. Il a relayé cette authentification vers le portail web d’AD CS (ESC8), sans mot de passe, obtenant un certificat pour le contrôleur de domaine lui-même. Avec ce certificat et Kerberos (PKINIT), il a récupéré un ticket granting ticket, transformant un accès éphémère en identité persistante. Cependant, Defender a déclenché une alerte, le client a isolé le poste, et aucune autre action malveillante n’a eu lieu.

Cette différence illustre l’importance de la couverture complète des comptes dans les réponses automatiques.

Limites de la réponse automatisée et leçons à retenir

Le premier cas montre une faille dans la stratégie de containment : un compte exclu de la réponse automatisée a permis à l’attaque de continuer. Microsoft recommande de traiter tout compte exclu comme une décision délibérée et d’assigner une action manuelle équivalente. En pratique, il faut auditer régulièrement les exceptions dans les règles de réponse aux incidents.

Par ailleurs, la révocation d’un certificat n’invalide pas les tickets Kerberos déjà émis. Après avoir révoqué un certificat compromis, il est impératif de vérifier les tickets actifs et de les supprimer si nécessaire.

Mesures de protection pour les entreprises françaises

Aucun correctif n’est disponible, car il ne s’agit pas de failles logicielles mais de mauvaises configurations. Voici les actions concrètes à mettre en œuvre, en cohérence avec les recommandations de l’ANSSI et les bonnes pratiques AD CS :

Vérification des demandes de support IT

• Exiger une confirmation via un canal interne connu (email, intranet) avant d’accepter un contrôle à distance.
• Limiter les locataires Teams externes autorisés à contacter les employés.
• N’autoriser que les outils de support à distance validés par la DSI.

Durcissement d’AD CS

1. Auditer les modèles de certificats : identifier ceux qui permettent au demandeur de définir l’identité (vulnérabilité ESC1) et restreindre les droits d’inscription.
2. Activer HTTPS et Extended Protection for Authentication (EPA) sur les points de terminaison d’enrôlement web. EPA empêche le relais d’authentification même si NTLM est activé.
3. Désactiver NTLM sur le portail d’enrôlement quand c’est possible (se reporter à KB5005413 de Microsoft).
4. Mettre en place une surveillance des certificats : journaliser les émissions et détecter les certificats demandés depuis des postes non autorisés.

Détection et réponse

Voici un extrait de requêtes de chasse avancées fournies par Microsoft (à adapter à votre SIEM) :

// Exemple : rechercher les certificats dont le Subject contient un compte admin émis depuis un poste non-admin
(index=windows AND eventID=1 AND CertificateTemplate=*)
| rex field=_raw "Subject: (?<subject>[^,]+)"
| where subject matches ".*admin.*"
| stats count by src_ip

Microsoft a également publié trois hash SHA-256 des scripts initiaux :

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

Ces indicateurs peuvent nourrir vos listes de détection, mais Microsoft précise qu’ils ne sont que des points de départ, non une preuve absolue.

Recommandations pour les environnements Windows Server

• Windows Server 2025 : EPA est activé par défaut sur AD CS, ce qui réduit l’exposition à ESC8. Les serveurs 2022 et 2019 doivent être configurés manuellement.
• Appliquer les correctifs de sécurité réguliers, même s’ils ne corrigent pas directement ces faiblesses de configuration.

Conclusion : anticiper les attaques combinant social engineering et AD CS

Cette campagne montre que les attaquants n’ont pas besoin de vulnérabilités zero-day pour pénétrer un système d’information : un appel Teams bien mené, une configuration AD CS trop permissive, et un compte oublié dans la réponse automatisée suffisent à compromettre un domaine entier. Pour les RSSI français, la priorité doit être double : sensibiliser les utilisateurs à ne jamais donner le contrôle de leur poste sans vérification croisée, et durcir les services de certificat en suivant les guides de l’ANSSI et de Microsoft. La cybersécurité en 2026 exige de combiner rigueur des configurations et vigilance humaine - aucune couche ne peut à elle seule arrêter ce type d’attaque. Agissez dès aujourd’hui en auditant vos modèles AD CS et en formant vos équipes à ce scénario d’ingénierie sociale ciblé.