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 importantes en matière de sécurité, notamment l'introduction de 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 victimes 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 le problème de la limitation à plusieurs machines, en permettant le partage des identités de service entre les clusters, les équilibreurs de charge et les services distribués, tout en conservant les avantages du MSA en matière de sécurité.
• Comptes de services gérés délégués (dMSA). La dernière innovation de Windows Server 2025 passe d'une gestion centralisée des mots de passe à une authentification liée à la machine, ce qui représente un changement fondamental dans la 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é d'énumérer les dMSA en tant qu'utilisateur non privilégié est cruciale pour l'escalade des privilèges et le mouvement latéral. Pour obtenir le mot de passe d'une dMSA, vous devez 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, nous commençons par l'option CreateDelegatedServiceAccount commande qui Figure 1 montre.

Voici maintenant la partie la plus amusante. Essayons d'afficher notre compte DMSA-Demo nouvellement créé à l'aide de la fonction Get-ADServiceAccount (Figure 2).

C'est là que nous rencontrons notre premier obstacle. Un utilisateur privilégié peut consulter le compte sans problème, mais un utilisateur non privilégié n'obtient absolument rien - des résultats vides(Figure 3). Pourquoi ? Tout se résume aux valeurs par défaut des listes de contrôle d'accès (ACL) du compte. Et croyez-moi, aucun administrateur n'a envie de les modifier.

Vous avez remarqué quelque chose de suspect dans la figure 4? Les utilisateurs authentifiés et Tout le monde 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 indiquent leur fonction, mais la figure 6 montre la documentation officielle de Microsoft pour la rendre parfaitement claire.

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 la plus excitante : Voyons ce qui se passe lorsque nous libérons ces fonctions Win32(figure 7).

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

Cette méthode réussit parce qu'elle contourne complètement LDAP, en contournant effectivement ces ACL restrictives. Voici la beauté technique : LsaLookupSids et LsaOpenPolicy ne s'appuient pas du tout sur LDAP. Au lieu de cela, le protocole LSA communique par l'intermédiaire de \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 la partie la plus astucieuse : Nous signalons tous les comptes se terminant par $ comme suspects. Ensuite, nous éliminons systématiquement les comptes machines et les gMSA.

Voilà ! Nous disposons d'un inventaire complet de tous les dMSA du 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 découvert une autre approche basée sur 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 la couronne de l'infrastructure gMSA de Microsoft. Il s'agit du cerveau cryptographique du service de distribution de clés de Microsoft, le moteur qui génère et distribue les mots de passe pour les 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 la rend si puissante : La clé racine KDS fonctionne comme la clé maîtresse ultime. C'est à partir de cette clé que tous les mots de passe gMSA sont dérivés grâce à un élégant processus de dérivation de clé.

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 réside généralement sur le DC racine de la forêt, c'est-à-dire sur le site le plus protégé d'AD. Microsoft n'a pas joué avec la sécurité ici. Les listes de contrôle d'accès à ces clés sont incroyablement restrictives(figure 10) et limitent l'accès aux seuls comptes les plus privilégiés : les administrateurs de domaine racine, les administrateurs d'entreprise 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.

Au cours de mes recherches, j'ai découvert quelque chose d'encore plus intriguant. Même dans les environnements comportant plusieurs clés racine KDS, le système utilise systématiquement la première clé racine KDS (la plus ancienne) pour des raisons de compatibilité. Cela signifie que la clé originale que nous avons compromise pourrait être préservée par la conception de Microsoft, créant ainsi une porte dérobée persistante qui pourrait durer 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 plonger au cœur de l'attaque, en extrayant les données de la dMSA. ManagedPasswordId attribut.

ManagedPasswordId est un attribut stocké dans AD qui contient les métadonnées nécessaires pour dériver le mot de passe actuel d'une MSA. Nous devons acquérir 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 de dérivation - qui, associés à la clé racine du KDS, permettent de calculer mathématiquement le mot de passe actuel de la gMSA.

