Jorge de Almeida Pinto

Principales conclusions

  • BadSuccessor, une technique d'escalade des privilèges qui exploite les comptes de services gérés délégués (dMSA), présente un risque élevé pour les organisations qui utilisent ne serait-ce qu'un contrôleur de domaine (DC) Windows Server 2025. Cette technique peut être utilisée pour usurper l'identité de n'importe quel compte dans Active Directory (AD) - même les administrateurs de domaine, le compte KRBTGT ou tout autre compte à haut privilège activé ou désactivé.
  • Jorge de Almeida Pinto, Senior Incident Response Lead de Semperis, a découvert un moyen de bloquer complètement le cas d'utilisation de la migration dMSA, ce qui empêche efficacement les attaquants d'utiliser abusivement un dMSA pour potentiellement prendre le contrôle d'un domaine AD.
  • La solution est configurée dans le schéma AD et doit être appliquée à chaque forêt AD.
  • Cette mesure d'atténuation des risques peut être mise en œuvre jusqu'à ce que Microsoft ait publié un correctif pour atténuer la vulnérabilité.

Jusqu'à Windows Server 2025, AD et Windows prenaient en charge les comptes de services gérés autonomes (sMSA) et les comptes de services gérés de groupe (gMSA). Windows Server 2025 introduit un nouveau type de compte de service géré : les comptes de service géré délégués.

Ce nouveau type de compte est conçu pour améliorer la gestion des justificatifs d'identité des comptes de service basés sur l'utilisateur en facilitant la migration du compte de service existant vers un dMSA.

Des chercheurs d'Akamai1 ont découvert que les attaquants peuvent facilement créer et configurer un dMSA, puis l'utiliser abusivement pour se faire passer pour n'importe quel principal de sécurité authentifiable dans AD. Ils ont baptisé cette technique d'attaque BadSuccessor.

Dans cet article de blog, nous fournissons une introduction détaillée et des informations pour atténuer la vulnérabilité, y compris le code PowerShell pour mettre en œuvre la solution suggérée pour bloquer le cas d'utilisation de la migration.

Pourquoi faut-il bloquer BadSuccessor ?

Lorsqu'elle est utilisée comme prévu, la migration dMSA ne prend officiellement en charge que les anciens comptes de service en tant que source (type de compte user). Cependant, l'attaque BadSuccessor fonctionne avec n'importe quel type de compte authentifiable comme source, y compris les comptes d'ordinateur, les sMSA, les gMSA et même les dMSA. En outre, le fait que le compte source soit activé ou désactivé n'a pas d'importance.

Les seuls composants nécessaires à l'exécution de cette attaque sont les suivants :

  • Au moins une DC 2025 inscriptible
  • Une dMSA (vulnérable) et l'outillage adéquat

En outre, il n'est pas nécessaire que l'attaque ait lieu sur Windows Server 2025.

Le cœur de l'attaque BadSuccessor commence par la possibilité de créer un nouveau dMSA ou de contrôler un dMSA existant. Ainsi, la délégation du contrôle d'un domaine AD existant nécessite un examen et une action immédiats.2

Compte tenu du risque de compromission totale du domaine AD, vous devez prendre des mesures pour atténuer ce risque dès que vous avez introduit votre premier DC inscriptible Windows Server 2025, même si vous n'utilisez pas encore de dMSA.

Comment détecter BadSuccessor : Indicateurs d'exposition et de compromission

Microsoft n'a pas encore fourni de correctif pour atténuer cette vulnérabilité. Semperis a ajouté des capacités de détection dans Directory Services Protector DSP) pour se défendre contre BadSuccessor. La plateforme DSP a été améliorée avec un nouvel indicateur d'exposition (IOE) et trois nouveaux indicateurs de compromission (IOC) axés sur la détection et l'atténuation des activités malveillantes impliquant des dMSA.

Quels sont les cas d'utilisation de la dMSA ?

Microsoft a conçu la dMSA pour un cas d'utilisation spécifique, difficile à résoudre, auquel sont confrontées de nombreuses organisations aujourd'hui. En pratique, une dMSA prend en charge deux cas d'utilisation.

