Les attaquants abusent d'AD CS et du social engineering sur Teams pour voler des données

Microsoft a détaillé deux incidents de sécurité distincts dans lesquels des acteurs malveillants ont usurpé l'identité du personnel interne du support informatique sur Microsoft Teams afin de prendre le contrôle à distance des postes de travail des employés. En exploitant une configuration incorrecte de Active Directory Certificate Services (AD CS), les attaquants ont émis des certificats de connexion frauduleux pour des comptes privilégiés, leur permettant de contourner les contrôles d'authentification standard et d'exfiltrer les données de l'entreprise dans un cas.

Ce qui s'est passé

Les intrusions ont commencé par une campagne de social engineering plutôt que par une exploitation technique de vulnérabilités logicielles. Les attaquants ont contacté les employés via Microsoft Teams, utilisant des locataires externes dont les noms étaient conçus pour imiter les rôles du service d'assistance ou du support informatique interne. Ils ont convaincu leurs cibles d'utiliser Quick Assist, un outil intégré de prise en charge à distance Windows, en leur demandant de lire à voix haute les codes de connexion. Cela a accordé aux attaquants un contrôle direct et manuel sur la machine de la victime.

Une fois à l'intérieur, les attaquants ont déployé des scripts d'accès initial déguisés en mises à jour Windows. Ces scripts s'exécutaient à l'aide d'environnements d'exécution portables comme Python, Bun ou Java, rendant la détection par nom de fichier seule difficile. L'objectif principal n'était pas seulement l'accès au poste de travail, mais l'exploitation de cet accès pour interagir avec l'infrastructure de certificats de l'organisation. AD CS émet les certificats numériques que les utilisateurs et les ordinateurs présentent pour prouver leur identité lors de la connexion. Si ce système est mal configuré, un attaquant peut demander des certificats qui lui accordent les privilèges de comptes à haute valeur, tels que les contrôleurs de domaine.

Dans le premier cas, les attaquants ont exploité une faiblesse de modèle connue sous le nom d'ESC1, qui leur permettait de spécifier l'identité du compte dans la demande de certificat. Ils ont obtenu des certificats pour plusieurs comptes privilégiés. Bien que Microsoft Defender ait automatiquement perturbé la plupart de ces identités, un compte privilégié a été exclu de la réponse automatique. Les attaquants ont utilisé cet accès restant pour exécuter DCSync, un outil qui copie les hachages de mots de passe depuis Active Directory, puis ont utilisé Rclone pour déplacer les données vers un serveur SFTP externe. Dans le second cas, les attaquants ont utilisé une technique appelée PetitPotam pour forcer un contrôleur de domaine à s'authentifier auprès de leur machine, relayant cette information d'identification pour obtenir un certificat pour le contrôleur de domaine lui-même. Cette tentative a été contenue après que le client a isolé le poste de travail compromis.

Détails clés

• Les attaquants ont utilisé le social engineering sur Microsoft Teams pour tromper les utilisateurs et les inciter à partager le contrôle à distance via Quick Assist.
• Aucune faille logicielle n'a été exploitée ; les attaques reposaient sur des configurations AD CS non sécurisées et la manipulation des utilisateurs.
• Dans le premier incident, un compte privilégié exclu a permis aux attaquants de contourner le confinement automatique et d'exfiltrer des données.
• Les attaquants ont utilisé les techniques ESC1 et ESC8 pour émettre des certificats pour des comptes très privilégiés et des contrôleurs de domaine.
• Microsoft Defender a bloqué plus de 1 000 tentatives de connexion ultérieures dans le premier cas, mais un confinement partiel a laissé une voie d'attaque viable.
• La nouvelle version Windows Server 2025 active la protection étendue pour l'authentification (EPA) par défaut, réduisant l'exposition aux attaques ESC8.

Contexte

Active Directory Certificate Services (AD CS) est un rôle de serveur Windows qui gère l'infrastructure à clé publique (PKI) d'une organisation. Il émet des certificats numériques qui vérifient l'identité des utilisateurs, des ordinateurs et des services. Lorsqu'il est configuré de manière sécurisée, il constitue un mécanisme d'authentification robuste. Cependant, des configurations incorrectes spécifiques, telles que celles désignées ESC1 et ESC8 par les chercheurs, peuvent permettre aux attaquants d'abuser du système. ESC1 permet à un utilisateur à faible privilège de demander un certificat pour n'importe quel autre compte, escaladant ainsi effectivement ses privilèges. ESC8 implique le relais de l'authentification NTLM vers la page d'inscription web AD CS pour obtenir un certificat sans connaître le mot de passe.

Ces vulnérabilités ne sont pas nouvelles ; elles ont été divulguées en 2021. Cependant, elles nécessitent des modifications proactives de configuration pour être atténuées. Contrairement à un bug logiciel qui peut être corrigé par un correctif, ces problèmes découlent de la façon dont les administrateurs configurent les modèles de certificats et les politiques d'inscription. Si un attaquant obtient un certificat valide pour un compte privilégié, ce certificat reste valide même si le mot de passe du compte est réinitialisé ou si la machine compromise initiale est effacée, fournissant un accès persistant.

Pourquoi c'est important

Pour les équipes qui gèrent leur propre infrastructure, en particulier celles qui dépendent de Windows Server et d'Active Directory, ce rapport met en évidence un fossé critique entre la défense automatisée et la configuration manuelle. Les outils automatisés comme Microsoft Defender peuvent détecter et perturber de nombreux vecteurs d'attaque, mais ils reposent sur des règles prédéfinies. Si un administrateur exclut explicitement un compte des politiques de confinement automatique, peut-être pour éviter de perturber un service critique, cette décision peut créer un angle mort. Les attaquants recherchent activement ces exceptions, comme on l'a vu dans le premier cas où un seul compte exclu a permis un vol de données significatif.

De plus, la dépendance au social engineering souligne que les contrôles techniques seuls sont insuffisants. Même avec une segmentation réseau robuste et une protection des points de terminaison, un seul employé trompé et accordant un accès à distance peut contourner les défenses périmétriques. L'utilisation d'outils légitimes comme Quick Assist et d'environnements d'exécution portables rend ces activités plus difficiles à distinguer du travail administratif normal. Les organisations doivent donc équilibrer le durcissement technique d'AD CS avec des contrôles procéduraux stricts pour les demandes de support à distance.

Ce que vous pouvez faire

• Vérifiez toutes les demandes de support inattendues via un canal interne connu et séparé avant d'accorder un accès à distance ou de partager des écrans.
• Restreignez les locataires externes Microsoft Teams qui peuvent contacter vos employés et limitez les outils de support à distance aux applications approuvées uniquement.
• Auditez les modèles de certificats AD CS pour supprimer les droits d'inscription pour les utilisateurs qui n'en ont pas besoin et désactivez les modèles qui permettent aux demandeurs de spécifier le nom du sujet.
• Activez la protection étendue pour l'authentification (EPA) sur les points de terminaison d'inscription web AD CS et désactivez NTLM lorsque cela est possible pour prévenir les attaques ESC8.
• Mettez en œuvre l'audit des certificats et assurez-vous que tout compte exclu du confinement automatique dispose d'un processus de surveillance manuelle correspondant.
• Examinez les tickets Kerberos actifs séparément lors de la révocation des certificats, car la révocation n'invalide pas automatiquement les tickets existants.