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

Une campagne d’ingénierie sociale inédite cible Microsoft Teams

Une récente campagne d’attaques par ingénierie sociale ciblant Microsoft Teams a révélé une faille de configuration critique dans les services de certificat Active Directory (AD CS). Selon un rapport de Microsoft, les assaillants, se faisant passer pour le support informatique, ont convaincu des employés de leur donner le contrôle à distance de leur poste, avant de détourner des certificats AD CS mal sécurisés pour accéder à des comptes privilégiés. Ces attaques, bien que ne reposant sur aucune vulnérabilité logicielle, soulignent l’importance d’une configuration rigoureuse des infrastructures d’authentification. Découvrez dans cet article le détail des techniques employées, les deux cas analysés par Microsoft et les mesures concrètes pour renforcer votre sécurité.

Comment les attaquants obtiennent l’accès initial : l’usurpation du support IT

Les deux intrusions documentées par Microsoft ont débuté de manière identique. Les attaquants contactaient leurs victimes via Microsoft Teams en se faisant passer pour le service d’assistance informatique interne. Ils utilisaient des tenants externes avec des noms à consonance support (par exemple « IT Helpdesk ») pour paraître légitimes.

Une fois la conversation engagée, ils demandaient à l’employé d’ouvrir Quick Assist, un outil de contrôle à distance intégré à Windows. L’utilisateur devait simplement lire le code de connexion affiché, ce qui accordait aux assaillants un accès direct et complet au poste de travail.

« Aucune vulnérabilité dans Teams n’a été exploitée ; seule l’ingénierie sociale a permis l’intrusion initiale. » - Microsoft

À partir de là, l’attaquant déposait une archive dans le dossier Téléchargements, la décompressait dans un dossier nommé pour ressembler à une mise à jour Windows, et exécutait son contenu à l’aide d’un runtime Python, Bun ou Java portable. Les noms de fichiers eux-mêmes étaient un faible indicateur, car une copie avait été renommée tout en conservant les informations de version du runtime d’origine.

Selon le rapport, une première vague a ciblé 3 utilisateurs et un poste de travail, suivie 90 minutes plus tard d’une seconde vague touchant 16 utilisateurs et un autre poste. Au total, plus de 1 000 tentatives d’accès ultérieures ont été bloquées par Microsoft Defender, mais un compte privilégié exclu de la réponse automatique a permis la persistance. Cette technique d’ingénierie sociale, parfois appelée vishing adapté à Teams, exploite la confiance naturelle des employés envers le service IT. Selon l’ANSSI, près de 80 % des cyberattaques reposent sur l’erreur humaine ; cette campagne en est une illustration parfaite.

Les faiblesses AD CS au cœur de l’escalade de privilèges

Active Directory Certificate Services (AD CS) est le service chargé de délivrer les certificats que les utilisateurs et les ordinateurs présentent lors de l’authentification. Un certificat émis à partir d’un modèle mal configuré permet à son détenteur de se connecter en tant que le compte qu’il nomme. Microsoft souligne qu’un tel certificat continue de fonctionner même après la réinitialisation du mot de passe du compte ou l’effacement de la machine initiale, ce qui rend la remédiation particulièrement délicate.

La recherche a identifié plusieurs classes de faiblesses dans AD CS, dont deux ont été exploitées lors de ces attaques : ESC1 et ESC8.

ESC1 : le demandeur choisit l’identité du certificat

Dans le premier cas, les attaquants ont trouvé un modèle de certificat avec une vulnérabilité de type ESC1. Cela signifie que toute personne autorisée à demander un certificat peut spécifier le compte qu’il représentera. Ainsi, un utilisateur avec de faibles privilèges peut obtenir un certificat pour un compte administrateur.

Cas n°1 détaillé :

