Golden dMSA : Qu'est-ce que le contournement de l'authentification dMSA ?

Principales conclusions

• Le chercheur en sécurité de Semperis, Adi Malyanker, a découvert un défaut de conception critique dans les comptes de services gérés délégués (dMSA) introduits dans Windows Server 2025.
• Comme cette faille simplifie grandement la génération de mots de passe par force brute, son exploitation est peu complexe.
• L'attaque Golden dMSA permet aux attaquants de contourner l'authentification et de générer des mots de passe pour tous les dMSA et gMSA et leurs comptes de service associés.
• La détection de l'activité de Golden dMSA nécessite une configuration et un audit manuels des journaux, ce qui rend les mesures d'atténuation difficiles.
• Les chercheurs de Semperis considèrent cette vulnérabilité comme MODÉRÉE car pour l'exploiter, les attaquants doivent posséder une clé racine KDS accessible uniquement aux comptes les plus privilégiés : root Domain Admins, Enterprise Admins, et SYSTEM.
• Cependant, cette attaque peut avoir un impact important, permettant un mouvement latéral entre domaines et un accès permanent à tous les comptes de services gérés et à leurs ressources, et ce indéfiniment.

Windows Server 2025 de Microsoft apporte des innovations majeures en matière de sécurité, notamment l'introduction des comptes de service gérés délégués (dMSA), conçus pour révolutionner la gestion des comptes de service. Contrairement aux comptes statiques basés sur des mots de passe, qui peuvent être la cible d'attaques de type « Kerberoasting », les dMSA lient l'authentification directement aux machines autorisées dans Active Directory (AD).

Cette approche centrée sur la machine élimine le vol de données d'identification en liant l'authentification à l'identité de l'appareil plutôt qu'aux mots de passe gérés par l'utilisateur. Seules les machines explicitement autorisées peuvent accéder à la dMSA.

Cet article révèle une nouvelle attaque contre les comptes de services gérés délégués, appelée " Golden DMSA attack". Cette technique permet aux attaquants de contourner l'authentification gérée par la machine et de générer des mots de passe pour tous les dMSA associés hors ligne.

Qu'est-ce que le Golden dMSA ?

Golden dMSA est une méthode de persistance et d'élévation des privilèges qui permet aux attaquants de générer des mots de passe pour tous les dMSA et les comptes de service gérés par groupe (gMSA), ainsi que pour leurs comptes de service associés.

L'attaque exploite un défaut de conception critique : une structure utilisée pour le calcul de la génération de mots de passe contient des composants temporels prévisibles avec seulement 1 024 combinaisons possibles, ce qui rend la génération de mots de passe par force brute triviale du point de vue du calcul.

Cette attaque peut être utilisée à la fois pour la persistance et l'escalade des privilèges dans tout environnement AD avec des comptes dMSA. Semperis estime que cette vulnérabilité présente un risque modéré car son exécution dépend d'une compromission partielle de la forêt.

Lisez la suite pour savoir comment nous avons découvert la vulnérabilité qui permet à Golden dMSA de fonctionner, les détails que nous avons trouvés derrière le défaut de conception,
et comment vous pouvez détecter et atténuer l'activité de contournement de l'authentification.

Comment fonctionne une attaque de type Golden dMSA ?

Une fois qu'un attaquant a obtenu des privilèges élevés dans un domaine, il peut compromettre systématiquement tous les comptes dMSA et gMSA au moyen d'une attaque simple en quatre phases.

