Attaque AD CS : comment les pirates usurpent le support IT via Microsoft Teams

Une attaque AD CS silencieuse mais redoutable a été mise en lumière par Microsoft en novembre 2026. En se faisant passer pour le service d’assistance informatique via Microsoft Teams, des pirates ont obtenu des certificats leur permettant de se connecter à des comptes privilégiés, dont celui d’un contrôleur de domaine. Ces intrusions, qui reposent sur l’ingénierie sociale et des configurations AD CS défaillantes, montrent que la sécurité des infrastructures Windows ne tient qu’à un fil. Voici comment ces attaques fonctionnent et, surtout, comment vous pouvez les contrer.

Comment l’attaque commence : le piège du faux support technique

L’intrusion débute toujours par un contact sur Microsoft Teams. L’attaquant, se faisant passer pour un membre du service IT ou du help desk de l’entreprise ciblée, envoie un message ou passe un appel. Pour rendre le contact crédible, il utilise un locataire Teams externe dont le nom évoque le support (par exemple « IT-Help », « Support-Tech »). La victime, habituée à solliciter ce type d’assistance, abaisse naturellement sa garde.

L’assaillant demande alors à l’employé d’ouvrir Quick Assist, un outil d’aide à distance intégré à Windows. La personne lit le code de connexion à voix haute, ce qui donne à l’attaquant un contrôle total et direct du poste de travail. Cette étape ne nécessite aucun logiciel supplémentaire ni contournement de pare-feu : tout repose sur la confiance.

Une fois la session établie, le pirate dépose une archive dans le dossier Downloads de l’utilisateur. Il la décompresse dans un dossier dont le nom imite une mise à jour Windows (par exemple « WindowsUpdate »). Le contenu est exécuté à l’aide d’un environnement portable Python, Bun ou Java. Les noms de fichiers, même renommés, conservent souvent les versionnements des exécutables d’origine, ce qui rend leur détection difficile.

Voici les étapes clés de cette phase initiale :

1. Appel Teams d’un faux support IT.
2. Demande d’ouverture de Quick Assist.
3. Lecture du code de connexion par l’employé.
4. Prise de contrôle à distance du poste.
5. Dépose et exécution d’un script malveillant.

« Aucun correctif n’est nécessaire car il ne s’agit pas d’une faille logicielle. » - Microsoft

L’exploitation des certificats AD CS : ESC1 et ESC8

Active Directory Certificate Services (AD CS) est le service chargé de délivrer les certificats utilisés par les comptes et les ordinateurs lors de l’authentification dans un domaine Windows. Un certificat issu d’un modèle mal configuré permet à son détenteur de se connecter comme le compte qu’il désigne. Microsoft précise qu’un tel certificat continue de fonctionner même après la réinitialisation du mot de passe ou le nettoyage de la machine initiale.

Deux vulnérabilités de configuration sont exploitées dans ces attaques :

Pour l’ESC8, la technique PetitPotam (divulguée en 2021) force le contrôleur de domaine à s’authentifier sur une machine contrôlée par l’attaquant. Le challenge NTLM est ensuite relayé vers le serveur AD CS via une requête HTTP sans mot de passe. Avec le certificat obtenu, l’assaillant utilise PKINIT pour demander un ticket-granting ticket Kerberos, transformant une authentification unique en identité persistante.

Deux cas concrets d’intrusion analysés par Microsoft

Cas n°1 - ESC1 et exclusion partielle

Dans la première intrusion, les attaquants ont identifié un modèle de certificat présentant la faiblesse ESC1. Une première vague a ciblé trois utilisateurs et un poste de travail, produisant des certificats pour trois comptes hautement privilégiés. La réponse automatique de Microsoft Defender a coupé ces identités et mis fin à leurs sessions actives. Un seul compte privilégié avait été omis de la réponse automatique, ce qui l’a laissé utilisable.

Environ 90 minutes plus tard, une seconde vague a touché seize utilisateurs et un deuxième poste, générant des certificats pour huit autres comptes privilégiés. Microsoft indique que plus de 1 000 tentatives de connexion ultérieures (via SMB ou authentification) ont été bloquées. Cependant, dans les secondes suivant l’obtention du certificat, l’attaquant s’est connecté au contrôleur de domaine et a lancé DCSync pour copier les mots de passe Active Directory. L’exclusion d’un seul compte a permis à l’attaque de se poursuivre : le pirate a utilisé ce compte pour accéder à un serveur de fichiers et exécuter une copie renommée de Rclone, transférant des données vers un serveur SFTP externe.

Selon Microsoft, « l’intégration partielle des identités peut réduire l’activité malveillante tout en laissant une voie privilégiée viable. »

Ce cas illustre le danger d’une réponse automatique incomplète : une simple omission peut compromettre l’ensemble de la défense.

Cas n°2 - ESC8 stoppée par l’isolation