En raison de la multiplicité des cas d'utilisation, toute dMSA a un état qui détermine la manière dont la dMSA est utilisée et qui est enregistré dans l'attribut msDS-DelegatedMSAState.

Les états pris en charge sont les suivants :

  • 0: Non utilisé (cet état est celui par défaut lorsqu'il n'est pas défini)
  • 1: Début de l'utilisation de la migration
  • 2: Utilisation de la migration - terminée
  • 3: Utilisation par les autochtones

Un dMSA peut être utilisé comme un gMSA. Dans ce cas, l'état de la dMSA sera 3, ce qui signifie qu'elle est utilisée de manière native.

Le dMSA a été conçu pour permettre la migration d'un compte de service existant vers un dMSA afin d'améliorer la gestion des informations d'identification sans affecter la fonctionnalité d'un service, d'une application ou d'une tâche planifiée qui utilise le compte de service existant. Une meilleure gestion des informations d'identification signifie techniquement une rotation plus fréquente et automatisée des mots de passe à l'aide d'un mot de passe plus fort et très complexe.

La migration du compte de service hérité vers le dMSA est initiée par un administrateur. L'état du compte de service hérité et du dMSA passe à 1-migration started. Une fois que l'administrateur a terminé la migration et que l'état du compte de service hérité et du dMSA devient 2-Migration terminée - la configuration spécifique du compte de service hérité est migrée vers le dMSA. Cependant, les appartenances de groupe du compte de service hérité ne sont pas migrées vers le dMSA et restent avec le compte de service hérité.

Au cours du premier état de migration, le système découvre automatiquement où le compte de service hérité est utilisé et configure le dMSA en conséquence. Dans le deuxième état de migration, lorsque le système tente de s'authentifier à l'aide du compte de service hérité (désactivé), le dMSA prend en charge l'authentification.

Lorsque le dMSA prend en charge l'authentification, le contrôleur de domaine Windows Server 2025 fusionne le certificat d'attributs privilégiés (PAC) du compte de service hérité et le PAC du dMSA en un seul PAC contenant toutes les appartenances de groupe combinées et autres objectSID applicables. Le dMSA hérite donc de tous les droits, autorisations et accès de l'utilisateur, de sorte qu'il peut remplacer l'ancien compte de service sans impact sur le service, l'application ou la tâche planifiée.

Le bon côté des choses : la succession des dMSA se déroule comme prévu

Les cmdlets PowerShell suivantes sont disponibles pour la migration d'un compte de service hérité vers un dMSA.

CMDlet PowerShellAction
Start-ADServiceAccountMigrationLancer la migration de l'ancien compte de service vers le dMSA. Cet état passe d'initial à démarré. Ne peut être exécuté que lorsque l'état est 0.
Complete-ADServiceAccountMigrationAchever la migration du compte de service existant vers le dMSA. Transitions de commencé à terminé. Ne peut être exécuté que lorsque l'état est 1.
Undo-ADServiceAccountMigrationAnnule la dernière étape de la migration et revient à l'étape précédente. Transitions de terminé à commencé ou de commencé à initial. Ne peuvent être exécutées que lorsque l'état est soit 1 ou 2.
Reset-ADServiceAccountMigrationRéinitialiser la migration à l'état initial, en annulant tout. Transitions de l'état terminé ou commencé à l'état initial. Ne peut être exécuté que lorsque l'état est soit 1 ou 2.

Selon la cmdlet PowerShell utilisée, un attribut opérationnel avec des données d'entrée est utilisé contre le RootDSE d'un DC inscriptible. Dans ce cas, plusieurs actions simultanées sont exécutées contre le compte de service hérité cible et le dMSA cible. Les cmdlets PowerShell ou l'attribut opérationnel ne peuvent être utilisés que par les membres du groupe Domain Admins.

Pour mieux comprendre ce que fait chaque cmdlet PowerShell, voici une description plus détaillée des actions.

