Faux support informatique sur Teams, puis certificats du domaine : Microsoft détaille deux intrusions via AD CS

Microsoft a enquêté sur deux intrusions lancées par de faux techniciens sur Teams, puis poursuivies grâce à Active Directory Certificate Services. Dans l’un des cas, des certificats de comptes à privilèges ont abouti au vol de données sur un serveur de fichiers. Aucune faille de Teams n’a été exploitée : tout a reposé sur un employé convaincu et une configuration AD CS dangereuse.

Ce qui s’est passé

Dans un rapport daté du 30 octobre 2026, Microsoft Threat Intelligence décrit deux intrusions dans des organisations non nommées. Le scénario de départ est identique : des messages et des appels Teams émanant de comptes qui se font passer pour le support, afin de convaincre des salariés d’ouvrir une session Assistance rapide (Quick Assist) ou un outil équivalent. Microsoft précise qu’aucune vulnérabilité de Teams n’a été exploitée et n’attribue ces attaques à aucun groupe.

Comment les attaquants sont entrés

Premier cas (ESC1). Une première vague vise trois utilisateurs et compromet un poste. Un modèle de certificat mal configuré permet alors d’obtenir des certificats pour trois comptes à hauts privilèges. Environ 90 minutes après l’interruption de la première session, une seconde vague vise 16 utilisateurs et rapporte des certificats pour huit autres comptes à privilèges. Quelques secondes après l’obtention de l’un d’eux, l’attaquant s’authentifie sur un contrôleur de domaine et lance un DCSync. Un compte à privilèges avait été exclu de la réponse automatique : il sert à atteindre un serveur de fichiers, d’où une copie renommée de Rclone envoie des données vers une destination SFTP externe.

Second cas (ESC8). PetitPotam force un contrôleur de domaine à s’authentifier auprès d’une machine contrôlée par l’attaquant. Cette authentification est relayée vers le service d’inscription web d’AD CS, ce qui fournit un certificat, puis un ticket Kerberos au nom du contrôleur. Le client a isolé le poste après les alertes ; aucune progression n’a suivi.

Que faire maintenant

  1. Encadrez Teams et l’assistance à distance : limitez les domaines externes, n’autorisez que les outils de support validés et faites confirmer toute demande de support non sollicitée par un canal interne connu.
  2. Auditez les modèles de certificats : lancez certutil -v -template et cherchez CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT sur les modèles qui permettent l’authentification. Désactivez l’option Fournir dans la demande, restreignez les droits d’inscription ou exigez l’approbation d’un responsable.
  3. Sécurisez l’inscription web : recensez les points d’accès Web Enrollment et Certificate Enrollment Web Service et supprimez ceux qui sont inutiles. Pour les autres, imposez HTTPS et réglez la protection étendue de l’authentification (EPA) sur « Requis », comme l’indique le KB5005413, puis exécutez iisreset /restart.
  4. Activez l’audit de l’autorité de certification pour les demandes et les émissions. Révoquez tout certificat illégitime, sans oublier les tickets Kerberos : la révocation n’annule pas ceux déjà émis.
  5. Passez en revue les exclusions de confinement : tout compte exclu de la réponse automatique exige un responsable désigné et une action manuelle.

Notre avis

L’hameçonnage explique l’entrée, mais c’est le paramétrage des certificats qui explique la vitesse : un seul poste a suffi pour atteindre des comptes de niveau domaine. AD CS est souvent installé une fois pour toutes puis oublié, alors qu’il mérite la même protection qu’un contrôleur de domaine.

Sources

Comment nous choisissons, vérifions et rédigeons nos analyses →

Les identifiants volés commencent souvent par un message de phishing. Reçu un message suspect (SMS, WhatsApp, réseaux sociaux) ou un e-mail ? Vérifiez-le avant de cliquer :

Vérifier un message Vérifier un e-mail

Vous craignez que vos serveurs soient exposés ? Notre équipe audite, corrige et surveille vos infrastructures Linux et cloud 24h/24, 7j/7.

Parler à un expert Notre offre d’infogérance de serveurs →