La seconde intrusion a emprunté une voie différente car le modèle ESC1 n’était pas présent. L’assaillant a utilisé PetitPotam pour forcer le contrôleur de domaine à s’authentifier sur une machine contrôlée, puis a relayé cette authentification NTLM vers l’interface web AD CS (ESC8). Il a ainsi obtenu un certificat pour le contrôleur de domaine lui-même. Avec ce certificat et PKINIT, il a récupéré un TGT pour le contrôleur de domaine.

Cette fois, la réponse a été rapide : Microsoft Defender a généré une alerte spécifique à ESC8, le client a isolé le poste de travail concerné, et aucune activité malveillante n’a été observée par la suite. La différence avec le premier cas tient à la réactivité du containment : isoler un seul poste a suffi à stopper l’attaque.

Pourquoi les mesures de sécurité classiques ne suffisent pas

Ces attaques ne laissent aucune trace dans les logs de changement de mot de passe, car le certificat reste valide indépendamment du secret. Réinitialiser le mot de passe d’un compte compromis ne révoque pas le certificat obtenu. De même, formater la machine initiale n’empêche pas l’utilisation du certificat depuis un autre poste. L’attaque ne repose sur aucun bug logiciel : elle exploite des choix de configuration légitimes mais dangereux.

En France, où l’adoption de Microsoft Teams est massive dans les entreprises et les administrations, ce type de menace est particulièrement préoccupant. L’ANSSI rappelle régulièrement que la sécurité des annuaires Active Directory passe par un durcissement des services de certificats et une sensibilisation des utilisateurs aux risques d’ingénierie sociale.

Recommandations pour sécuriser votre AD CS

Microsoft et les experts en cybersécurité convergent sur une série de mesures concrètes. En voici les plus importantes :

• Vérifier les demandes de support : tout contact non sollicité via Teams doit être confirmé par un canal interne (téléphone, email séparé) avant d’accepter une assistance à distance.
• Limiter les locataires Teams externes : n’autoriser que les tenants approuvés pour les appels entrants, et bloquer ceux dont le nom évoque le support sans validation.
• Auditer les modèles de certificats : rechercher ceux qui permettent au demandeur de renseigner le sujet (ESC1) et restreindre les droits d’inscription aux seuls administrateurs légitimes.
• Activer HTTPS et EPA (Extended Protection for Authentication) sur les points d’inscription web AD CS, comme le décrit la note Microsoft KB5005413. Désactiver l’authentification NTLM sur ces endpoints lorsque c’est possible.
• Activer l’audit des certificats : surveiller toute délivrance suspecte. En cas de certificat malveillant, le révoquer, mais aussi vérifier les tickets Kerberos déjà émis, car la révocation ne les invalide pas.
• Traiter les exclusions manuellement : tout compte laissé de côté par une réponse automatique doit faire l’objet d’une action dédiée (désactivation, rotation de secrets, surveillance renforcée).
• Appliquer les configurations de durcissement : les serveurs Windows 2025 activent EPA par défaut, mais les versions 2019 et 2022 nécessitent une activation manuelle.

Indicateurs de compromis (IoCs)

Microsoft a publié trois empreintes SHA-256 liées aux scripts initial-access utilisés dans ces attaques :

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

Ces signatures peuvent être intégrées à vos outils de détection (SIEM, EDR) pour identifier des artefacts similaires.

Exemple d’application en contexte français

Imaginons une PME française spécialisée dans les services financiers, utilisant Active Directory pour gérer les accès à son système de cotation. Un employé du service comptabilité reçoit un appel Teams d’un pseudo-support IT. Pensant répondre à une sollicitation légitime, il partage son écran via Quick Assist. L’attaquant, après avoir pris le contrôle, exploite un modèle de certificat AD CS laissé ouvert pour obtenir un certificat au nom du responsable financier. En quelques minutes, l’accès aux fichiers sensibles est compromis. Sans les mesures listées ci-dessus, cette PME pourrait subir une exfiltration comparable au premier cas décrit par Microsoft.

Conclusion : l’humain reste le maillon faible, mais la technique peut être verrouillée

Cette attaque AD CS montre que la sécurité ne se limite pas à l’absence de failles logicielles. L’ingénierie sociale combinée à des configurations laissées ouvertes crée une vulnérabilité redoutable. Les deux cas analysés par Microsoft le prouvent : un seul oubli - un compte exclu d’une réponse automatique, un modèle de certificat trop permissif - peut suffire à compromettre un domaine entier. Toutefois, les mesures défensives existent et sont efficaces. En auditant vos modèles de certificats, en durcissant vos points d’inscription AD CS et en formant vos équipes à identifier les demandes de support frauduleuses, vous réduisez considérablement le risque.

Menez dès maintenant un audit de vos modèles de certificats et sensibilisez vos collaborateurs à ces nouvelles techniques d’usurpation. La résilience de votre Active Directory en dépend.