Si cela vous semble familier, vous avez tout à fait raison. L'excellente recherche de Yuval Gordon sur les 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 ici que nous rencontrons notre premier obstacle majeur. Les ACL restrictives que nous avons découvertes précédemment nous empêchent complètement de lire ces données critiques sur les comptes dMSA. Nous avons dû approfondir 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 semble familière. Elle est pratiquement identique à celle de la 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 l'étudierons plus tard)
• L1Index : Valeur entière représentant une variable temporelle (nous l'étudierons plus tard)
• L2Index : Valeur entière représentant une variable temporelle (nous l'étudierons 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 expire, le système établit une nouvelle heure de début et appelle la fonction 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 quelque chose de crucial : Les valeurs L1 et L2 sont limitées à 31 (inclus). Ce n'est pas une simple théorie ; c'est confirmé à la fois dans la DLL (Figure 19) et 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 creusant davantage l'algorithme de Golden gMSA, j'ai découvert qu'il crée ces objets :

• 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 ce qu'il faut savoir.

• 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 testé 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" en utilisant le ^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 indique que "le secret de dMSA ne peut être récupéré ou trouvé nulle part ailleurs que sur le DC", ce qui souligne 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 informations d'identification de la gMSA (mot de passe), puis reçoit le mot de passe réel à des fins d'authentification.

Les dMSA fonctionnent selon un principe totalement différent. Ils doivent s'authentifier en utilisant l'identité de la machine pour obtenir un ticket pour l'utilisateur de la dMSA. Le mot de passe du dMSA ne quitte jamais le DC. Il est utilisé pour 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 tout. Golden dMSA contourne complètement les protections normales de Credential Guard(Figure 28). Nous ne respectons plus les règles d'authentification habituelles.

Au lieu de suivre le flux d'authentification prévu par Microsoft, les informations d'identification dMSA sont utilisées directement à l'aide de l'attaque cryptographique(figure 29). Cela signifie que :

• Aucune identité de machine n'est requise. Il n'est pas nécessaire de compromettre la machine hôte.
• Credential Guard n'a plus aucune raison d'être. Puisque nous ne volons pas les informations d'identification des machines, cette protection n'offre aucune défense.

Microsoft a reconnu que, "À partir de la mise à jour de sécurité Windows d'avril(KB5055523), les comptes machine protégés par Credential Guard sont temporairement désactivés dans 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 de la machine à l'aide de Kerberos. La fonctionnalité reste désactivée jusqu'à ce qu'un correctif permanent 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 seulement d'obtenir l'accès à un compte de service. Il s'agit de tirer parti de ce point d'appui pour effectuer un mouvement latéral dévastateur. En outre, cette technique permet aux attaquants de déchiffrer les mots de passe et d'obtenir les autorisations des comptes de service qui ont commencé et terminé leur migration vers le dMSA compromis.

C'est ici que l'attaque devient vraiment terrifiante du point de vue de la sécurité. L'attaque Golden dMSA n'est pas limitée par les frontières des domaines. Elle opère au niveau de la forêt. Une fois que nous avons compromis la clé racine KDS d'un seul domaine de la forêt, nous pouvons systématiquement cibler et compromettre chaque compte dMSA dans tous les 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 s'étend de manière exponentielle. Ce qui commence par la compromission d'un DC s'intensifie jusqu'à la possession de chaque service protégé par dMSA dans toute la forêt d'une entreprise. Il ne s'agit pas seulement d'une escalade des privilèges. Il s'agit d'une domination numérique à l'échelle de l'entreprise par le biais d'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 tester la validité du ticket, j'ai créé un nouvel utilisateur - caché dans le DC racine - que seul le compte dMSA peut lire. Si nous parvenons à lire les données de l'utilisateur, nous savons que le ticket 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 exploite une vulnérabilité cryptographique qui peut compromettre la dernière innovation de Microsoft en matière de sécurité dans Windows Server 2025. Cette technique exploite le fondement architectural des comptes de services gérés délégués. L'attaque s'appuie sur un défaut de conception critique : le système d'authentification des comptes de services gérés délégués. 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 ce phénomène particulièrement dévastateur, c'est sa portée à l'échelle de la forêt. Une seule extraction de clé réussie permet un mouvement latéral entre les domaines et un accès permanent à tous les comptes de service gérés et à leurs ressources, et ce indéfiniment, puisque les clés racine KDS n'ont pas de date d'expiration. Cette vulnérabilité transforme la technologie de compte de service la plus sûre 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 question les avantages supposés de l'authentification liée à la machine en matière de sécurité.

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 qu'utilisateur. Ces fonctionnalités n'ont jamais été destinées à 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.