Attaque AD CS Microsoft Teams : ingénierie sociale et certificats compromis
Séraphine Clairlune
En novembre 2026, Microsoft a publié un rapport détaillant deux intrusions où des attaquants se sont fait passer pour le support IT via Microsoft Teams. En exploitant des configurations vulnérables d’Active Directory Certificate Services (AD CS), ils ont réussi à obtenir des certificats de connexion pour des comptes privilégiés, dont un contrôleur de domaine. Cette attaque AD CS Microsoft Teams combine habilement ingénierie sociale et faiblesses techniques, rappelant que la sécurité ne repose pas uniquement sur des correctifs logiciels.
Selon l’ANSSI, près de 80 % des cyberattaques réussies en France impliquent un facteur humain. L’ingénierie sociale reste le vecteur d’accès privilégié des attaquants, et ce cas d’école illustre parfaitement comment quelques secondes de confiance accordée à un faux support IT peuvent suffire à compromettre tout un domaine.
Pourquoi les certificats AD CS sont une cible de choix
Avant d’entrer dans le vif du sujet, il est utile de comprendre pourquoi AD CS attire autant les attaquants. Active Directory Certificate Services gère les certificats dans un domaine Windows. Ces certificats peuvent être utilisés pour l’authentification, notamment via Kerberos (PKINIT). Un certificat bien configuré offre une authentification forte, mais un certificat mal émis peut remplacer un mot de passe.
L’avantage pour l’attaquant : un certificat volé reste valide même après une réinitialisation de mot de passe ou la réinstallation de la machine d’origine. Comme l’a démontré Microsoft, un certificat pour un compte privilégié ou pour un contrôleur de domaine offre un accès persistant difficile à déceler.
L’ingénierie sociale comme porte d’entrée
L’attaque débute toujours par un appel ou un message sur Microsoft Teams. L’attaquant se présente comme un membre du support IT interne. Pour rendre le contact légitime, il utilise un locataire Teams externe dont le nom évoque le service d’assistance (par exemple « IT-Help » ou « Service Desk »). La conversation est conçue pour inciter l’employé à accorder un accès à distance.
L’outil utilisé est Quick Assist, une fonctionnalité intégrée à Windows permettant le contrôle à distance. L’employé est invité à ouvrir l’outil et à communiquer le code de connexion à l’attaquant. En quelques secondes, ce dernier obtient un contrôle direct de la machine.
Une fois connecté, l’attaquant dépose une archive dans le dossier Téléchargements, l’extrait dans un dossier au nom trompeur (ressemblant à une mise à jour Windows), et exécute son contenu à l’aide d’un runtime portable Python, Bun ou Java. Quick Assist n’est pas une vulnérabilité : c’est un outil légitime détourné de son usage.
Dans la pratique, nous avons observé que les employés formés aux risques d’ingénierie sociale sont moins susceptibles de céder à ce type de demande. En France, une PME du secteur industriel a récemment été visée par une campagne similaire, mais une politique de double vérification des demandes de support via un canal officiel a permis de déjouer l’attaque avant toute compromission.
L’exploitation des certificats AD CS : deux techniques clés
AD CS est le service Windows chargé de délivrer les certificats utilisés pour l’authentification des utilisateurs et des machines. Un certificat émis à partir d’un modèle mal configuré permet à son détenteur de se connecter comme le compte qu’il représente. Pire : un tel certificat reste valide même après une réinitialisation de mot de passe ou un nettoyage de la machine source.
Deux faiblesses connues, désignées sous les noms d’ESC1 et ESC8, ont été exploitées dans ces intrusions.
ESC1 : le certificat sur mesure
Dans ce scénario, le modèle de certificat permet au demandeur de spécifier le nom du compte pour lequel le certificat est émis. Ainsi, un utilisateur avec peu de privilèges peut demander un certificat pour un compte administrateur. Microsoft indique que cette vulnérabilité est connue depuis 2021, mais sa persistance dans les configurations d’entreprise est alarmante. Un simple audit des modèles de certificats avec le paramètre RequesterCanSpecifyIdentity activé permet de les identifier.
ESC8 : le relais d’authentification
Lorsque l’interface web d’enregistrement AD CS accepte l’authentification NTLM sans protections supplémentaires (comme l’Extended Protection for Authentication ou EPA), un attaquant peut forcer un contrôleur de domaine à s’authentifier sur une machine qu’il contrôle via l’outil PetitPotam, puis relayer cette authentification pour obtenir un certificat. La technique transforme une authentification ponctuelle en identité durable. Microsoft recommande d’activer EPA et de désactiver NTLM sur ces points de terminaison, comme détaillé dans la KB5005413.
Retour sur deux intrusions réelles
Microsoft a partagé les détails de deux campagnes distinctes. Le tableau ci-dessous en résume les différences essentielles.
| Caractéristique | Cas n°1 (ESC1) | Cas n°2 (ESC8) |
|---|---|---|
| Vecteur d’accès | Ingénierie sociale Teams + Quick Assist | Idem |
| Technique AD CS | ESC1 (modèle de certificat modifiable) | ESC8 (relais NTLM vers web enrollment) |
| Cible | Certificats pour comptes privilégiés | Certificat pour le contrôleur de domaine |
| Confinement | Automatique par Microsoft Defender (un compte exclu) | Isolation manuelle du poste de travail |
| Résultat | Exfiltration de données vers un serveur SFTP externe | Aucune activité détectée après confinement |
Cas n°1 : un compte exclu qui change la donne
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. Microsoft Defender a automatiquement interrompu ces sessions et révoqué les certificats. Cependant, un compte privilégié avait été laissé de côté par cette 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 supplémentaires. Microsoft indique que plus de 1 000 tentatives ultérieures d’accès par SMB ou de connexion ont été bloquées.
Mais le compte exclu est resté actif. En quelques secondes, l’attaquant l’a utilisé pour se connecter au contrôleur de domaine et exécuter DCSync afin de copier les mots de passe du domaine. Il a ensuite atteint un serveur de fichiers et utilisé une copie renommée de l’outil Rclone pour exfiltrer des données vers un serveur SFTP externe. Microsoft n’a pas précisé le volume exact de données dérobées.
La leçon, selon Microsoft : « un confinement partiel de l’identité peut réduire l’activité de l’attaque tout en laissant une voie privilégiée viable ».
Cas n°2 : PetitPotam et le contrôleur de domaine
La seconde intrusion a débuté de la même manière mais n’a pas pu utiliser ESC1 car le modèle de certificat n’était pas vulnérable. Les attaquants ont alors eu recours à PetitPotam pour forcer le contrôleur de domaine à s’authentifier sur une machine qu’ils contrôlaient. Cette authentification NTLM a été relayée vers la page d’enregistrement web d’AD CS (ESC8), permettant d’obtenir un certificat pour le contrôleur de domaine lui-même.
Avec ce certificat et le mécanisme PKINIT (Kerberos), l’attaquant a obtenu un ticket TGT (Ticket Granting Ticket) pour le contrôleur de domaine. Heureusement, Microsoft Defender a levé une alerte ESC8, le client a isolé le poste de travail, et aucune activité malveillante supplémentaire n’a été observée.
Enseignements pour les équipes de sécurité
Ces deux cas illustrent l’importance d’un confinement rapide et complet. La faille dans le premier cas réside dans un compte « oublié » par la réponse automatique. Microsoft insiste sur le fait que tout compte exclu d’une mesure de confinement automatique doit faire l’objet d’une action manuelle dédiée.
Par ailleurs, ces attaques ne nécessitent aucun correctif : les méthodes reposent sur des fonctionnalités légitimes mal configurées. La sécurisation passe par la configuration et la formation. L’ANSSI, dans son guide de gestion des identités et des accès, souligne régulièrement l’importance de durcir les services d’authentification.
« La meilleure défense contre ce type d’attaque est une combinaison de formation des utilisateurs et de durcissement de la configuration AD CS. » - ANSSI (paraphrase d’après ses recommandations 2025)
Actions correctives à mettre en œuvre
Voici les mesures recommandées par Microsoft et par l’ANSSI pour se prémunir contre ce type d’attaque.
Vérification des demandes de support
Toute demande de support inattendue doit être confirmée via un canal interne connu (téléphone, chat interne officiel) avant d’accorder un accès à distance. Limitez les locataires Teams externes autorisés à contacter vos utilisateurs. N’autorisez que les outils de support à distance validés par votre service informatique.
Sécurisation des modèles de certificats
Passez en revue vos modèles de certificats de connexion. Identifiez ceux qui permettent au demandeur de spécifier le nom du compte (ESC1) ou qui sont accessibles à un trop grand nombre d’utilisateurs. Supprimez les droits d’inscription inutiles. Utilisez des outils comme ldapsearch ou des requêtes PowerShell pour lister les modèles vulnérables.
Renforcement des points de terminaison web
Exigez HTTPS et activez l’Extended Protection for Authentication (EPA) sur les interfaces web d’enregistrement d’AD CS. Désactivez l’authentification NTLM sur ces points lorsque cela est possible. La KB5005413 de Microsoft couvre ces configurations, et les vérifications de posture de Microsoft Defender for Identity signalent les modèles et points de terminaison exposés aux attaques ESC1 et ESC8.
Audit des certificats et tickets Kerberos
Activez l’audit des certificats. En cas de certificat frauduleux, révoquez-le, mais rappelez-vous que la révocation n’annule pas les tickets Kerberos déjà émis. Vérifiez également les tickets actifs. Utilisez les requêtes de détection avancées fournies par Microsoft comme point de départ pour vos investigations.
Voici un exemple de requête de détection (adaptée de Microsoft) pour identifier les demandes de certificats suspectes :
// Détection des demandes de certificats sur des modèles vulnérables
identity_events
| where action = "Certificate Sign Request"
| where certificate_template in ["VulnerableTemplate1", "VulnerableTemplate2"]
| where requester != "authorized_admin"
| project timestamp, user, source_ip, template, serial_number
Indicateurs de compromission (IoC)
Microsoft a publié trois empreintes SHA-256 liées aux scripts d’accès initiaux utilisés dans ces attaques :
85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17(script JavaScript)f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001(script Python)06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7(script Python)
Conclusion : la configuration et la formation, boucliers indispensables
L’attaque AD CS Microsoft Teams démontre que les cybercriminels savent combiner persuasion sociale et faiblesses de configuration pour pénétrer les systèmes les plus sensibles. Aucun correctif ne viendra résoudre ce problème ; c’est sur le terrain de la prévention que la bataille se gagne.
Pour les entreprises françaises, les recommandations de l’ANSSI en matière de gestion des identités et des accès prennent ici tout leur sens. La mise en œuvre rigoureuse des contrôles listés ci-dessus, associée à une formation régulière des employés aux risques d’ingénierie sociale, constitue la meilleure défense.
En 2026, alors que les attaques s’appuient sur des outils légitimes, la vigilance et la rigueur de configuration restent vos alliées les plus fiables. Ne laissez pas un compte non couvert devenir la porte d’entrée vers vos données les plus critiques.