Lors de l'utilisation de Start-ADServiceAccountMigrationLes actions suivantes sont exécutées par le système :

  • Sur le compte de l'ancien service :
    • Set (jeu de mots) msDS-SupersededServiceAccountState à 1
    • Set (jeu de mots) msDS-SupersededManagedAccountLink au DN de la dMSA ciblée
  • Sur le dMSA :
    • Set (jeu de mots) msDS-DelegatedMSAState à 1
    • Set (jeu de mots) msDS-ManagedAccountPrecededByLink à la DN du compte de l'ancien service visé
    • Attribuer des autorisations de lecture au compte de service hérité ciblé sur tous les attributs du dMSA ciblé.
    • Attribuer des droits d'écriture au compte du service hérité ciblé sur l'attribut msDS-GroupMSAMembership de la dMSA ciblée

Lors de l'utilisation de Complete-ADServiceAccountMigrationLes actions suivantes sont exécutées par le système :

  • Sur le compte de l'ancien service :
    • Set (jeu de mots) msDS-SupersededServiceAccountState à 2
    • Désactiver le compte
  • Sur le dMSA :
    • Set (jeu de mots) msDS-DelegatedMSAState à 2
    • Supprimer les autorisations de lecture précédemment attribuées au compte de service hérité ciblé dans tous les attributs du dMSA.
    • Supprimer les autorisations d'écriture précédemment attribuées au compte de l'ancien service ciblé dans l'attribut msDS-GroupMSAMembership de la dMSA
  • Depuis le compte de service hérité vers le dMSA, déplacez les configurations suivantes :
    • Noms des principaux services (SPN)
    • Autorisé à déléguer à la liste
    • Délégation restreinte basée sur les ressources
    • Politique d'authentification attribuée
    • Silo d'authentification assigné
    • Authentification de confiance pour la délégation UAC Bit

Lors de l'utilisation de Reset-ADServiceAccountMigrationtoutes les actions exécutées par l'un ou l'autre Start-ADServiceAccountMigration ou Complete-ADServiceAccountMigration sont annulées, et le compte de service hérité ainsi que le dMSA reviennent à leur état initial.

Lors de l'utilisation de Undo-ADServiceAccountMigrationtoutes les actions exécutées par l'un ou l'autre Start-ADServiceAccountMigration ou Complete-ADServiceAccountMigration sont annulées et le compte de service hérité et le dMSA reviennent tous deux à l'état précédant l'exécution de, respectivement, Start-ADServiceAccountMigration ou Complete-ADServiceAccountMigration. Techniquement, cela signifie l'une ou l'autre des transitions suivantes :

  • De l'achevé au commencé
  • Du début à la fin

Le mauvais et le laid : l'abus de dMSA

Comme l'ont découvert les chercheurs d'Akamai, les attributs du compte de service hérité et du dMSA impliqué dans la migration ne sont pas protégés contre les écritures LDAP ordinaires. Toute personne disposant au moins de l'autorisation Write Property sur les attributs du dMSA - ou de toute autre autorisation pouvant mener à cette autorisation - peut écrire des données. Malheureusement, cette faille invalide les protections mises en œuvre par la cmdlet PowerShell et l'attribut opérationnel sous le capot.

En outre, en termes de validation, le DC inscriptible Windows Server 2025 qui s'authentifie ne semble prendre en compte que deux attributs du dMSA et rien du compte de service hérité. Si le msDS-DelegatedMSAState de la dMSA est fixée à 2 (et peu importe comment il est arrivé à cet état), le DC vérifiera quel compte est spécifié dans le fichier msDS-ManagedAccountPrecededByLink attribut.