• Première vague : 3 utilisateurs ciblés, 1 poste de travail, obtention de certificats pour 3 comptes hautement privilégiés.
• La réponse automatique de Microsoft Defender a interrompu ces sessions, mais un compte privilégié avait été exclu de la réponse automatique, restant donc actif.
• 90 minutes plus tard, seconde vague : 16 utilisateurs et un second poste, certificats pour 8 comptes privilégiés supplémentaires.
• Plus de 1 000 tentatives ultérieures d’accès via SMB ou de connexion ont été bloquées.
• L’attaquant a utilisé le compte exclu pour atteindre un serveur de fichiers, exécuter DCSync afin de copier des mots de passe depuis l’Active Directory, puis une copie renommée de l’outil Rclone pour exfiltrer les données vers un serveur SFTP externe.

« L’identité partiellement contenue peut réduire l’activité malveillante tout en laissant une voie privilégiée viable. » - Microsoft

ESC8 : le relais NTLM vers le point d’enrôlement AD CS

Dans le second cas, le modèle de certificat ne présentait pas de faiblesse ESC1, mais l’infrastructure AD CS était vulnérable à ESC8. Les attaquants ont utilisé PetitPotam pour forcer un contrôleur de domaine à s’authentifier via NTLM vers une machine qu’ils contrôlaient. Ce hash NTLM a été relayé vers la page d’enrôlement web d’AD CS, permettant d’obtenir un certificat pour le contrôleur de domaine lui-même.

Avec ce certificat et le mécanisme PKINIT (authentification Kerberos par certificat), l’attaquant a récupéré un ticket d’octroi de ticket (TGT) pour le contrôleur de domaine, transformant un relais unique en une identité persistante. Heureusement, Microsoft Defender a émis des alertes ESC8, le client a isolé le poste compromis, et aucune activité supplémentaire n’a été observée. Cet isolement rapide a été la clé ; il démontre que la réponse aux incidents, couplée à la détection, peut stopper une attaque même après un accès initial.

Comparaison des deux faiblesses exploitées :

Pourquoi ces attaques sont-elles particulièrement insidieuses ?

Plusieurs facteurs rendent cette campagne préoccupante :

• Persistance après réinitialisation : un certificat délivré reste valide même si le mot de passe du compte est changé ou si la machine compromise est réinstallée.
• Difficulté de détection : les actions initiales (appel Teams, utilisation de Quick Assist, exécution de binaires portables) peuvent passer inaperçues sans supervision adéquate.
• Échec de la réponse automatique : comme l’a montré le premier cas, si un compte est exclu du périmètre de containment, l’attaquant conserve une voie d’accès privilégiée.
• Aucun correctif : il ne s’agit pas de failles logicielles mais de mauvaises configurations, ce qui exige une action proactive des équipes sécurité.

D’après le rapport, aucun groupe connu n’a été attribué à ces intrusions, ce qui rend difficile le profilage des assaillants. Les méthodes utilisées ne sont pas nouvelles : les faiblesses ESC1 et ESC8 ont été documentées dès 2021, et l’entrée via Teams avait déjà été décrite par Microsoft plus tôt en 2026. Cependant, leur combinaison dans des attaques réelles souligne l’urgence de sécuriser AD CS. En France, où de nombreuses entreprises utilisent encore Active Directory avec des configurations par défaut, cette menace est particulièrement prégnante. L’ANSSI, dans ses recommandations, insiste sur la nécessité de durcir les services de certificats.

Mesures de défense : comment protéger votre Active Directory

Microsoft a publié plusieurs recommandations, que nous détaillons ici, en les adaptant au contexte des organisations françaises.

1. Vérifier les demandes de support via un canal secondaire

Toute demande inattendue d’assistance doit être confirmée par un canal officiel (email, intranet, appel sortant). Les équipes doivent être formées à ne jamais partager un code de connexion Quick Assist sans validation préalable. Des simulations d’ingénierie sociale peuvent aider à renforcer ces réflexes.

2. Limiter les tenants Teams autorisés

