Les dMSAs sont la nouvelle cible de l'escalade des privilèges AD — Voici ce que vous devez savoir

Introduction

Windows Server 2025 a introduit des comptes de service gérés délégués (dMSAs) pour améliorer la sécurité en liant l'authentification des services aux identités des appareils. Mais les attaquants ont déjà trouvé un moyen de détourner cette nouvelle fonctionnalité en une technique d'escalade de privilèges dangereuse.

L'attaque BadSuccessor permet aux adversaires d'usurper l'identité de n'importe quel utilisateur — même les administrateurs de domaine — sans déclencher d'alertes traditionnelles. Voici comment cela fonctionne, pourquoi c'est si discret et ce que vous pouvez faire pour rester en avance sur cette menace.

Comprendre les dMSAs et leur rôle dans Active Directory

Comment les dMSAs diffèrent des gMSAs

• Un dMSA (delegated managed service account) fonctionne comme un compte de service mais est lié à l'identité d'une seule machine. Contrairement aux gMSAs, qui sont gérés de manière centralisée et peuvent fonctionner sur plusieurs serveurs, les dMSAs héritent des privilèges de l'appareil sur lequel ils sont créés.

Cette portée plus restreinte améliore la sécurité en théorie — mais elle crée également de nouveaux risques lorsque les dMSA sont migrés depuis des comptes hérités.

Ce qu'il faut savoir sur la migration vers les dMSAs

Un dMSA peut être créé en tant que compte autonome. Alternativement, il peut être créé en remplacement d'un compte de service utilisateur traditionnel existant (pas un compte de service géré ou un gMSA) par le biais d'une migration. Cela se fait généralement à l'aide de l'applet de commande PowerShell Start-ADServiceAccountMigration, qui déclenche l'opération MigrateADServiceAccount LDAP RootDSE. Deux attributs clés sont définis dans le cadre de ce processus :

• msDS-ManagedAccountPrecededByLink — Indique le compte utilisateur d'origine
• msDS-DelegatedMSAState — Indique l'état de la migration (par exemple, prêt ou terminé)

À la fin du processus de migration, le compte de service hérité est désactivé mais doit rester dans Active Directory. S'il est supprimé, le dMSA ne fonctionnera plus car de nombreux services et configurations font encore référence au compte original. Les attaquants ciblent ces attributs dans la technique BadSuccessor, ce qui les rend critiques pour la surveillance.

Comment les attaquants peuvent abuser d'un dMSA pour l'escalade de privilèges dans Active Directory

Techniques traditionnelles d'escalade des privilèges

Les recherches dans le monde réel révèlent que l'escalade des privilèges est souvent la deuxième phase d'attaque après l'accès initial. Une fois que les adversaires prennent le contrôle d'un compte utilisateur, ils recherchent des voies qui leur permettent d'augmenter systématiquement leurs privilèges, dans le but d'obtenir finalement les droits d'Admin Domaine.

Les techniques traditionnelles d'escalade de privilèges répertoriées dans le catalogue MITRE ATT&CK incluent le Kerberoasting, le AS?REP Roasting et la création de Golden Ticket. De plus, les attaquants utilisent aujourd'hui souvent des outils comme BloodHound pour cartographier les chemins d'escalade de privilèges, ce qui implique de tirer parti de problèmes tels que les mauvaises configurations, les permissions héritées ou les défauts de conception pour obtenir des permissions de haut niveau.

Élévation de privilèges en utilisant des dMSAs

L'introduction des dMSAs offre aux adversaires une autre option pour l'escalade de privilèges, non pas parce que les dMSAs sont intrinsèquement peu sûrs, mais parce que les attaquants peuvent exploiter la manière dont ils sont liés aux comptes de service hérités. En modifiant des attributs comme msDS-ManagedAccountPrecededByLink, un dMSA peut être configuré pour se faire passer pour un autre utilisateur et hériter de l'accès de ce compte. Par conséquent, ces droits peuvent être exploités sans changer les adhésions à des groupes ou compromettre des identifiants supplémentaires. En conséquence, même des piles de sécurité sophistiquées peuvent manquer ce vecteur d'attaque si elles se fient uniquement à la surveillance des ID d'événement traditionnels ou au suivi de l'attribution de privilèges.