Avec ces informations, et en supposant que le compte demandeur (normalement un compte d'ordinateur, mais il peut s'agir de n'importe quoi) a les autorisations nécessaires pour demander le mot de passe ou les clés au dMSA, le DC authentifiant Windows Server 2025 inscriptible fusionne le certificat d'attribut privilégié (PAC) du compte de service hérité et du dMSA en un seul PAC. L'AD émet ensuite ce PAC fusionné dans un TGS-REP au compte demandeur.

Le nom distinctif (DN) du compte dans la base de données du msDS-ManagedAccountPrecededByLink peut être n'importe quoi - et BadSuccessor exploite pleinement cette vulnérabilité.

L'utilisation de la hiérarchisation administrative permet de masquer et de protéger vos comptes à privilèges élevés (utilisateurs, services, ordinateurs, sMSA, gMSA, dMSA). Il s'agit ici de "cacher" les comptes à haut privilège de sorte que leur DN ne soit pas visible par les comptes à faible privilège. Il est également important de noter que le DN des comptes à privilèges élevés ne doit pas être facilement devinable.

Cette attaque peut rapidement devenir un successeur très laid.

If an attacker knows the DN of the default domain Administrator account (CN=administrator,CN=Users, DC=<DOMAIN>,DC=<TLD>) or the KRBTGT account (CN=krbtgt,CN=Users,DC=<DOMAIN>,DC=<TLD>), they can misuse the controlled dMSA to completely take over the AD domain, and ultimately the AD forest.

REMARQUE : Le compte KRBTGT peut être déplacé dans un modèle de hiérarchisation protégé et caché, mais Microsoft ne recommande pas de le déplacer.3

REMARQUE : Le compte de l'administrateur peut être déplacé dans un modèle de hiérarchisation protégé et caché. Il est également possible de le renommer.4

Si vous décidez de déplacer le compte de l'administrateur du domaine par défaut ou le compte KRBTGT dans la structure administrative par niveaux, veillez à les placer dans une OU distincte (c'est-à-dire non combinée avec d'autres comptes) et à n'accorder l'accès à cette OU qu'aux comptes d'administrateurs de niveau 0.

Comment bloquer les successeurs

En examinant le fonctionnement interne actuel d'une dMSA du point de vue d'un "bon successeur" et d'un "mauvais successeur", les objectifs de ma recherche étaient les suivants :

  • A : Prise en charge de tous les cas d'utilisation décrits
  • B : Permettre et soutenir le bon successeur
  • C : Bloquer le mauvais et le vilain successeur

Les écritures LDAP régulières, telles que décrites pour le successeur mauvais et laid, nécessitent que l'acteur ait des permissions spécifiques sur un dMSA. L'utilisation des cmdlets PowerShell nécessite que l'acteur soit membre de Domain Admins.

Comme je l'ai indiqué précédemment, les cmdlets PowerShell effectuent différentes actions sur le compte de service hérité et sur le dMSA, en exploitant un attribut opérationnel avec des données d'entrée.

C'est dans cette optique que j'ai revu le schéma AD, et plus particulièrement la définition du schéma de l'élément msDS-ManagedAccountPrecededByLink car il permet de contrôler quel compte est migré (officiellement) ou attaqué (Figure 1).

Bien que l'attribut msDS-DelegatedMSAState joue un rôle important, il doit toujours être géré par l'exécution d'une écriture LDAP ordinaire pour pouvoir définir l'état de la dMSA à 3 lorsqu'il est utilisé de manière native plutôt qu'à des fins de migration.

Figure 1 : La définition originale du schéma AD de l'attribut msDS-ManagedAccountPrecededByLink avec systemOnly fixé à FALSE.

En examinant la définition de l'attribut affiché, mon intention était de bloquer les écritures LDAP régulières et de prendre en charge les écritures d'attributs opérationnels. Dans cette optique, la propriété systemOnly s'est démarquée, car j'espérais qu'elle permettrait d'atteindre l'objectif de la recherche. Cet attribut ne peut pas être modifié comme n'importe quel autre attribut ordinaire. Une fonctionnalité du DC doit d'abord être activée pour prendre en charge une action d'écriture spéciale, puis désactivée à nouveau. L'intention du bloc est d'empêcher l'écriture normale, tout en permettant la lecture.

Voyons cela étape par étape.

Figure 2 montre la vérification de la configuration de la dMSA dMSA.weak.5 Ce CSMO a son état initial et aucun compte n'y est lié (c'est-à-dire qu'aucun compte n'est affiché).

Figure 2 : Visualisation de la configuration de la dMSA : dMSA.weak

