Exploitation d'Active Directory Certificate Services via Microsoft Teams : usurpation du support IT et vol de données

En 2026, l’ingénierie sociale demeure un vecteur d’attaque majeur, et Microsoft a récemment documenté une menace émergente : des assaillants se faisant passer pour le support informatique via Microsoft Teams et abusant d’Active Directory Certificate Services (AD CS) pour obtenir des certificats d’authentification privilégiés. Le rapport, publié en novembre 2026, relate deux intrusions distinctes. Dans l’une d’elles, les attaquants ont réussi à copier des données d’entreprise vers un serveur externe avant que le confinement ne soit total. Plus de 1 000 tentatives d’accès ultérieures ont été bloquées, mais la fuite a eu lieu. La particularité de ces attaques : elles n’exploitent aucune vulnérabilité de code, mais uniquement l’ingénierie sociale et des configurations AD CS laxistes. Cet article analyse le mode opératoire, les faiblesses exploitées, les leçons des deux cas, et les mesures défensives concrètes pour sécuriser votre infrastructure contre l’exploitation d’Active Directory Certificate Services via Microsoft Teams.

Le mode opératoire : de l’appel Teams à la compromisson du poste

Les attaquants ont suivi une procédure en plusieurs étapes, identique dans les deux intrusions :

1. Contact via Microsoft Teams : les assaillants utilisent un tenant externe dont le nom évoque le support interne (par exemple, « IT Helpdesk »). Ils appellent ou envoient un message à un employé, prétextant un problème technique urgent.
2. Demande d’utilisation de Quick Assist : ils convainquent la victime d’ouvrir l’outil de contrôle à distance intégré à Windows (Quick Assist) et de leur communiquer le code à six chiffres affiché.
3. Prise de contrôle à distance : une fois le code saisi, l’attaquant dispose d’un accès complet à la souris et au clavier de la machine.
4. Dépôt et exécution d’un script : l’assaillant télécharge une archive, la décompresse dans un dossier nommé pour ressembler à une mise à jour Windows (par exemple, « Windows Update v24.11 »), puis exécute un script (JavaScript ou Python) via un runtime portable.
5. Reconnaissance et escalade : le script établit une connexion avec l’infrastructure de l’attaquant et commence à sonder l’environnement Active Directory pour identifier les faiblesses AD CS.

Microsoft précise que les attaquants ont contacté dans un premier temps trois utilisateurs, puis seize autres 90 minutes plus tard, démontrant une organisation rapide et ciblée.

Ce mode opératoire illustre l’importance de la vérification des demandes de support. Les entreprises françaises, souvent cibles de campagnes d’ingénierie sociale, doivent intégrer cette menace dans leur plan de sensibilisation.

Exploitation d’Active Directory Certificate Services via Microsoft Teams : les faiblesses configurationnelles

L’étape cruciale de l’attaque est l’exploitation de AD CS, le service de certificats d’Active Directory. Deux faiblesses principales ont été identifiées :

• ESC1 (Subject specification) : le modèle de certificat permet au demandeur de spécifier l’identité (Subject) que le certificat représentera. Un utilisateur non privilégié peut ainsi demander un certificat pour un compte administrateur, sans interaction supplémentaire avec un contrôleur de domaine.
• ESC8 (NTLM relay to web enrollment) : l’attaquant utilise l’outil PetitPotam pour forcer un contrôleur de domaine à s’authentifier via NTLM vers une machine qu’il contrôle. Il relaie ensuite cette authentification vers la page d’inscription web d’AD CS, obtenant un certificat sans mot de passe.

Microsoft insiste sur le fait qu’un certificat émis via ces faiblesses continue de fonctionner même après la réinitialisation du mot de passe du compte ou la suppression de la machine d’origine. Cela signifie que les mesures classiques de remédiation (changement de mot de passe, reconstruction du poste) n’interrompent pas l’accès obtenu par certificat. Une vérification indépendante des certificats émis et des tickets Kerberos associés est nécessaire.