Un facteur de risque courant est la délégation inappropriée du contrôle sur les unités organisationnelles (OUs). Si un attaquant compromet un compte utilisateur avec les droits CreateChild ou WriteProperty sur une OU, il peut potentiellement créer un dMSA qui hérite des privilèges au niveau du domaine. Akamai a découvert que 91 % des environnements analysés avaient au moins une OU où les comptes utilisateurs avaient suffisamment de permissions pour exploiter cette technique.

L'attaque BadSuccessor et pourquoi elle est si dangereuse

BadSuccessor est un nouveau vecteur d'attaque qui abuse des attributs de migration dMSA. En modifiant l'attribut msDS-ManagedAccountPrecededByLink, un attaquant peut faire en sorte qu'un dMSA se fasse passer pour un compte privilégié.

Le Kerberos Key Distribution Center émet alors des tickets comme si le dMSA était cet utilisateur privilégié — aucun changement de groupe, aucun événement de connexion évident. En d'autres termes, les attaquants obtiennent un accès de niveau administrateur qui semble tout à fait légitime.

Aggravant le problème, les attaques BadSuccessor peuvent être très difficiles à détecter. Il n'y a pas de changements de groupe et aucune activité de connexion de la part du compte utilisateur usurpé. Bien que Microsoft fournisse maintenant des journaux pour les changements d'attributs pertinents dans le schéma Windows 2025 (version 91), la plupart des outils d'audit ne sont pas encore configurés pour les signaler. En bref, cette technique passera probablement inaperçue si les outils de détection ne recherchent pas spécifiquement des configurations dMSA anormales ou un comportement d'usurpation dans les demandes de ticket Kerberos. L'examen médico-légal est également délicat, car le nom du dMSA pourrait ne pas refléter le niveau de privilège approprié sous lequel il opère.

En plus de permettre l'escalade de privilèges, les attaques BadSuccessor peuvent permettre aux adversaires d'obtenir un accès à long terme à l'environnement, connu sous le nom de persistance. La persistance est cruciale pour les acteurs de la menace persistante avancée (APT). Dans AD, les techniques de persistance avancées sont celles qui survivent aux réinitialisations de mot de passe, aux cycles de redémarrage et aux efforts de remédiation standards. L'attaque BadSuccessor remplit certainement ces conditions : une fois qu'un dMSA est configuré en mode de migration avec un compte succédé et des tickets Kerberos émis, il peut continuer à fonctionner même si le compte original est désactivé. En d'autres termes, les dMSAs abusés de cette manière fournissent une « porte dérobée avec un badge » — un compte qui semble légitime, demande des tickets Kerberos comme tout compte de service normal et opère dans le cadre de privilèges définis.

Meilleures pratiques pour se défendre contre l'abus de dMSA

Une défense robuste contre l'abus des dMSAs pour l'escalade des privilèges nécessite une stratégie à plusieurs niveaux couvrant à la fois la prévention et la détection. Les meilleures pratiques clés comprennent les suivantes :

• Révisez les permissions. Auditez régulièrement qui possède les droits CreateChild, WriteProperty, WriteDACL (Modifier les Permissions), Generic All (Contrôle Total), et WriteOwner (Changer le Propriétaire) sur tous les OUs et appliquez rigoureusement le principe du moindre privilège pour réduire votre surface d'attaque.
• Formez les équipes. Assurez-vous que tous les administrateurs AD comprennent le fonctionnement des dMSAs et les risques associés.
• Restez informé. Alors que Microsoft continue d'améliorer la fonctionnalité dMSA, les équipes de sécurité doivent rester en contact avec la documentation officielle et les recherches de la communauté pour comprendre les risques émergents. Des ressources telles que la documentation dMSA de Microsoft et les dernières analyses de SpecterOps sur les atténuations de BadSuccessor fournissent des conseils précieux.
• Surveillez les changements. Les indicateurs traditionnels de compromission (IoC) tels que les échecs de connexion sont insuffisants pour détecter les attaques dMSA telles que BadSuccessor. Les organisations ont besoin d'outils de surveillance en temps réel capables de signaler les modifications apportées aux attributs liés au dMSA. Une approche robuste comprend :
  • Établir une base de référence des dMSAs légitimes et de leurs comportements attendus
  • Surveillance de la création ou modification inattendue de dMSAs
  • Surveillance de l'émission de tickets Kerberos pour les dMSAs
  • Reviewing dMSA migration logs, now available in recent Windows Server builds — see Microsoft’s guide to dMSA event logging
