BadSuccessor : exploiter les dMSA pour élever les privilèges dans Active Directory
Synthèse
Yuval Gordon, chercheur chez Akamai, a découvert une vulnérabilité d'élévation des privilèges dans Windows Server 2025 qui permet aux attaquants de compromettre n'importe quel utilisateur dans Active Directory (AD).
L'attaque exploite la fonction de compte de service géré délégué (dMSA) introduite dans Windows Server 2025, fonctionne avec la configuration par défaut et est facile à mettre en œuvre.
Ce problème affecte probablement la plupart des entreprises qui utilisent AD. Dans 91 % des environnements que nous avons examinés, nous avons constaté que des utilisateurs en dehors du groupe d'administrateurs de domaine avaient les autorisations requises pour réaliser cette attaque.
Bien que Microsoft indique que ce problème devrait être résolu à l'avenir, aucun correctif n'est actuellement disponible. Par conséquent, les entreprises doivent prendre d'autres mesures proactives pour réduire leur exposition à cette attaque. Microsoft a examiné nos conclusions et a approuvé la publication de ces informations.
Dans cet article de blog, nous fournissons des détails complets sur l'attaque, ainsi que des stratégies de détection et d'atténuation.
Contenu
Introduction
Dans Windows Server 2025, Microsoft a introduit des comptes de services gérés délégués (dMSA). Un dMSA est un nouveau type de compte de service dans Active Directory (AD) qui étend les capacités des comptes de service gérés par groupe (gMSA). L'une des principales fonctionnalités des dMSA est la possibilité de migrer les comptes de service non gérés existants en les convertissant en dMSA de manière fluide.
Nous avons fait une découverte intéressante en explorant les mécanismes internes des dMSA d'AD. À première vue, le mécanisme de migration semblait être une solution épurée et bien conçue. Mais quelque chose dans son fonctionnement interne a attiré notre attention.
En creusant davantage, nous avons découvert une voie d'élévation surprenante : en exploitant les dMSA, les attaquants peuvent prendre le contrôle de n'importe quel principal dans le domaine. Pour utiliser cette méthode, un attaquant n'a besoin que d'une autorisation bénigne sur toute unité organisationnelle (OU) du domaine, qui reste souvent non détectée.
Et, cerise sur le gâteau, l'attaque fonctionne par défaut : votre domaine n'a pas du tout besoin d'utiliser de dMSA. Tant que la fonctionnalité existe, ce qui est le cas dans tout domaine avec au moins un contrôleur de domaine Windows Server 2025, elle devient disponible.
Dans cet article de blog, nous vous expliquons comment nous avons découvert cette attaque, comment elle fonctionne et ce que vous pouvez faire pour la détecter ou la prévenir.
Qu'est-ce qu'un dMSA ?
Avant de nous pencher sur les attaques, il est important de comprendre ce que sont réellement les dMSA et comment ils sont censés fonctionner.
Un dMSA est généralement créé pour remplacer un compte de service existant. Pour permettre une transition fluide, un dMSA peut « hériter » des autorisations du compte existant en effectuant un processus de migration. Ce flux de migration associe étroitement le dMSA au compte remplacé, c'est-à-dire le compte d'origine qu'il est censé remplacer. C'est ce flux, et les autorisations qu'il accorde, qui nous intéresse particulièrement.
Flux de migration dMSA
Le processus de migration d'un dMSA peut être déclenché en appelant la nouvelle cmdlet Start-ADServiceAccountMigration. En interne, il appelle une nouvelle opération LDAP rootDSE nommée migrateADServiceAccount, qui prend les arguments suivants :
Nom unique (DN, Distinguised Name) du dMSA
DN du compte remplacé
Constante correspondant à StartMigration
L'état de migration d'un dMSA est dicté par l'attribut msDS-DelegateMSAState, un nouvel attribut qui détermine l'état actuel du dMSA. Il n'existe actuellement aucune documentation officielle sur l'attribut mSDS-DelegateMSAState. Le tableau suivant est donc basé sur nos propres analyse comportementale et expérimentation.
Valeur |
Signification |
0 |
Inconnu (peut-être désactivé, mais non confirmé) |
1 |
Migration en cours |
2 |
Migration terminée |
3 |
dMSA autonome (pas de migration) |
Valeurs de migration msDS-DelegatedMSAState et leur signification
En plus de cet attribut, d'autres attributs sont notamment utilisés pendant le processus de migration.
Sur l'objet dMSA :
msDS-GroupMSAMembership : Contient une liste des entités de sécurité autorisées à utiliser ce dMSA
msDS-ManagedAccountPrecededByLink : DN du compte remplacé
Sur l'objet de compte remplacé :
msDS-SupersededManagedAccountLink : DN du dMSA « suivant »
msDS-SupersededServiceAccountState : signifie la même chose que msDS-DelegatedMSAState, qui indique l'état de migration du compte d'origine
Lors du déclenchement d'une migration, l'opération effectue les modifications suivantes :
Définit msDS-DelegatedMSAState sur 1 (migration en cours)
Met à jour l'attribut ntSecurityDescriptor du dMSA pour accorder au compte remplacé :
Des autorisations de lecture
Accès en écriture à l'attribut msDS-GroupMSAMembership
Définit l'attribut msDS-ManagedAccountPrecededByLink du dMSA pour faire référence au compte remplacé
Définit l'attribut msDS-SupersededManagedAccountLink du compte remplacé pour faire référence au dMSA
Définit l'attribut msDS-SupersededServiceAccountState du compte remplacé sur 1
À ce stade, le dMSA est à l'état « migration en cours ». Il n'est pas encore entièrement fonctionnel, mais il sait désormais quels systèmes utilisent encore l'ancien compte de service.
Une fois la commande Complete-ADServiceAccountMigration émise, les événements suivants se produisent :
Le dMSA hérite des configurations clés telles que les SPN, les paramètres de délégation et d'autres attributs sensibles du compte remplacé
Le compte remplacé est désactivé
msDS-DelegateMSAState et msDS-SupersededServiceAccountState sont tous deux définis sur 2 (migration terminée)
La migration est terminée et tout service qui s'appuie sur le compte remplacé utilisera désormais le dMSA pour l'authentification.
Authentification dMSA
Maintenant que nous comprenons le processus de création et de migration des dMSA, il est temps de nous concentrer sur le fonctionnement de l'authentification, les modifications introduites pour prendre en charge les dMSA et la manière dont ces modifications rendent le processus de migration fluide.
Pour une meilleure compréhension, examinons le compte de service svc_sql legacy, qui est utilisé pour exécuter un service sur le serveur SQL_SRV$. Chaque fois que le service est requis pour accéder aux ressources du domaine, l'authentification normale est effectuée à l'aide du compte svc_sql (Figure 1).
Fig. 1: Legacy service account authentication flow
Authentification lors de la migration
Nous procédons maintenant à la transition du compte de service vers un nouveau dMSA appelé DMSA$ et nous déclenchons une migration. Pendant la période de migration, lorsque le service sur SQL_SRV$ s'authentifie en tant que svc_sql, le flux d'authentification est légèrement modifié.
Le client envoie un AS-REQ pour s'authentifier en tant que svc_sql.
Le Centre de distribution des clés (KDC) renvoie un fichier AS-REP contenant un champ supplémentaire : KERB-SUPERSEDED-BY-USER (ce champ comprend le nom et la sphère du nouveau dMSA DMSA$)
Si l'hôte prend en charge les dMSA (Windows Server 2025 ou Windows 11 24H2) et que l'authentification dMSA est activée, il pourra :
Extrayez le nom DMSA$
Exécutez une requête LDAP sur DMSA$ pour récupérer les attributs suivants :
msDS-GroupMSAMembership
distinguishedName
objectClass
Étant donné que le service s'exécute sur SQL_SRV$ en tant que svc_sql, l'authentification déclenche elle-même une demande de modification LDAP de svc_sql, qui ajoute SQL_SRV$ à la liste des principaux autorisés à récupérer le mot de passe de DMSA$ (Figure 2).
Cela est possible car, pendant le processus de migration, svc_sql a obtenu un accès en écriture à l'attribut msDS-GroupMSAMembership sur le dMSA, une modification qui lui permet d'autoriser son ordinateur hôte à accéder aux informations d'identification du compte.
Fig. 2: Kerberos authentication flow during dMSA migration
Cette attribution fluide d'autorisation garantit qu'à la fin de la migration, toutes les machines qui utilisaient auparavant svc_sql seront répertoriées dans l'attribut msDS-GroupMSAMembership de DMSA$, ce qui lui permet de s'authentifier en tant que dMSA.
Authentification après la fin de la migration
Une fois la migration terminée (via Complete-ADServiceAccountMigration), le comportement change à nouveau.
Lorsque le client tente de s'authentifier en tant que svc_sql en envoyant une requête AS-REQ, il ne reçoit plus de réponse AS-REP.
Au lieu de cela, le DC répond avec une erreur KRB-ERROR, indiquant que svc_sql est désactivé.
Le message d'erreur KRB-ERROR contient le champ KERB-SUPERSEDED-BY-USER, ce qui permet au client de reconnaître que svc_sql a été migré et de réessayer automatiquement l'authentification en utilisant DMSA$ (Figure 3).
Fig. 3: Kerberos authentication flow after the dMSA migration is completed
SQL_SRV$ (et toute autre machine qui dépendait auparavant de svc_sql) passera désormais automatiquement à DMSA$.
Comportement UnexPACted
Un aspect intéressant de l'authentification dMSA Kerberos concerne son Privilege Attribute Certificate (PAC).
Lors de l'authentification, Kerberos intègre un PAC dans les tickets, une structure que les services utilisent pour déterminer le niveau d'accès d'un client. Dans un ticket d'octroi de ticket (TGT, Ticket Granting Ticket) standard, le PAC inclut les SID des utilisateurs et de tous les groupes dont ils font partie.
Cependant, lorsque nous nous connectons avec un dMSA, nous avons observé quelque chose d'inattendu.
Le PAC comprenait non seulement le SID des dMSA, mais également les SID du compte de service remplacé et de tous ses groupes associés.
Exploiter le processus de migration dMSA pour élever les privilèges
Après la migration, le KDC accorde au dMSA toutes les autorisations du compte d'origine (remplacé).
Du point de vue de la conception, c'est logique. L'objectif est de fournir une expérience de migration fluide, et que le nouveau compte se comporte comme celui qu'il remplace : mêmes SPN, mêmes délégations, appartenance aux mêmes groupes.
Mais du point de vue d'un chercheur en sécurité, ce type de comportement se démarque immédiatement. Lorsque nous avons vu un système qui copie automatiquement les privilèges d'un compte à un autre, sans nécessiter de reconfiguration manuelle, nous avons commencé à nous poser les questions suivantes : Comment le service informatique choisit-il le compte à copier ? Ce choix peut-il être influencé ? Peut-il être utilisé de manière abusive ?
Cette ligne de questions nous a directement conduits à une découverte clé. Ce comportement curieux d'héritage des PAC semble être contrôlé par un attribut unique : msDS-ManagedAccountPrecededByLink.
Le KDC s'appuie sur cet attribut pour déterminer qui est « remplacé » par le dMSA : lorsqu'un dMSA s'authentifie, le PAC est uniquement basé sur ce lien.
Il est temps de réfléchir comme un attaquant
À quoi cela ressemble-t-il du point de vue d'un attaquant ? Explorons un scénario d'attaque possible et voyons jusqu'où un attaquant pourrait aller en utilisant cette fonction.
Notre première idée : Utilisez un DMSA pour créer une primitive de prise de contrôle de compte. Si nous supposons que nous disposons des autorisations nécessaires pour contrôler le compte d'un utilisateur, pourrions-nous « migrer » ses autorisations vers un nouveau dMSA pour les compromettre discrètement ? Ce plan semble solide ! Nous devons simplement :
Créer un DMSA
Démarrer et terminer la migration entre l'utilisateur cible et le dMSA à l'aide de l'opération migrateADServiceAccount rootDSE
S'authentifier en tant que dMSA - Obtener toutes les autorisations de l'utilisateur cible
Le seul problème est le suivant : Cela ne fonctionne pas.
Même si nous contrôlons entièrement le dMSA et le compte remplacé, nous ne pouvons pas effectuer de migration. En effet, à notre connaissance, l'opération migrateADServiceAccount est restreinte aux administrateurs du domaine. La Figure 4 montre un exemple de tentative échouée.
Fig. 4: A failed attempt to use a dMSA to create an account takeover primitive
Passons à notre deuxième idée. Il est évident que nous avons besoin de quelque chose de complexe, créatif et profondément technique. Nous devons explorer des comportements non documentés, voire procéder à une ingénierie inverse d'une partie du groupe KDC... ou nous pourrions simplement définir deux attributs.
Bien que nous ne puissions pas effectuer directement une migration, nous pouvons très facilement la « simuler » en définissant simplement les attributs suivants directement sur l'objet dMSA.
Saisir le DN du compte cible dans l'attribut msDS-ManagedAccountPrecededByLink
Définir msDS-DelegateMSAState sur la valeur 2 (migration terminée)
Par la suite, chaque fois que nous nous authentifions en tant que dMSA, le KDC génère le PAC à l'aide des SID du compte lié à l'attribut msDS-ManagedAccountPrecededByLink, ce qui nous permet de bénéficier de toutes les autorisations du compte remplacé.
Présentation de BadSuccessor
Ce qui est intéressant avec cette technique de « simulation de migration », c'est qu'elle ne nécessite aucune autorisation sur le compte remplacé. La seule exigence est l'autorisation d'écriture sur les attributs d'un dMSA. N'importe quel dMSA.
Une fois que nous avons marqué un dMSA comme ayant été remplacé par un utilisateur, le KDC part automatiquement du principe qu'une migration légitime a été effectuée et accorde volontiers à notre dMSA toutes les autorisations dont disposait l'utilisateur d'origine, comme si nous étions son successeur légitime.
Mais cela ne fonctionnera sans doute pas pour les comptes à privilèges élevés, n'est-ce pas ? Eh bien…
En outre, cette technique, que nous avons baptisée « BadSuccessor », fonctionne sur tous les utilisateurs, y compris les administrateurs de domaine (Figure 5). Elle permet à tout utilisateur qui contrôle un objet dMSA de contrôler l'ensemble du domaine. C'est tout ce qu'il faut. Aucune véritable migration. Aucune vérification. Aucune supervision.
Fig. 5: Full attack flow, showing all steps needed to have a BadSuccessor
Exploitation des dMSA : des faibles privilèges à la domination du domaine
À ce stade, vous vous demandez peut-être : « Eh bien, je n'utilise pas les dMSA dans mon environnement, donc cela ne m'affecte pas. » Détrompez-vous.
Un scénario d'abus : un attaquant prend le contrôle d'un dMSA existant et utilise cet accès pour lancer l'attaque BadSuccessor. Mais il existe en fait un autre scénario, qui sera probablement mis à la disposition des attaquants beaucoup plus souvent : Un attaquant crée un nouveau dMSA.
Lorsqu'un utilisateur crée un objet dans AD, il dispose des autorisations complètes sur tous ses attributs. Par conséquent, si un attaquant peut créer un nouveau dMSA, il peut compromettre l'ensemble du domaine.
Normalement, lorsqu'un dMSA est créé à l'aide de la cmdlet New-ADServiceAccount, il est stocké dans le conteneur Managed Service Accounts. Bien qu'il soit possible que les utilisateurs aient accès à ce conteneur, seuls les groupes Active Directory privilégiés intégrés disposent d'autorisations sur ce conteneur par défaut. Il est donc peu probable que nous puissions écrire dans ce conteneur.
Cependant, les dMSA ne sont pas limités au conteneur Managed Service Accounts ; ils peuvent également être créés dans n'importe quelle unité d'organisation normale. Tout utilisateur disposant des droits de création d'attribut msDS-DelegatedManagedServiceAccount ou des droits de création de tous les objets enfants sur une unité d'organisation peut créer un dMSA.
Création du dMSA
L'autorisation des utilisateurs à créer des objets dans une unité d'organisation est une configuration assez courante. Cette autorisation étant considérée comme bénigne, les utilisateurs disposant de ce privilège ne font probablement pas l'objet d'une surveillance et d'un renforcement appropriés.
Pour créer le dMSA, nous commençons par localiser une unité d'organisation sur laquelle nous avons des privilèges. Heureusement, quelqu'un a créé une unité d'organisation appelée « temp » dans notre exemple d'environnement et a accordé à notre utilisateur sans privilège des autorisations « faibles » pour créer tous les objets enfants (Figure 6).
Fig. 6: Example of required privileges on an OU
Nous pouvons ensuite utiliser ces autorisations pour créer un dMSA à l'aide de la cmdlet New-ADServiceAccount. Comme le montre la Figure 7, bien que l'utilisateur non privilégié ne puisse pas créer de dMSA dans le conteneur MSA par défaut, nous pouvons utiliser l'argument path pour créer le dMSA dans l'unité d'organisation accessible.
Fig. 7: Creating the dMSA in an allowed location using the New-ADServiceAccount PowerShell cmdlet
Nous sommes désormais les heureux propriétaires d'un dMSA nouvellement créé et non fonctionnel. En tant que propriétaire et créateur, nous pouvons nous accorder des autorisations sur l'objet, y compris l'accès en écriture aux deux attributs que nous allons utiliser pour cette attaque. Nous pouvons ensuite les modifier comme suit :
msDS-ManagedAccountPrecededByLink : nous définissons cet attribut sur le DN de n'importe quel utilisateur ou ordinateur (contrôleurs de domaine, membres des administrateurs du domaine, utilisateurs protégés et même, ironiquement, les comptes marqués comme étant sensibles et ne pouvant pas être délégués).
msDS-DelegatedMSAState : nous définissons cette valeur sur 2 pour simuler une migration terminée (Figure 8).
Fig. 8: Modifying attributes to mimic successful migration
Comme nous l'avons mentionné, cette attaque semble fonctionner sur tous les comptes dans AD. Nous n'avons trouvé aucune configuration qui empêcherait l'utilisation d'un compte comme cible remplacée.
Obtention d'un TGT pour le dMSA
Pour nous authentifier auprès de notre dMSA, nous pouvons créer un service et le configurer de sorte qu'il soit exécuté avec le compte dMSA. Bien que possible, cette approche est loin d'être pratique. Heureusement, grâce à la formidable demande de modification de Joe Dibley, Rubeus prend désormais en charge l'authentification dMSA (Figure 9). Nous pouvons donc l'utiliser pour demander un TGT pour notre dMSA :
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket:<Machine TGT>
Fig. 9: Requesting TGT for the new dMSA using Rubeus
dMSA → Administrateur de domaine
Dans cet exemple, nous avons ciblé le compte Administrateur intégré. À l'aide de Wireshark, nous avons inspecté le PAC du ticket que nous avons reçu pour notre dMSA (Figure 10), qui comprenait :
RID du dMSA (1137)
RID du compte remplacé (500 - Administrateur)
Tous les groupes auxquels appartenait le compte remplacé (512 - Administrateurs du domaine, 519 - Administrateurs d'entreprise)
Fig. 10: dMSA’s PAC that includes the Administrator’s groups’ RIDs
C'est tout ce dont le contrôleur de domaine a besoin pour nous traiter en tant qu'héritier légitime. N'oubliez pas : aucune modification des appartenances à un groupe, aucune intervention du groupe d'administrateurs du domaine et aucune écriture LDAP suspecte sur le véritable compte doté de privilèges n'est nécessaire.
Il suffit de deux modifications d'attributs pour qu'un simple objet soit couronné successeur : le KDC ne remet jamais en cause sa légitimité. Si le lien est présent, les privilèges sont accordés. Nous n'avons modifié aucune appartenance à un groupe, nous n'avons pas modifié le rang d'un compte existant et nous n'avons déclenché aucune alerte traditionnelle d'élévation des privilèges.
Démo : Flux d'attaque de bout en bout
Regardez cette vidéo pour obtenir une démonstration complète de l'attaque en action.
Démonstration d'une exploitation de dMSA pour élever les privilèges dans Active Directory
Mais ce n'est pas tout : les attaquants exploitent les dMSA pour compromettre les informations d'identification
Nous avons été satisfaits d'obtenir un TGT pour n'importe quel utilisateur, mais nous en voulons encore plus. Que se passe-t-il si nous voulions également leurs informations d'identification? Heureusement, le dMSA est également présent dans ce scénario.
Une demande de TGT pour un dMSA s'accompagne d'une nouvelle structure appelée KERB-DMSA-KEY-PACKAGE. Cette structure comprend deux champs : current-keys et previous-keys. Selon MSDN, ils sont censés contenir des clés liées au mot de passe actuel et précédent du dMSA, et c'est le cas. Mais ce n'est pas tout.
Nous avons été surpris de constater que même lors de la demande d'un TGT pour un dMSA nouvellement créé, le champ previous-keys n'était pas vide. Étant donné qu'il vient d'être créé, il ne doit pas y avoir de « mot de passe précédent ». Nous avons d'abord ignoré ce fait, puis nous avons vu quelque chose qui nous a semblé très familier.
Comme le montre la Figure 11, le deuxième élément de la structure contenait une seule clé de type 23 (RC4-HMAC). Ce type de chiffrement n'est pas salé, ce qui signifie que des mots de passe identiques génèrent des clés identiques, même entre les utilisateurs.
Fig. 11: ASN.1 decoded value of the KERB-DMSA-KEY-PACKAGE, decoded at https://pkitools.net/pages/ca/asn1.html
Qu'en est-il de cette clé en particulier ? Le fait de réutiliser le même mot de passe pendant des années dans les environnements de laboratoire a enfin porté ses fruits. Nous l'avons immédiatement reconnu. Il s'agissait de la clé correspondant à Aa123456, le mot de passe que nous avons utilisé pour notre compte cible pendant la démonstration.
Il faut comprendre ce point : La clé d'un compte distinct s'est retrouvée dans la structure previous-keys du dMSA.
Compromission de clés à grande échelle
Alors, que se passe-t-il ? Et pourquoi ?
L'attribut msDS-ManagedAccountPrecededByLink ne se contente pas de lier le dMSA au compte remplacé pour récupérer ses autorisations : il permet également au dMSA d'hériter de ses clés. Cela signifie que cette attaque peut également être utilisée pour obtenir les clés de n'importe quel (ou de chaque) utilisateur et ordinateur du domaine. Nous pouvons utiliser cette clé pour nous authentifier auprès du compte.
Bien que nous n'ayons pas analysé l'ensemble de la mise en œuvre, notre théorie est que ce comportement existe pour garantir une continuité fluide lors de la migration du compte, au profit de l'utilisateur final.
Supposons que nous ayons un service en cours d'exécution avec un compte de service existant. Les comptes du domaine demandent des tickets pour ce service, qui sont chiffrés à l'aide de la clé du compte de service existant. Supposons maintenant que nous remplacions le compte existant par un dMSA, que la migration soit effectuée et que le compte de service soit remplacé par le dMSA, mais que le dMSA n'ait pas accès à la clé de l'ancien compte.
Résultat : lorsqu'un client tente de s'authentifier à l'aide de son ticket existant, le serveur ne peut pas le déchiffrer à l'aide de la nouvelle clé du dMSA. Ainsi, tous les tickets émis sont inutilisables, même s'ils n'ont pas expiré.
Pour éviter ce type d'interruption de service, le KDC inclut les clés du compte précédent dans la nouvelle structure de package de clés du dMSA, les traitant comme s'il s'agissait des informations d'identification précédentes du dMSA et lui permettant alors de déchiffrer les « anciens » tickets.
Une fois que nous avons compris cela, une autre particularité commence à avoir du sens. Le champ current-keys contient trois éléments, chacun composé d'un entier (représentant le type de chiffrement) et d'une chaîne d'octets (la clé correspondante). Vous pouvez vous reporter à cette page pour comprendre les valeurs de type de chiffrement. Dans notre cas, la liste inclut les clés pour RC4-HMAC, AES256 et AES128. Cependant, le champ previous-keys semble légèrement différent : il ne contient qu'une seule clé, qui correspond à RC4-HMAC (Figure 12). Pourquoi la liste previous-keys ne contient-elle qu'un seul type de clé, et pourquoi RC4-HMAC en particulier ?
Fig. 12: KERB-DMSA-KEY-PACKAGE structure, highlighting the different keys
La réponse se trouve dans les types de chiffrement pris en charge par le compte d'origine (remplacé). Les tickets de service sont chiffrés uniquement à l'aide des types de chiffrement pris en charge par le service cible. Comme expliqué dans l'excellent article de blog de Harmj0y, l'attribut msDS-SupportedEncryptionTypes contrôle ce comportement. Si cet attribut n'est pas défini (cas par défaut pour les comptes utilisateur), le système utilise par défaut RC4-HMAC uniquement, d'où la seule clé RC4-HMAC dans la la liste previous-keys.
En d'autres termes, le KDC fournit au dMSA uniquement les clés du compte d'origine qui seraient nécessaires pour déchiffrer les tickets de service émis avant la migration. Ils sont déterminés en fonction des types de chiffrement pris en charge par l'entité de sécurité d'origine, que vous pouvez vérifier en inspectant son attribut msDS-SupportedEncryptionTypes.
La réponse de Microsoft
Nous avons transmis ces informations à Microsoft via MSRC le 1er avril 2025, et après avoir examiné notre rapport et notre preuve de concept, Microsoft a reconnu le problème et confirmé sa validité. Cependant, Microsoft a estimé qu'il s'agissait d'une vulnérabilité de gravité modérée et a déclaré qu'elle ne nécessitait pas de correction immédiate.
Selon Microsoft, une exploitation réussie exige que l'attaquant dispose déjà d'autorisations spécifiques sur l'objet dMSA, ce qui indique des privilèges élevés. En réponse au scénario de création d'un nouveau dMSA, Microsoft a référencé KB5008383, qui traite des risques liés à l'autorisation CreateChild.
Bien que nous appréciions la réponse de Microsoft, nous ne sommes pas d'accord avec l'évaluation de la gravité.
Cette vulnérabilité introduit un chemin d'exploitation jusqu'alors inconnu et à fort impact, qui permet à tout utilisateur disposant des autorisations « CreateChild » sur une unité d'organisation de compromettre n'importe quel utilisateur du domaine et d'obtenir un pouvoir similaire au privilège « Replicating Directory Changes », utilisé pour lancer des attaques DCSync.
En outre, nous n'avons trouvé aucune indication que les pratiques ou outils actuels du secteur signalent l'accès CreateChild (ou, plus précisément, CreateChild pour les dMSA) comme étant une préoccupation majeure. Nous pensons que cela souligne à la fois la discrétion et la gravité de la question.
Détection et prévention
Détection
Pour détecter un abus potentiel de ce vecteur d'attaque, les entreprises doivent se concentrer sur les domaines suivants :
Auditer la création de dMSA : configurez un SACL pour enregistrer la création de nouveaux objets msDS-DelegatedManagedServiceAccount (ID d'événement 5137 ; Figure 13). Prêtez une attention particulière aux comptes qui ne sont généralement pas responsables de la création de comptes de service.
Fig. 13: Event example of dMSA creation
Surveiller les modifications d'attributs : configurez un SACL pour les modifications apportées à l'attribut MSDS-ManagedAccountPrecededByLink (ID d'événement 5136 ; Figure 14). Les modifications apportées à cet attribut peuvent indiquer une tentative d'abus ou un abus réussi.
Fig. 14: Event example of dMSA link creation
Suivre les authentifications des dMSA : lorsqu'un TGT est généré pour un dMSA et inclut la structure KERB-DMSA-KEY-PACKAGE, le contrôleur de domaine enregistre l'ID d'événement 2946 (journal des services d'annuaire).
Le champ « Group Managed Service Account Object » (bien qu'il s'agisse d'un dMSA et non d'un gMSA) affiche le DN du dMSA qui tente de s'authentifier et le champ « Caller SID » est désigné par S-1-5-7 (Figure 15). Les événements 2946 fréquents ou inattendus impliquant des dMSA inhabituels doivent faire l'objet d'une enquête.
Fig. 15: Event example of dMSA authentication
Vérifier les autorisations : prêtez une attention particulière aux autorisations sur les unités d'exploitation et les conteneurs. Des délégations excessivement permissives peuvent ouvrir la porte à cet abus.
Atténuation
Jusqu'à ce qu'un correctif officiel soit publié par Microsoft, les efforts défensifs doivent se concentrer sur la limitation de la capacité à créer des dMSA et le renforcement des autorisations dans la mesure du possible.
Les gardiens de la sécurité doivent identifier tous les principaux (utilisateurs, groupes, ordinateurs) disposant de l'autorisation de créer des dMSA dans le domaine et limiter cette autorisation aux administrateurs de confiance uniquement.
Pour vous aider, nous avons publié un script PowerShell qui :
Énumère tous les principaux non définis par défaut pouvant créer des dMSA
Répertorie les unités d'organisation dans lesquelles chaque entité de sécurité a cette autorisation
Microsoft nous a informés que ses équipes d'ingénierie travaillent sur un correctif, et nous mettrons à jour les conseils d'atténuation de cet article de blog dès que nous aurons de plus amples détails techniques.
Conclusion
Cette étude souligne la façon dont même les autorisations limitées, souvent considérées comme présentant un risque faible, peuvent avoir des conséquences considérables dans les environnements Active Directory. Les attaquants peuvent se montrer très créatifs, et les avancées technologiques récentes nous ont appris que les fonctions paraissant inoffensives peuvent avoir des conséquences désastreuses si elles sont mises entre de mauvaises mains. Le dMSA a été présenté comme une solution moderne pour la gestion des comptes de service, mais son lancement a également apporté une nouvelle couche de complexité, et avec elle, de nouvelles opportunités d'abus.
Les organisations devraient traiter la capacité de créer des dMSA ou de contrôler les systèmes existants avec le même niveau de surveillance que les autres opérations sensibles. Les autorisations de gestion de ces objets doivent être strictement restreintes et les modifications apportées à ces objets doivent être surveillées et auditées régulièrement.
Nous espérons que cette étude met en lumière les risques associés à Windows Server 2025 en général, et plus particulièrement aux dMSA, et qu'elle aide les défenseurs à mieux comprendre et à atténuer l'impact potentiel des autorisations mal configurées.