Ces vulnérabilités de configuration ne sont pas nouvelles : elles ont été présentées et documentées par des chercheurs lors de la conférence Black Hat 2021. Malgré cela, de nombreuses organisations n’ont pas audité leurs modèles de certificats et leurs points d’inscription. Microsoft a renforcé la sécurité par défaut dans Windows Server 2025 en activant Extended Protection for Authentication (EPA) sur les points d’inscription web AD CS. Cependant, les serveurs sous Windows Server 2022 ou 2019 nécessitent une activation manuelle, ce qui expose encore un grand nombre d’infrastructures. L’ANSSI, dans ses recommandations, insiste également sur le durcissement des services d’annuaire et de certificats.

Microsoft souligne que l’activation d’EPA est un prérequis pour empêcher les relais NTLM vers le service d’inscription web, et recommande de désactiver NTLM sur ces points si possible.

Analyse des deux intrusions : quand le confinement fait la différence

Le rapport détaille deux cas concrets qui illustrent l’impact des décisions de configuration et de réponse.

Cas 1 : la brèche ouverte par un compte exclu du confinement

Dans la première intrusion, les attaquants ont d’abord ciblé trois utilisateurs et un poste de travail, obtenant des certificats pour trois comptes hautement privilégiés. La détection automatique de Microsoft Defender a révoqué ces certificats et mis fin aux sessions actives. Cependant, un compte privilégié n’a pas été inclus dans la réponse automatique. Environ 90 minutes plus tard, une seconde vague a touché 16 utilisateurs et un deuxième poste, produisant des certificats pour huit comptes privilégiés supplémentaires. Microsoft a bloqué plus de 1 000 tentatives ultérieures d’accès aux fichiers via SMB ou de connexion.

Le compte exclu est resté opérationnel. Les attaquants l’ont utilisé pour se connecter à un serveur de fichiers et exécuter une copie renommée de Rclone, un outil de synchronisation, pour transférer des données depuis un partage vers un serveur SFTP externe. Microsoft n’a pas divulgué le volume de données dérobées, mais confirme que des données ont bien été copiées.

Ce cas montre qu’une réponse automatisée, même efficace, peut laisser une porte ouverte si elle n’est pas exhaustive. Comme le souligne Microsoft, la containment partielle des identités peut réduire l’activité malveillante tout en laissant une voie privilégiée viable.

Cas 2 : l’isolement immédiat stoppe l’attaque

Dans la seconde intrusion, la faiblesse ESC1 n’était pas présente. Les attaquants ont utilisé la combinaison PetitPotam + relais NTLM (ESC8) pour forcer un contrôleur de domaine à s’authentifier et obtenir un certificat pour le contrôleur lui-même. Grâce au mécanisme PKINIT, ils ont transformé cette authentification en un ticket Kerberus durable.

Cette fois, la réponse a été plus rapide : Microsoft Defender a généré des alertes spécifiques à ESC8, et le client a immédiatement isolé le poste de travail compromis. Aucune activité malveillante supplémentaire n’a été observée. L’isolement d’un seul poste de travail a suffi à stopper la progression, contrairement au cas 1 où la combinaison d’une réponse automatisée partielle et d’un compte non couvert a permis l’exfiltration de données.

Enseignements pour la réponse aux incidents

Ces deux cas mettent en lumière l’importance d’une couverture complète du confinement. Une réponse automatisée doit systématiquement être accompagnée d’une vérification manuelle des comptes exclus. La décision de ne pas inclure un compte dans une action de confinement doit être un choix explicite, non un oubli. En pratique, les équipes SOC doivent :

• Valider que tous les comptes privilégiés sont traités par les règles de réponse automatisée.
• Mettre en place des alertes pour tout compte non couvert.
• Prévoir une procédure manuelle de remédiation pour les exceptions.
• Tester régulièrement l’exhaustivité des réponses automatisées lors d’exercices de simulation.

Comme le note Microsoft, la containment partielle des identités peut réduire l’activité malveillante tout en laissant une voie privilégiée viable.

Détection proactive et indicateurs de compromission

Pour détecter ce type d’attaque avant qu’elle n’aboutisse, les équipes de sécurité doivent surveiller plusieurs signaux. Microsoft fournit des alertes Defender couvrant les étapes Teams, endpoints et identités. Voici quelques indicateurs clés :