L'attaquant définit l'état de dMSA.weak à 2Il configure un compte lié (l'administrateur de domaine par défaut, qui a été renommé dans cet AD en ADM.TEC) et s'ajoute comme compte autorisé à récupérer le mot de passe/les clés du dMSA.6 (Figure 3). Dans ce cas, l'action est possible parce que l'attaquant possède un compte qui est membre du groupe des anciens opérateurs de compte.

Figure 3 : Reconfiguration dMSA.weak en cas d'utilisation abusive

Ensuite, nous vérifions la configuration de dMSA.weak5 (Figure 4).

Figure 4 : Visualisation de la configuration de dMSA.weak

La dMSA a maintenant l'état de migration terminé 2L'attaquant est autorisé à récupérer le mot de passe/les clés de la dMSA. En utilisant RUBEUS, par exemple, l'attaque peut être lancée contre le dMSA et en particulier contre le compte lié.

Ensuite, nous supprimons la configuration précédente6 et validons qu'elle a bien été supprimée5(Figure 5 et Figure 6).

Figure 5 : Suppression de la configuration précédemment définie de dMSA.weak
Figure 6 : Visualisation de la configuration de dMSA.weak

Nous pouvons maintenant voir l'état du bloc7(figure 7).

Figure 7 : Examen de l'état du bloc sur l'attribut (False indique qu'il n'est pas bloqué)

Ensuite, nous activons le bloc pour le scénario de migration8(figure 8).

Figure 8 : Activation du blocage de l'attribut (True indique un blocage)

Une fois de plus, nous confirmons en visualisant l'état du bloc7(figure 9).

Figure 9 : Examen de l'état du bloc sur l'attribut (True indique un blocage)

L'attaquant essaie à nouveau6 de :

  • Définir l'état de dMSA.weak à 2
  • Configurer un compte lié (toujours l'administrateur de domaine par défaut renommé)
  • S'ajouter comme compte autorisé à récupérer le mot de passe/les clés de la dMSA(Figure 10).

Maintenant, la transaction n'aboutit pas car l'attaquant n'est pas autorisé à écrire le DN du compte lié.
Objectif C atteint !

Figure 10 : Tentative de reconfiguration dMSA.weak en cas d'utilisation abusive

Maintenant, vérifions à nouveau la configuration de dMSA.weak5 (Figure11).

Figure 11 : Visualisation de la configuration de dMSA.weak

La transaction complète ayant échoué, rien n'a été modifié. Si les attributs avaient été écrits individuellement, ils auraient tous réussi, à l'exception de l'écriture dans le fichier msDS-ManagedAccountPrecededByLink attribut. Rien n'est affiché car il n'a pas de valeur.

Lorsque le blocage est activé, l'utilisation de la méthode officielle pour migrer un ancien compte de service vers un dMSA échoue également(figure 12). C'est regrettable. Mais il y a de la lumière au bout du tunnel !

Le bloc a pour but d'empêcher les écritures contre le msDS-ManagedAccountPrecededByLink attribut. Si l'on examine les cmdlets PowerShell officielles pour la migration, seules les cmdlets Start-ADServiceAccountMigration et Reset-ADServiceAccountMigration écrire dans cet attribut. La cmdlet Undo-ADServiceAccountMigration écrit également dans cet attribut lorsqu'il annule l'étape du passage de "commencé" à "initial". Dans les autres transitions, aucune écriture n'est nécessaire ou exécutée dans cet attribut.

Objectifs A et B : partiellement atteints.

Figure 12 : Lancement de la migration officielle d'un compte de service existant sVC.SQL à une dMSA appelée dMSA.SQL$

Ensuite, nous désactivons le bloc pour le scénario de migration9(figure 13).

Figure 13 : Désactivation du blocage de l'attribut (False indique qu'il n'est pas bloqué)

Nous visualisons à nouveau l'état du bloc7(figure 14).

Figure 14 : Examen de l'état du bloc sur l'attribut (False indique qu'il n'est pas bloqué)

Maintenant, lorsque l'attaquant tente6 de :

  • Définir l'état de dMSA.weak à 2
  • Configurer un compte lié (toujours l'administrateur de domaine par défaut renommé)
  • S'ajouter comme compte autorisé à récupérer le mot de passe/les clés de la dMSA

-Ils y parviennent car le bloc a de nouveau disparu(figure 15).

Figure 15 : Reconfiguration dMSA.weak en cas d'utilisation abusive

Maintenant, lorsque nous vérifions la configuration de dMSA.weak5 (Figure 16), nous voyons que l'attaquant a l'état de migration terminé 2a un compte lié à la dMSA et est autorisé à récupérer le mot de passe/les clés de la dMSA.

Figure 16 : Visualisation de la configuration de dMSA.weak

Avec le blocage désactivé, nous pouvons également utiliser la méthode officielle pour initier, compléter et réinitialiser avec succès la migration d'un compte de service hérité vers un dMSA(Figure 17). Pour cet exemple, un autre compte de service hérité et un dMSA ont été utilisés, et la migration a été exécutée par un compte d'administrateur de domaine.

Figure 17 : Initiation, achèvement et réinitialisation de la migration du compte de service hérité sVC.SQL à une dMSA nommée dMSA.SQL$

Le blocage de BadSuccessor nécessite une gestion pratique

Avec cette solution, il est possible de bloquer le scénario de migration des dMSA et donc toute utilisation abusive.

Nous encourageons toujours les organisations à revoir de manière proactive leur modèle de délégation2 et à agir en conséquence pour atténuer tout risque. Dans ce contexte, l'examen se concentre sur la création et la gestion des dMSA dans n'importe quel domaine AD.

Les organisations qui souhaitent mettre à niveau vers Windows Server 2025 AD ou installer un nouveau Windows Server 2025 AD peuvent mettre en œuvre cette solution pour atténuer les risques d'une attaque jusqu'à ce que Microsoft ait publié un correctif.

La mise en œuvre du blocage du scénario de migration s'effectue dans le schéma AD, et le changement est réversible : Vous pouvez définir le blocage sur 8 et, à un stade ultérieur, le débloquer sur 7. Cela signifie que plusieurs approches de gestion sont possibles.

Votre organisation peut mettre en œuvre ce bloc parce qu'elle ne souhaite pas utiliser les dMSA pour le scénario de migration.

Si votre organisation souhaite utiliser des dMSA pour le scénario de migration, vous pouvez toujours mettre en œuvre le blocage pour protéger AD. Chaque fois que vous souhaitez initier la migration d'un compte, vous pouvez supprimer le blocage à l'avance et le réimplémenter par la suite. Vous pouvez terminer la migration d'un compte avec ou sans le blocage.

Cette approche permet d'atteindre les objectifs A, B et C.

Même si vous mettez en œuvre un bloc, les IOE et IOC de Semperis DSP permettent de suivre de près les événements de création, de gestion et d'authentification des dMSA ainsi que les modifications d'attributs.

En savoir plus sur les dangers des privilèges excessifs dans AD

Notes de fin d'ouvrage

  1. BadSuccessor : Abuser de dMSA pour escalader les privilèges dans Active Directory
  2. (2025-05-25) Révision du modèle de délégation avant l'introduction des DC W2K25 et l'amélioration de la sécurité (à cause de "BadSuccessor")
  3. Microsoft Learn : Attributs du compte KRBTGT
  4. Microsoft Learn : Compte administrateur
  5. Bad Successor - VIEW DATA IN ATTRIBUTES "msDS-groupMSAMembership", "msDS-DelegatedMSAState", "msDS-ManagedAccountPrecededByLink"
  6. Bad Successor - WRITE DATA INTO ATTRIBUTES "msDS-groupMSAMembership", "msDS-DelegatedMSAState", "msDS-ManagedAccountPrecededByLink"
  7. Mauvais successeur - VOIR L'ÉTAT DU BLOC
  8. Bad Successor - BLOC D'ADDING/ENABLING
  9. Mauvais successeur - SUPPRESSION/DÉSABLISSEMENT DU BLOC

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.