Restreindre les tenants externes pouvant contacter les employés. N’autoriser que les outils de support à distance validés par la DSI. Dans la console d’administration Teams, vous pouvez définir une liste blanche de tenants. Cela réduit la surface d’attaque dès le départ.

3. Auditer les modèles de certificats AD CS

Recenser les modèles de certificats qui permettent au demandeur de spécifier le sujet (SAN) ou qui accordent des droits d’enrôlement à trop d’utilisateurs. Supprimer les droits superflus. L’ANSSI recommande dans son guide de sécurisation d’Active Directory de limiter les inscriptions aux modèles de certificats aux seuls utilisateurs autorisés. Des outils comme BloodHound peuvent aider à cartographier ces relations.

4. Sécuriser le point de terminaison d’enrôlement AD CS

• Exiger HTTPS.
• Activer Extended Protection for Authentication (EPA) sur les points de terminaison web d’enrôlement.
• Désactiver NTLM sur ces points si possible.
• Microsoft indique que le KB5005413 couvre ces configurations, et que Defender for Identity peut signaler les modèles et points de terminaison exposés à ESC1 et ESC8.

5. Activer l’audit des certificats

Mettre en place une journalisation des émissions de certificats. En cas d’incident, révoquer les certificats malveillants et vérifier les tickets Kerberos actifs (la révocation ne les invalide pas). La corrélation entre les émissions de certificats et les connexions suspectes peut être intégrée à un SIEM.

6. Ne pas exclure de comptes de la réponse automatique sans action de remplacement

Dans le premier cas, un compte exclu manuellement a permis la persistance. Microsoft recommande de traiter toute exclusion comme une décision délibérée et d’y associer une action manuelle (par exemple, rotation des mots de passe, vérification des sessions). Revoyez vos playbooks de réponse aux incidents pour inclure cette vérification.

7. Tenir compte des évolutions récentes

Sous Windows Server 2025, EPA est activé par défaut pour AD CS, contrairement à Server 2022 et 2019 où il doit être activé manuellement. Migrer vers les versions récentes peut donc réduire la surface d’attaque. D’ici là, vérifiez manuellement que vos contrôleurs de domaine exécutant AD CS ont la configuration EPA active.

Récapitulatif des priorités :

Indicateurs de compromission et pistes de détection

Microsoft a partagé des alertes Defender couvrant Teams, les endpoints et l’identité, ainsi que quatre requêtes de chasse avancées. Les empreintes SHA-256 des scripts d’accès initial sont :

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

Ces indicateurs peuvent être intégrés aux SIEM pour détecter des déploiements similaires. De plus, surveillez les demandes de certificats inhabituelles, les connexions Teams depuis des tenants externes non reconnus, et l’exécution de Quick Assist en dehors des heures de bureau.

Conclusion : une vigilance accrue sur la configuration AD CS et la sensibilisation

L’attaque décrite dans ce rapport de Microsoft illustre la convergence de techniques connues - ingénierie sociale via Teams, exploitation de faiblesses AD CS - en une campagne opérationnelle. Aucune faille zero-day n’est nécessaire ; ce sont les configurations par défaut ou mal durcies qui ouvrent la porte.

Pour les équipes de sécurité françaises, cette affaire rappelle l’importance de :

• Former les utilisateurs à reconnaître les demandes de support frauduleuses.
• Auditer régulièrement la configuration des services de certificat Active Directory selon les recommandations de l’ANSSI.
• Mettre en place une réponse aux incidents qui couvre l’ensemble des identités, sans exclusion oubliée.

En adoptant ces mesures, vous réduisez significativement le risque qu’une attaque similaire compromette vos données sensibles. Comme le souligne Microsoft, la clé réside dans la configuration et la réponse, et non dans l’attente d’un correctif.

N’attendez pas que votre organisation soit la prochaine cible : planifiez dès aujourd’hui un audit de votre Active Directory et de vos politiques de support à distance. La sécurité de vos données en dépend.