• Connexions Teams inhabituelles en provenance de tenants externes non répertoriés.
• Utilisation de l’outil Quick Assist en dehors des plages de maintenance prévues.
• Exécution de scripts depuis le dossier Téléchargements avec un runtime portable.
• Demandes de certificats AD CS avec des spécifications de sujet anormales (ESC1).
• Tentatives de relais NTLM vers les points d’inscription web (ESC8).

Microsoft a également publié les empreintes SHA-256 des scripts initiaux utilisés dans les attaques :

SHA-256 (JavaScript initial-access script) : 85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17
SHA-256 (Python initial-access script)    : f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001
SHA-256 (Python initial-access script)    : 06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7

Ces indicateurs peuvent être intégrés dans vos SIEM et EDR. En complément, le rapport inclut quatre requêtes de chasse avancées qui constituent des points de départ pour les investigations.

Mesures de défense concrètes pour votre entreprise

Il n’existe pas de correctif logiciel pour ces attaques, car elles n’exploitent aucune faille de code. La protection repose sur la configuration et la formation. Voici les six mesures clés recommandées par Microsoft :

1. Vérification systématique des demandes de support : tout collaborateur recevant une demande d’assistance inattendue via Teams ou tout autre canal doit la confirmer par un moyen interne connu (email, intranet, téléphone) avant d’autoriser un accès à distance. Sensibilisez vos équipes à cet aspect.

2. Restriction des connexions Teams externes : limitez les tenants externes autorisés à contacter vos collaborateurs. N’autorisez que les outils de contrôle à distance approuvés par votre politique de sécurité. Bloquez Quick Assist si son utilisation métier n’est pas justifiée.

3. Audit des modèles de certificats AD CS : identifiez les modèles qui permettent au demandeur de spécifier l’identité (Subject) et ceux qui accordent des droits d’inscription trop larges. Supprimez les modèles superflus et réduisez les droits au strict nécessaire. Utilisez les outils d’audit de Microsoft Defender for Identity pour détecter les modèles vulnérables à ESC1.

4. Sécurisation des points de terminaison d’inscription web : activez le protocole HTTPS et l’Extended Protection for Authentication (EPA). Désactivez l’authentification NTLM sur ces pages lorsque c’est possible. La base de connaissances Microsoft KB5005413 fournit des instructions détaillées pour activer EPA et désactiver NTLM.

5. Audit actif des certificats et des tickets Kerberos : activez la journalisation des émissions de certificats. En cas de certificat frauduleux, révoquez-le, mais n’oubliez pas de revoir les tickets Kerberos déjà délivrés, car la révocation du certificat ne les annule pas automatiquement. Examinez les tickets actifs pour détecter toute utilisation anormale.

6. Traitement des exceptions de confinement : tout compte non couvert par une réponse automatisée doit être traité comme un incident nécessitant une action manuelle immédiate. Intégrez cette règle dans vos playbooks de réponse.

Conclusion : une menace configurationnelle, mais des parades existent

Les attaques décrites par Microsoft en novembre 2026 illustrent une tendance préoccupante : l’ingénierie sociale combinée à des configurations insuffisamment sécurisées d’infrastructures critiques comme Active Directory Certificate Services. Bien qu’aucun correctif ne soit nécessaire, la responsabilité de la protection incombe aux équipes IT et sécurité. En appliquant les recommandations ci-dessus - formation des utilisateurs, audit régulier des modèles de certificats, activation d’EPA, et gestion rigoureuse des réponses automatisées - vous réduisez significativement le risque de voir votre entreprise victime de l’exploitation d’Active Directory Certificate Services via Microsoft Teams. Restez vigilants et adaptez votre posture de sécurité face à une menace qui évolue en s’appuyant sur des techniques sociales, non sur des failles de code.

Ce cas rappelle également que la sécurité ne se limite pas aux correctifs : elle passe par la formation, l’audit de configuration et une réponse aux incidents rigoureuse. Les entreprises françaises, souvent ciblées par des attaques similaires, ont tout intérêt à renforcer leurs défenses dès maintenant.