• Adoptez une stratégie Zero Trust. Plus largement, intégrez la sécurité dMSA dans une initiative Zero Trust plus globale. Traitez les dMSA comme des identités à haute valeur, et non seulement comme des comptes d'infrastructure. Mettez en œuvre les mêmes contrôles que ceux utilisés pour les comptes administratifs, y compris l'application stricte du principe de moindre privilège, l'analyse de l'activité d'authentification et la surveillance continue du comportement.

Outils pour une détection et une défense efficaces

Netwrix Identity Threat Detection & Response offre une protection complète contre les attaques d'escalade de privilèges basées sur dMSA grâce à des outils de sécurité intégrés qui travaillent ensemble pour évaluer, prévenir et détecter les menaces :

Comment Netwrix arrête les attaques BadSuccessor

• Trouvez rapidement les UO à risque : Netwrix PingCastle identifie où les utilisateurs ont des droits de création de dMSA dangereux, afin que vous puissiez les corriger avant que les attaquants ne frappent.
• Bloquez les exploits en temps réel : Netwrix Threat Prevention arrête les modifications non autorisées des attributs dMSA — coupant ainsi les attaques BadSuccessor à la source.
• Détectez ce que les autres ne voient pas : Netwrix Threat Manager surveille les tickets Kerberos et les migrations dMSA pour détecter les signes d'usurpation d'identité, vous alertant avant que les attaquants n'élèvent leurs privilèges.

Ensemble, ces outils vous offrent visibilité, contrôle et défense automatisée contre les techniques d'escalade de privilèges discrètes telles que BadSuccessor.

Conclusion

Le compte de service géré délégué est une puissante nouvelle fonctionnalité de Windows Server qui peut améliorer à la fois la sécurité et la gestion. Cependant, les attaquants peuvent utiliser le dMSA pour une élévation de privilèges dans Active Directory. En effet, la découverte de BadSuccessor souligne la nécessité de mettre en œuvre de nouvelles capacités avec la diligence requise, y compris disposer d'une suite d'outils éprouvés pour assurer à la fois une forte posture de sécurité et une détection rapide des menaces.

FAQ sur dMSA pour l'escalade de privilèges dans Active Directory

Qu'est-ce que l'attaque BadSuccessor ?

BadSuccessor est une technique qui exploite un dMSA pour l'escalade de privilèges dans Active Directory. Elle peut permettre à un compte contrôlé par un attaquant d'usurper l'identité d'autres utilisateurs dans Active Directory, y compris des utilisateurs privilégiés.

Comment fonctionne l'attaque BadSuccessor ?

Un attaquant crée ou modifie un dMSA, en définissant ses attributs de migration pour référencer un utilisateur privilégié. En conséquence, le KDC émet des tickets Kerberos qui accordent au dMSA ces privilèges élevés, permettant une usurpation d'identité discrète.

Pourquoi tant d'environnements sont-ils vulnérables ?

Selon Akamai, 91 % des environnements AD réels avaient au moins une unité organisationnelle où les utilisateurs non privilégiés disposaient des permissions CreateChild ou Write — suffisantes pour réaliser la technique BadSuccessor.

Que peuvent faire les organisations pour atténuer leurs risques ?

Les meilleures pratiques pour atténuer les risques incluent la limitation des permissions CreateChild et Write sur les unités organisationnelles, la surveillance continue des modifications apportées aux attributs dMSA, et l'identification proactive ainsi que la correction des configurations à risque.

Microsoft prévoit-il de corriger cela ?

Microsoft a classé le problème de l'utilisation de dMSA pour l'escalade de privilèges dans Active Directory comme étant de gravité modérée. Bien qu'un correctif puisse être développé, il est judicieux pour les organisations d'adopter immédiatement des stratégies robustes de prévention et de détection des menaces.