Phase 1 : Extraction du matériel de la clé racine KDS (condition préalable à l'attaque). L'attaquant extrait le matériel cryptographique de la clé racine des services de distribution de clés (KDS), qui est à la base de tous les mots de passe des comptes de services gérés.

Phase 2 : Recensement des comptes dMSA. Dans la phase 1, l'utilisateur SYSTEM ou Domain Admin n'a pas le droit d'énumérer les dMSA dans d'autres domaines. Dans cette deuxième phase, l'attaquant tente, par force brute ou en utilisant LDAP, de découvrir des données telles que sAMAccountName des attributs et des identifiants de sécurité (SID) des comptes dMSA dans la forêt AD.

Phase 3 : deviner le ManagedPasswordID. Ensuite, l'attaquant tente d'identifier la bonne ManagedPasswordId et les hachages de mots de passe par le biais de devinettes ciblées.

Phase 4 : Génération de mots de passe. En utilisant des outils spécialisés comme GoldenDMSA, l'attaquant peut générer des mots de passe valides pour tout gMSA ou dMSA associé à la clé compromise.

Ce processus ne nécessite aucun accès privilégié supplémentaire une fois la clé racine du KDS obtenue, ce qui en fait une méthode de persistance particulièrement dangereuse.

Cette attaque met en évidence la limite de confiance critique des comptes de services gérés. La sécurité de ces comptes repose sur des clés cryptographiques au niveau du domaine. Bien que la rotation automatique des mots de passe offre une excellente protection contre les attaques typiques, les administrateurs de domaine, les administrateurs Dns et les opérateurs d'impression peuvent contourner entièrement ces protections et compromettre tous les dMSA et gMSA de la forêt.

Qu'est-ce que les dMSA ? Un bref historique des comptes de service

Pendant des décennies, les administrateurs Windows ont utilisé des comptes de domaine ordinaires pour exécuter des services - une approche fonctionnelle mais imparfaite qui a évolué avec l'introduction des comptes de service. Contrairement aux comptes d'utilisateurs interactifs qui représentent des personnes réelles, les comptes de service existent uniquement pour fournir un contexte d'identité aux processus automatisés.

Les premiers comptes de service reposaient sur des mots de passe statiques qui créaient des cauchemars opérationnels. La coordination des changements de mots de passe entre plusieurs équipes, services et applications entraînait souvent des pannes et une résistance aux meilleures pratiques en matière de sécurité.

Pire encore, les mots de passe statiques permettaient des attaques dévastatrices. Les exploits de type "Kerberoasting" permettent aux attaquants de demander des tickets de service et de craquer des mots de passe hors ligne, tandis que les informations d'identification faibles ou inchangées constituent des cibles faciles pour l'escalade des privilèges.

Depuis, Microsoft a créé différentes versions de comptes de service.

• Comptes de services gérés (MSA). Windows Server 2008 R2 a introduit la rotation automatique des mots de passe de 240 caractères tous les 30 jours, ainsi que la gestion automatique des noms de principaux services (SPN). Le problème ? Les MSA sont limités à une seule machine.
• Comptes de services gérés par groupe (gMSA). Windows Server 2012 a résolu la limitation liée au nombre de machines, permettant ainsi le partage d'identités de service au sein des clusters, des équilibreurs de charge et des services distribués, tout en conservant les avantages de la MSA en matière de sécurité.
• Comptes de service gérés délégués (dMSA). La dernière innovation de Windows Server 2025 marque le passage d'une gestion centralisée des mots de passe à une authentification liée à la machine, ce qui représente un changement fondamental en matière de sécurité des comptes de service.

Cette évolution des comptes traditionnels vers le gMSA puis le dMSA crée une surface d'attaque intéressante, que la technique Golden dMSA exploite en s'appuyant sur la base cryptographique partagée entre les systèmes gMSA et dMSA.

Comment les attaquants trouvent les dMSA : Briser la barrière de l'invisibilité

Du point de vue d'un attaquant, la possibilité de répertorier les dMSA en tant qu'utilisateur sans privilèges est essentielle pour l'escalade de privilèges et le déplacement latéral. Pour obtenir le mot de passe d'un dMSA, il faut connaître son nom et son SID.

Cependant, l'un des défis les plus intrigants en matière d'ASDM est de trouver ces comptes insaisissables en premier lieu.

D'après la documentation de Microsoft, pour créer des dMSA, on commence par le CreateDelegatedServiceAccount commande qui Figure 1 montre.

Et maintenant, place au plaisir ! Essayons d'afficher notre compte DMSA-Demo que nous venons de créer à l'aide de Get-ADServiceAccount (Figure 2).

C'est là que nous nous heurtons à notre premier obstacle. Un utilisateur privilégié peut consulter le compte sans problème, mais un utilisateur non privilégié n'obtient absolument rien : les résultats sont vides (figure 3). Pourquoi ? Tout cela tient aux paramètres par défaut des listes de contrôle d'accès (ACL) du compte. Et croyez-moi, aucun administrateur ne souhaite s'aventurer sur ce terrain.

Vous avez remarqué quelque chose de suspect dans la figure 4? Les utilisateurs authentifiés ne peuvent pas lire les données de ces comptes.

Comment un utilisateur non privilégié peut-il donc accéder aux informations relatives aux comptes dMSA ?

C'est ici que le travail de détective commence. Après d'innombrables recherches et tentatives infructueuses, j'ai découvert que nous pouvions construire une liste de SID potentiels et traduire chacun d'entre eux en objets NTAccount (j'ai utilisé C# pour cette magie). (J'ai utilisé C# pour cette magie).

Sous le capot, la fonction translate exploite ces puissantes API Win32 : LsaOpenPolicy et LsaLookupSids (Figure 5).

Les noms des fonctions laissent deviner leur fonction, mais la figure 6 présente la documentation officielle de Microsoft pour que cela soit parfaitement clair.

Il est intéressant de noter qu'un outil Impacket appelé lookupsid¹ utilise exactement la même technique, en employant hLsarOpenPolicy2 et hLsarLookupSids pour énumérer les SID.

Passons maintenant à la partie passionnante : voyons ce qui se passe lorsque nous utilisons ces fonctions Win32 (figure 7).

Jackpot ! Nous avons récupéré tous les comptes du domaine, ainsi que d'autres objets dotés d'un SID.

Cette méthode fonctionne car elle contourne complètement le protocole LDAP, échappant ainsi efficacement à ces listes de contrôle d'accès (ACL) restrictives. Voici en quoi réside toute la beauté technique de cette approche : LsaLookupSids et LsaOpenPolicy ne s'appuie absolument pas sur LDAP. À la place, le protocole LSA communique via \PIPE\lsarpc comme point de terminaison RPC sur SMB.

Mais attendez - comment pouvons-nous identifier les comptes de cette liste massive qui sont des dMSA ?

Voici l'astuce : nous signalons tous les comptes se terminant par « $ » comme suspects. Ensuite, nous éliminons systématiquement les comptes automatiques et les gMSA.

Et voilà ! Nous disposons désormais d'un inventaire complet de tous les dMSA présents dans le domaine.

Coup de théâtre : cette technique fonctionne également au-delà des frontières des domaines ! Nous pouvons énumérer les dMSA d'autres domaines en utilisant exactement la même méthode.

Voici une découverte en prime.

Grâce à mes collègues Andrea Pierini et Shai Laronne, nous avons mis au jour une autre approche basée sur le protocole LDAP (figure 8).

La sauce secrète ? Lorsque nous lançons la recherche directement à partir du conteneur lui-même, nous pouvons rechercher ces types de comptes spécifiques. Combinée à notre précédente méthode d'énumération des SID, nous pouvons extraire les informations SID tout en filtrant les gMSA et les comptes d'ordinateur(figure 9).

Cette double approche nous donne de multiples vecteurs d'attaque pour la découverte de dMSA - ce qui change la donne pour toute évaluation de la sécurité.

Pourquoi la clé racine KDS est-elle au cœur des attaques Golden dMSA ?

Introduite pour la première fois dans Windows Server 2012, la clé racine KDS est le joyau de l'infrastructure gMSA de Microsoft. Considérez-la comme le cerveau cryptographique du service de distribution de clés (Key Distribution Service) de Microsoft : c'est le moteur qui génère et distribue les mots de passe pour les comptes gMSA.

L'obtention de cette clé racine est la première étape critique de la chaîne d'attaque, car elle permet aux attaquants de calculer les mots de passe de n'importe quel gMSA du domaine hors ligne. Cette capacité est dévastatrice car les gMSA sont conçus pour que leurs mots de passe fassent l'objet d'une rotation automatique par le contrôleur de domaine (DC), ce qui les fait apparaître comme sûrs aux yeux des administrateurs. Cependant, avec la clé racine KDS en main, un attaquant peut dériver mathématiquement le mot de passe actuel de n'importe quel compte gMSA sans jamais se connecter à nouveau au contrôleur de domaine.

Voici ce qui rend ce système si puissant : la clé racine KDS fait office de clé maîtresse ultime. C'est à partir de celle-ci que tous les mots de passe gMSA sont dérivés grâce à un processus de dérivation de clés particulièrement ingénieux.

Mais ce n'est pas tout. Microsoft a récemment étendu la clé racine KDS au contrôle des comptes dMSA.

La clé racine du KDS est désormais deux fois plus précieuse pour les attaquants, puisqu'elle déverrouille les mots de passe gMSA et dMSA.

La clé racine du KDS se trouve dans le contexte de nommage de la configuration (CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=,DC=), qui se réplique vers tous les contrôleurs de domaine (DC) inscriptibles de la forêt à partir du contrôleur de domaine racine de celle-ci, mais reste invisible pour un utilisateur non privilégié. Microsoft n'a pas pris la sécurité à la légère dans ce cas précis. Les listes de contrôle d'accès (ACL) associées à ces clés sont extrêmement restrictives (Figure 10) limitant l'accès aux seuls comptes les plus privilégiés : root Domain Admins, Enterprise Admins et SYSTEM.

Cependant, malgré ces restrictions inflexibles, ces précieuses clés peuvent toujours être récupérées à partir d'autres DC dans toute la forêt, mais uniquement avec un accès de niveau SYSTEM(Figure 11).

A ce stade, on pourrait penser que le fait d'avoir des permissions SYSTEM sur un DC diminue l'exploitabilité de Golden dMSA. Cependant, il s'agit d'un seul DC sur l'ensemble de la forêt, et le flux d'attaque modifie fondamentalement le paysage des menaces, passant d'une compromission localisée à une porte dérobée persistante à l'échelle de la forêt.

Cela signifie que même si l'accès SYSTEM sur un DC représente déjà une brèche importante, la technique Golden dMSA transforme cette brèche en une menace beaucoup plus dangereuse et durable en permettant à l'attaquant de maintenir un accès persistant aux gMSA, aux dMSA et à leurs comptes de service associés dans l'ensemble de la forêt - sans nécessiter une présence continue sur le DC compromis.

Soyez attentif à ce détail essentiel : Les clés racine KDS n'ont pas de date d'expiration

Microsoft recommande de ne conserver qu'une seule clé racine KDS par environnement.

Faites le calcul. Théoriquement, après avoir compromis une seule clé racine KDS, un attaquant pourrait potentiellement générer indéfiniment des mots de passe pour tous les futurs comptes dMSA et gMSA.

J'ai découvert un élément encore plus intrigant au cours de mes recherches. Même dans des environnements comportant plusieurs clés racines KDS, le système peut continuer à utiliser l'ancienne clé racine KDS en raison de la mise en cache (à moins de réinitialiser le service KDS d'une manière bien précise). Cela signifie que la clé d'origine que nous avons compromise pourrait être conservée de par la conception même de Microsoft, créant ainsi une porte dérobée persistante susceptible de perdurer pendant des années.

Cette décision architecturale transforme une seule extraction de clé réussie en un avantage stratégique à long terme pour les attaquants, faisant de la clé racine du KDS l'une des cibles les plus précieuses de tout domaine Windows.

Déchiffrer le code : De la génération de mots de passe gMSA à la génération de mots de passe dMSA

Nous allons maintenant nous plonger au cœur de l'attaque : l'extraction des dMSA ManagedPasswordId attribut.

ManagedPasswordId Il s'agit d'un attribut stocké dans Active Directory qui contient les métadonnées nécessaires pour dériver le mot de passe actuel d'un MSA. Nous devons récupérer cet attribut car il contient les paramètres cryptographiques essentiels — notamment l'identifiant de la clé, l'heure de création et d'autres détails relatifs à la dérivation — qui, associés à la clé racine du KDS, permettent de calculer mathématiquement le mot de passe réel du gMSA.

Si cela vous semble familier, vous avez tout à fait raison. L'excellente étude de Yuval Gordon sur Attaques de l'Active Directory de la gMSA a fait connaître au monde entier Golden gMSA. Cette technique d'attaque consiste à extraire la clé racine du KDS de l'AD, à interroger les gMSA disponibles avec leur SID et leur ManagedPasswordId et de calculer les mots de passe à partir des données.

Lors de mes recherches sur Golden dMSA, mon hypothèse était simple mais puissante : Microsoft aurait pu recycler le même code de gMSA à dMSA pour la création et le renouvellement des mots de passe. Mais pouvions-nous réellement reproduire l'attaque Golden gMSA contre des comptes dMSA ?

C'est là que nous nous sommes heurtés à notre premier obstacle majeur. Ces ACL restrictives que nous avions découvertes auparavant nous empêchaient totalement d'accéder à ces données essentielles sur les comptes dMSA. Nous avons dû approfondir nos recherches et étendre notre algorithme.

Rétro-ingénierie de la structure ManagedPasswordId

Pour résoudre cette énigme, j'ai commencé à enquêter sur les ManagedPasswordId structure elle-même. J'ai créé un nouveau compte dMSA et j'ai extrait son ManagedPasswordID attribut.

Après avoir analysé le tableau d'octets et l'avoir comparé à différentes instances, j'ai découvert qu'il contenait les composants présentés à la figure 12.

Cette structure me semblait familière. Elle est pratiquement identique à celle de gMSA. ManagedPasswordID format (Figure 13).

La figure 14 montre la décomposition complète de cette structure, avec ces éléments clés :

• Version : Valeur entière avec valeur décimale (1,0,0,0)
• Réservé : Valeur entière avec une valeur décimale de (75, 68, 83, 75)
• isPublicKey : Valeur entière avec valeur décimale (2,0,0,0)
• L0Index : valeur entière représentant une variable temporelle (nous y reviendrons plus tard)
• L1Index : valeur entière représentant une variable temporelle (nous y reviendrons plus tard)
• L2Index : valeur entière représentant une variable temporelle (nous y reviendrons plus tard)
• RootKeyIdentifier : Valeur GUID construite à partir de l'ID de la clé racine du KDS.

Le domaine de la RootKeyIdentifier peut être construit à partir des clés racine KDS (RKL est l'identifiant de la clé racine KDS, c'est-à-dire f06c3c8d-b2c2-4cc6-9a1a-8b3b3c82b9f0), sous la forme suivante Figure 15 montre.

• cbUnknown : Valeur entière avec valeur décimale (0, 0, 0, 0)
• cbDomainName : Valeur entière représentant (longueur du nom de domaine * 2) + 2.
• cbForestName : Valeur entière représentant (longueur du nom de la forêt * 2) + 2.
• Nom de domaine : Nom de domaine du compte dMSA dans ce format spécial
• ForestName : Nom de la forêt du compte dMSA dans ce format spécial

Remarquez quelque chose dans le cbDomainName et cbForestName: On multiplie par 2 et on ajoute 2 car des octets ASCII de valeur 0 sont insérés entre chaque caractère. Ainsi, root.test devient r.o.o.t…t.e.s.t.. dans la structure actuelle.

En étudiant les Article de Microsoft Learn sur msDS-ManagedPassword et le fournisseur Microsoft KDS KdsCli.dll (qui met en œuvre la majeure partie de la logique du mot de passe), j'ai tracé le flux à partir de GetgMSAPasswordBlob(), comme Figure 16 montre.

La logique est élégante. Lorsque le ManagedPasswordId n'existe pas ou a expiré, le système définit une nouvelle heure de début et appelle GetPasswordBasedOnTimestamp(), comme Figure 17 montre.

Ceci nous amène à l'une des observations les plus significatives de notre recherche. Les valeurs L0, L1 et L2 sont générées en GetIntervalID()puis transmis à GetKey() lors de la construction d'une nouvelle clé BLOB (Figure 18).

Cette observation m'a permis de découvrir un élément crucial : les valeurs L1 et L2 sont limitées à 31 (inclus). Ce n'est pas seulement une hypothèse ; cela est confirmé à la fois dans la DLL (Figure 19) et celui de Microsoft GetKey() documentation (Figure 20).

Les GetPasswordBasedOnTimestamp() sera également appelée lorsqu'un renouvellement de la méthode ManagedPasswordId est nécessaire.

La découverte révolutionnaire

C'est maintenant que vient la révélation qui change la donne.

Nous pouvons prédire la plupart des ManagedPasswordID nécessaire pour calculer les mots de passe gMSA et dMSA. Nous savons que L1Index et L2Index sont liées à des valeurs que nous pouvons obtenir par la force brute. Le principal défi semble être L0Indexqui, en tant qu'entier de 4 octets, pourrait avoir des milliards de valeurs potentielles.

En approfondissant l'analyse de l'algorithme de Golden gMSA, j'ai découvert qu'il créait les objets suivants :

• L0Keycontenant les attributs de la clé racine du KDS (Figure 21)
• L0KeyId, calculée à partir de l'heure actuelle
• GenerateKDFContext et GenerateDerivedKeyce qui permet de déduire L1Key et L2Key les vecteurs d'octets une fois (Figure 21) ou plusieurs fois (Figure 22)

Voici l'idée essentielle.

• L0Keyid, L1Keyidet L2Keyid sont entièrement basées sur le temps et indépendantes de l'utilisateur (comme les Figure 19 ci-dessus).
• La seule valeur contrôlée par l'utilisateur est la valeur ManagedPasswordId lui-même, que nous fournissons avec la clé racine KDS, les noms de domaine et de forêt, et le SID.

C'est là que tout s'est enclenché. Lorsque j'ai tracé l'endroit où L0Index (extrait de l'article ManagedPasswordId) est effectivement utilisé dans l'algorithme, j'ai trouvé que les révélations que le Figure 23 et Figure 24 spectacle.

C'est un détail étonnant. L0index n'est pas du tout utilisé par le MsdsManagedPasswordId ce qui signifie que la valeur utilisée n'a pas d'importance.

Deviner un mot de passe : La mise en commun des connaissances

Nous pouvons maintenant construire la quasi-totalité de la ManagedPasswordId le dernier élément nécessaire pour prédire les mots de passe et les hachages gMSA et dMSA. Étant donné que le L0Index est ignorée, et L1Index et L2Index doit être compris entre 0 et 31 (inclus), nous n'avons que 32 × 32 = 1 024 vecteurs possibles à tester.

J'ai vérifié cette conclusion en calculant le mot de passe correct et le hachage NTLM pour chaque vecteur, puis j'ai tenté des attaques de type « Pass the Hash » à l'aide de^{l'outil smbclient2} d'Impacket (figure 25).

Succès ! Cette méthode a parfaitement fonctionné pour les comptes gMSA. Nous avons pu prédire leurs hachages en 1 024 tentatives sans avoir besoin de l'information spécifique de l ManagedPasswordId.

Mais je n'ai toujours pas réussi à passer le hachage avec le hachage du mot de passe de dMSA. En outre, nous devions nous demander comment nous pouvions tirer parti de cette attaque alors que les attaques de type "Pass the Hash" sont atténuées dans ce domaine.

Après avoir examiné les attributs de l'un de mes dMSA, j'ai constaté qu'il exigeait une connexion avec un cryptage Kerberos de type AES 256, comme le montre la figure 26. (Vous vous souviendrez que j'ai suivi la recommandation de Microsoft d'imposer AES 256 lors de la création d'un dMSA).

J'ai essayé de générer un hachage AES 256 à partir du mot de passe du service. Après quelques tentatives épuisantes, j'ai découvert que les gMSA et les dMSA utilisent un format de sel légèrement différent pour le hachage AES 256 :

<Domain name in UPPER case>host<user's full UPN in lower case (without $)>

Par exemple :

ROOT.TESThostdmsa-demo8.root.test

Avec ce format de sel, je pouvais enfin générer des tickets Kerberos valides pour les comptes dMSA.

Cartographie du flux d'attaque Golden dMSA

Le diagramme de la figure 27 résume l'attaque Golden dMSA.

1. Commencez avec les privilèges SYSTEM sur l'un des DC du domaine ou les privilèges Enterprise Admin pour extraire les clés racine du KDS.
2. Forcer les SID des comptes dMSA ou utiliser des requêtes LDAP pour identifier les comptes cibles.
3. Créer une liste de mots contenant tous les 1 024 mots possibles. ManagedPasswordIds pour cet utilisateur spécifique.
4. Calculer le mot de passe pour chaque paire possible (clés racine KDS), ManagedPasswordIds) et le hacher en NTLM/AES256.
5. Testez le hachage de chaque mot de passe à l'aide des techniques "Pass the Hash" ou "Overpass the Hash".

Cette attaque transforme les comptes dMSA de cibles apparemment impénétrables en défis de force brute gérables, nécessitant seulement 1 024 tentatives pour craquer n'importe quel mot de passe dMSA dans le domaine.

Comment une attaque Golden dMSA contourne l'authentification normale

Dans sa documentation, Microsoft précise que « le secret dMSA ne peut être récupéré ni trouvé ailleurs que sur le contrôleur de domaine », soulignant ainsi une différence fondamentale entre les mécanismes d'authentification gMSA et dMSA. Avec les gMSA, le processus est simple : une entité s'authentifie et demande directement les identifiants (mot de passe) du gMSA, puis reçoit le mot de passe proprement dit à des fins d'authentification.

Les dMSA fonctionnent selon un principe totalement différent. Elles doivent s'authentifier à l'aide de l'identité de la machine pour obtenir un ticket destiné à l'utilisateur de la dMSA. Le mot de passe de la dMSA ne quitte jamais le contrôleur de domaine. Il sert en revanche à chiffrer le ticket qui est renvoyé à la machine requérante.

Pour éviter les cas où un attaquant vole le hachage de la machine et l'utilise pour demander un ticket, Microsoft recommande d'utiliser Credential Guard. Cette mesure d'atténuation crée une barrière solide qui devrait stopper net la plupart des attaques par vol d'informations d'identification.

Mais c'est là que l'attaque « Golden dMSA » change la donne. Le « Golden dMSA » contourne complètement les protections habituelles de Credential Guard (figure 28). Nous ne suivons plus les règles d'authentification habituelles.

Au lieu de suivre le processus d'authentification prévu par Microsoft, les identifiants dMSA sont utilisés directement via une attaque cryptographique (figure 29). Cela signifie que :

• Aucune identité de machine n'est requise. Nous n'avons pas besoin de compromettre la machine hôte.
• Credential Guard perd toute utilité. Étant donné que nous ne volons pas les identifiants de la machine, cette protection n'offre aucune défense.

Microsoft a confirmé que « à compter de la mise à jour de sécurité Windows d'avril (KB5055523), la fonctionnalité Credential Guard protégeant les comptes machine est temporairement désactivée sous Windows Server 2025 et Windows 11, version 24H2. Cette fonctionnalité a été désactivée en raison d'un problème lié à la rotation des mots de passe machine via Kerberos. Elle restera désactivée jusqu'à ce qu'un correctif définitif soit disponible. »

Quel est le véritable risque de Golden dMSA ? Dévastation de l'ensemble de la forêt

Une fois qu’un attaquant a réussi à compromettre un compte dMSA à l’aide de la technique « Golden dMSA », les choses sérieuses commencent. Il ne s’agit pas simplement d’accéder à un seul compte de service. Il s’agit d’exploiter ce point d’ancrage pour mener une propagation latérale dévastatrice. De plus, cette technique permet aux attaquants de pirater les mots de passe et d’obtenir les autorisations des comptes de service ayant à la fois lancé et achevé leur migration vers le dMSA compromis.

C'est là que cette attaque devient véritablement terrifiante du point de vue de la sécurité. L'attaque « Golden dMSA » ne s'arrête pas aux limites des domaines. Elle opère au niveau de la forêt. Une fois que nous avons compromis la clé racine KDS d'un domaine quelconque au sein de la forêt, nous pouvons systématiquement cibler et compromettre tous les comptes dMSA de l'ensemble des domaines de cette forêt.

Cela signifie qu'une seule extraction de clé racine KDS réussie se transforme en.. :

• Compromission de comptes inter-domaines. Aucune limite de domaine ne peut nous arrêter.
• Récolte d'informations d'identification à l'échelle de la forêt. Chaque dMSA de chaque domaine devient vulnérable.
• Mouvement latéral illimité. Nous pouvons passer d'un domaine à l'autre à volonté en utilisant des comptes dMSA compromis.
• Accès permanent. Sans expiration des clés KDS, cet accès peut durer indéfiniment.

L'attaque prend une ampleur exponentielle. Ce qui commence par la compromission d'un seul contrôleur de domaine (DC) aboutit à la prise de contrôle de tous les services protégés par dMSA au sein de l'ensemble de la forêt d'entreprise. Il ne s'agit pas seulement d'une élévation de privilèges. Il s'agit d'une domination numérique à l'échelle de l'entreprise via une seule vulnérabilité cryptographique.

Qu'est-ce que l'outil Golden dMSA ?

Pour savoir comment cette technique d'attaque est exploitée, nous avons repris la logique de l'attaque et l'avons incluse dans un outil appelé ^GoldenDMSA3. Cet outil reprend les principes structurels de l'outil^GoldenGMSA4.

Un attaquant peut utiliser l'outil GoldenDMSA pour énumérer tous les gMSA, dMSA et leurs clés racine KDS associées, utiliser des attaques par force brute pour obtenir leurs mots de passe et obtenir des tickets d'accès aux comptes. Un attaquant disposant de privilèges élevés peut également utiliser l'outil GoldenDMSA pour extraire les clés racine du KDS.

Pour montrer l'outil en action, examinons une exploitation entre les domaines d'une forêt.

Pour commencer, l'attaquant se trouve dans un domaine appelé child.root.test (Figure 30) et tente d'obtenir des dMSA à partir de root.test (Figure 31).

Ensuite, l'attaquant doit créer une liste de mots (Figure 32) qui sera utilisé pour le ManagedPasswordIds attaque par force brute.

Enfin, nous lancerons une attaque par force brute à l'aide de la liste de mots(figure 33).

Le mot de passe est encodé en Base64 (figure 34) car il peut contenir des caractères non imprimables. Pour vérifier la validité du ticket, j’ai créé un nouvel utilisateur — masqué dans le contrôleur de domaine racine — que seul le compte dMSA pouvait consulter. Si nous parvenons à lire les données de cet utilisateur, cela signifie que le ticket que nous avons généré est valide.

Comment détecter le Golden dMSA : découvrir les indicateurs cachés

Par défaut, aucun événement de sécurité n'est enregistré lorsqu'une clé racine KDS est compromise. Pour détecter les attaques Golden dMSA, les défenseurs doivent configurer manuellement une liste de contrôle d'accès au système (SACL) sur les objets de la clé racine KDS afin d'auditer l'accès en lecture aux objets de la clé racine KDS. msKds-RootKeyData attribut.

Pour ce faire, ouvrez l'outil Active Directory Editor Interface (ADSI Edit) et :

• Sélectionnez le contexte de dénomination de la configuration
• Naviguez vers Services, puis cliquez sur Service de distribution de clés de groupe.
• Sélectionnez Master Root Keys et cliquez avec le bouton droit de la souris sur la clé racine KDS concernée.
• Allez dans l'onglet Sécurité, cliquez sur le bouton Avancé
• Sélectionnez l'onglet Audit et configurez une règle d'audit pour l'accès en lecture sur Utilisateurs authentifiés/Tout le monde.

Lorsque cette SACL est en place, toute tentative non autorisée d'extraction des données de la clé racine du KDS déclenche l'événement de sécurité 4662 sur le DC (Figure 35). Cet événement affichera un type d'objet msKds-ProvRootKey et un nom de compte qui n'est pas un DC, ce qui indique une activité malveillante potentielle.

Le nouvel indicateur de sécurité de DSP facilite la détection du Golden dMSA

Comme vous pouvez le constater, la détection manuelle de la compromission de la clé racine du KDS est un défi pour la plupart des équipes. Semperis a fourni un nouveau module de protection des comptes de service, une amélioration des capacités de Directory Services Protector DSP. Le module comprend un indicateur de sécurité appelé KDS root key ACL was modified, qui recherche les modifications d'ACL sur les clés racine KDS(Figure 36) qui pourraient permettre aux attaquants de lire ces clés et de lancer une attaque Golden dMSA.

Autres indices à surveiller

En outre, les défenseurs doivent

• Surveiller les volumes anormaux de demandes d'authentification AS-REQ visant le même compte de service (identifiable par les comptes se terminant par $), en particulier lorsqu'il est suivi de PREAUTH-FAILED (code d'erreur 24). Ce schéma peut indiquer une tentative d'attaque de type Overpass the Hash.
• Recherchez les demandes anormales de Ticket-Granting Ticket (TGT) des comptes dMSA, en particulier lorsqu'elles sont lancées par des comptes d'utilisateurs.

Aperçu de Semperis

L'attaque « Golden dMSA » tire parti d'une vulnérabilité cryptographique susceptible de compromettre la dernière innovation de Microsoft en matière de sécurité dans Windows Server 2025. Cette technique exploite les fondements architecturaux des comptes de service gérés délégués. L'attaque tire parti d'une faille de conception critique : la ManagedPasswordId contient des composants prévisibles basés sur le temps avec seulement 1 024 combinaisons possibles, ce qui rend la génération de mots de passe par force brute triviale sur le plan informatique.

Ce qui rend cette faille particulièrement dévastatrice, c’est son ampleur à l’échelle de l’environnement. Une seule extraction réussie d’une clé permet un déplacement latéral inter-domaines et un accès persistant à tous les comptes de service gérés et à leurs ressources pour une durée indéterminée, puisque les clés racines KDS n’ont pas de date d’expiration. Cette vulnérabilité transforme la technologie de comptes de service la plus sécurisée de Microsoft en une porte dérobée potentielle à l’échelle de l’entreprise, contournant les protections modernes telles que Credential Guard et remettant fondamentalement en cause les avantages supposés en matière de sécurité de l’authentification liée à la machine.

Divulgation

Le problème a été initialement signalé au Microsoft Security Response Center (MSRC) le 27 mai 2025.

Le 8 juillet 2025, Microsoft a répondu en partie : « Si vous disposez des secrets utilisés pour dériver la clé, vous pouvez vous authentifier en tant que cet utilisateur. Ces fonctionnalités n’ont jamais été conçues pour protéger contre la compromission d’un contrôleur de domaine. »

En savoir plus sur les menaces pesant sur les comptes de services gérés

• BadSuccessor : Comment détecter et atténuer l'escalade des privilèges de dMSA
• Comment bloquer BadSuccessor
• Attaques de l'Active Directory de la gMSA

Notes de fin d'ouvrage

1. https://github.com/fortra/impacket/blob/master/examples/lookupsid.py
2. https://github.com/fortra/impacket/blob/master/examples/smbclient.py
3. https://github.com/Semperis/GoldenDMSA/tree/main
4. https://github.com/Semperis/GoldenGMSA

Clause de non-responsabilité

Ce contenu est fourni à des fins éducatives et informatives uniquement. Il vise à promouvoir la prise de conscience et la remédiation responsable des vulnérabilités de sécurité qui peuvent exister sur les systèmes que vous possédez ou que vous êtes autorisé à tester. L'utilisation non autorisée de ces informations à des fins malveillantes, d'exploitation ou d'accès illégal est strictement interdite. Semperis n'approuve ni ne tolère aucune activité illégale et décline toute responsabilité découlant d'une mauvaise utilisation du matériel. En outre, la Semperis ne garantit pas l'exactitude ou l'exhaustivité du contenu et n'assume aucune responsabilité pour les dommages résultant de son utilisation.