Dans un rapport publié le 30 octobre 2026, Microsoft Threat Intelligence décrit deux intrusions qui ont débuté par l’usurpation du support informatique sur Microsoft Teams, puis exploité des failles de configuration d’Active Directory Certificate Services (AD CS). Teams a servi de canal d’ingénierie sociale, pas de vecteur à une faille logicielle, selon le compte rendu de Microsoft.
De Teams à une session à distance
Dans les deux cas, les attaquants se sont fait passer pour des techniciens informatiques par messages ou appels Teams. Ils ont convaincu des utilisateurs d’accorder un accès à distance, principalement avec Quick Assist. Une fois connectés, ils ont déposé des archives, exécuté des scripts avec des runtimes portables comme Python, Bun ou Java, puis recherché des informations sur les postes et le réseau avant de s’intéresser à AD CS.
Microsoft décrit notamment des runtimes lancés depuis des répertoires récemment créés et accessibles en écriture par l’utilisateur, parfois préfixés par « KB ». Un nom de fichier ou la présence de Bun ou Java ne suffit pas à caractériser une intrusion : le chemin d’exécution, le processus parent, la session distante et les activités qui suivent donnent le contexte utile.
Deux voies d’attaque dans AD CS
AD CS gère les certificats utilisés pour l’authentification. Les deux intrusions ont suivi des chemins différents pour obtenir des certificats associés à des identités privilégiées.
ESC1 : des certificats privilégiés et un compte exclu du confinement
Dans le premier cas, un modèle de certificat mal configuré permettait à des utilisateurs disposant de faibles privilèges de demander des certificats représentant des comptes privilégiés. La première vague a visé trois utilisateurs et un poste ; elle a conduit à l’obtention de certificats pour trois comptes hautement privilégiés. Environ 90 minutes plus tard, une seconde vague a ciblé 16 utilisateurs et un autre poste, puis l’attaquant a obtenu des certificats pour huit comptes privilégiés supplémentaires.
Microsoft Defender a bloqué plus de 1 000 tentatives ultérieures d’accès à des fichiers via SMB et de connexion. Un DCSync, opération qui imite la réplication des données d’annuaire, avait toutefois débuté quelques secondes après l’obtention d’un certificat privilégié. Une identité privilégiée exclue du confinement automatique est restée utilisable. L’attaquant s’en est servi pour accéder à un serveur de fichiers et transférer des données vers une destination SFTP externe.
PetitPotam et ESC8 : relayer l’authentification d’un contrôleur de domaine
Dans le second cas, PetitPotam a provoqué l’authentification NTLM d’un contrôleur de domaine vers un système contrôlé par l’attaquant. Celui-ci a relayé cette authentification vers le service Web Enrollment d’AD CS, selon la méthode ESC8, et obtenu un certificat pour le compte machine du contrôleur de domaine. Il l’a ensuite utilisé pour une authentification Kerberos par certificat, appelée PKINIT, et demander un ticket TGT.
Microsoft Defender a généré des alertes liées à ESC8. Le client a isolé le poste associé à l’activité, après quoi Microsoft n’a observé aucune progression supplémentaire de l’attaque.
Quels signaux peuvent guider l’enquête ?
Microsoft décrit quatre catégories de requêtes de chasse aux menaces : les contacts externes suspects et les signes d’usurpation sur Teams ; l’exécution de Bun ou Java depuis des chemins de staging préfixés par « KB » ; l’activité réseau de ces runtimes vers les ports 80, 445, 636 ou 88 ; et les alertes concernant les relais NTLM, Certificate Services, PKINIT ou les demandes de tickets Kerberos.
Une enquête utile relie ces signaux plutôt que de s’arrêter à une alerte isolée. Les équipes peuvent rapprocher l’échange Teams et la session distante de l’arborescence des processus, des chemins et métadonnées des fichiers, de l’activité réseau, des demandes et émissions de certificats, puis des alertes d’identité et des événements Kerberos. Microsoft précise que ses requêtes doivent être adaptées à l’environnement et que leurs résultats servent de pistes à examiner, pas de preuve de compromission à eux seuls.
Les mesures de réponse recommandées par Microsoft
Pour réduire le risque d’usurpation, Microsoft recommande de faire vérifier toute demande de support inattendue par un canal interne connu, d’examiner les besoins d’accès externe à Teams et de limiter les outils d’assistance à distance aux procédures approuvées.
Côté AD CS, les équipes doivent examiner les modèles d’authentification qui autorisent la saisie d’informations d’identité par le demandeur, les droits d’inscription trop larges et les contrôles d’émission insuffisants. Microsoft recommande aussi de retirer les points de terminaison Web Enrollment inutiles, d’imposer HTTPS et la protection étendue de l’authentification (EPA), et de désactiver NTLM sur les services d’inscription lorsque le fonctionnement de l’organisation le permet. Sa fiche KB5005413 sur la réduction des relais NTLM contre AD CS détaille ces protections ; la documentation Microsoft sur les évaluations de sécurité des certificats décrit les risques associés aux modèles ESC1 et aux points de terminaison Web vulnérables à ESC8.
En cas de certificat émis sans autorisation, changer le mot de passe ou réinstaller le poste ne révoque pas ce certificat et n’invalide pas les tickets Kerberos déjà délivrés. La révocation du certificat et l’examen des tickets actifs sont deux opérations distinctes. Chaque identité ou appareil exclu du confinement automatique nécessite une intervention manuelle et la vérification de son exécution.
