BadSuccessor : le correctif dMSA ne suffit pas

BadSuccessor : le correctif dMSA ne suffit pas — illustration Ctrl+Alt+Prod (BadSuccessor dMSA)

Windows Server 2025 a introduit les delegated Managed Service Accounts (dMSA), pensés pour migrer en douceur les comptes de service hérités. On avait couvert les principaux changements sécurité de cette version pour Active Directory dans cet article — les dMSA n’y figuraient pas encore comme un risque, et c’est justement le sujet du jour. Quelques mois après leur sortie, le chercheur Yuval Gordon (Akamai) a montré qu’ils ouvraient une voie d’élévation de privilèges vers n’importe quel compte du domaine — y compris un Domain Admin — sans toucher à un seul contrôleur de domaine. Le nom retenu : BadSuccessor.

Microsoft a corrigé la faille originale (CVE-2025-53779) lors d’un Patch Tuesday d’août 2025 qui corrigeait 107 CVE au total. Le problème : le correctif ferme une porte, pas la pièce entière. Une variante post-patch reste exploitable aujourd’hui, et si tu as un seul contrôleur de domaine Windows Server 2025 dans ton environnement, ça te concerne directement.

Pourquoi un simple droit sur une OU suffisait à devenir Domain Admin

Un dMSA référence le compte qu’il remplace via l’attribut msDS-ManagedAccountPrecededByLink. Avant le correctif, le KDC construisait le PAC (Privilege Attribute Certificate) du dMSA à partir de ce seul attribut, sans vérifier que le lien était réciproque. Concrètement : si tu pouvais créer un dMSA — ce qui ne demande que le droit CreateChild sur une unité d’organisation — tu pouvais le faire pointer vers n’importe quel compte, récupérer ses privilèges effectifs et ses clés Kerberos dès l’authentification suivante.

Le chiffre qui donne la mesure du problème : selon l’analyse d’Akamai, 91 % des environnements Active Directory examinés accordaient ce droit CreateChild à au moins un utilisateur hors Domain Admins sur au moins une OU. Autrement dit, la plupart des forêts avaient déjà, sans le savoir, la précondition réunie.

Ce que le correctif a réellement changé

Le patch agit dans kdcsvc.dll : le KDC exige désormais un appairage mutuel au moment de l’émission du ticket. Le compte cible doit lui aussi référencer le dMSA en retour, via les attributs msDS-SupersededManagedAccountLink et msDS-SupersededServiceAccountState. Un lien à sens unique — celui que BadSuccessor original exploitait — ne produit plus de ticket. L’escalade directe, sans aucun droit sur le compte cible, est fermée.

La variante qui survit : forger l’appairage

Ces nouveaux attributs ne sont pas protégés en écriture. Si tu disposes à la fois de CreateChild sur une OU et de GenericWrite sur le compte cible, tu peux écrire toi-même les deux côtés du lien et obtenir un appairage valide aux yeux du KDC. Résultat : tu t’authentifies en tant que dMSA et récupères le paquet de clés contenant les clés Kerberos du compte cible.

C’est présenté comme une alternative ciblée au DCSync classique — sans passer par l’interface de réplication DRS, donc sans les signatures de détection habituelles associées à une réplication anormale. Deux risques résiduels concrets, donc : l’obtention d’identifiants via appairage forgé, et l’extraction de secrets dans un domaine déjà partiellement compromis.

Comment détecter une tentative

Avant même de promouvoir ton premier contrôleur de domaine Windows Server 2025, active l’audit « Audit Directory Service Changes » (sous-catégorie DS Access) sur l’ensemble de tes DC, et pose des SACL sur les objets dMSA. Les événements à surveiller :

  • 5137 — création d’un dMSA
  • 5136 — modification d’un attribut sur un objet existant
  • 2946 et 4768/4769 — émission de TGT/TGS pour un dMSA
  • 4662 — solution de repli si les événements ci-dessus ne sont pas disponibles, mais à filtrer impérativement par GUID de schéma pour éviter une surcharge de ton SIEM

Cinq attributs méritent une surveillance dédiée : msDS-GroupMSAMembership, msDS-ManagedAccountPrecededByLink, msDS-SupersededManagedAccountLink, msDS-SupersededServiceAccountState et msDS-DelegatedMSAState. L’enjeu réel n’est pas de repérer un dMSA isolé — c’est de corréler, dans une fenêtre de quelques minutes, la séquence création → appairage → authentification, en tenant compte du décalage horaire entre contrôleurs de domaine. Si tu veux revoir comment Kerberos a évolué sur tes DC cette année, on avait couvert la bascule RC4 dans cet article.

Ce qu’il faut faire, dans l’ordre

D’abord, vérifie que le correctif d’août 2025 est appliqué sur tous tes contrôleurs de domaine — ça ferme la voie d’escalade la plus simple, sans aucune précondition sur le compte cible. Ensuite, et c’est le point que la plupart des équipes négligent : traite les dMSA comme du matériel d’identité Tier 0. Audite les délégations CreateChild sur tes OU avec BloodHound, retire ce droit à tout compte qui n’en a pas explicitement besoin, et fais le même ménage sur les GenericWrite superflus sur tes comptes sensibles.

Le correctif Microsoft referme une porte spécifique. Les permissions ACL de ton annuaire restent, elles, la vraie barrière — et c’est celle qui ne se corrige pas avec un Patch Tuesday.

FAQ

Suis-je concerné si je n’utilise pas encore les dMSA ?

Le risque apparaît dès qu’un contrôleur de domaine Windows Server 2025 est promu dans ton domaine, même si tu n’as créé aucun dMSA volontairement — l’évaluation se fait domaine par domaine, pas à l’échelle de la forêt entière.

Le correctif d’août 2025 est-il suffisant à lui seul ?

Il ferme l’escalade originale sans précondition sur la cible, ce qui est déjà la partie la plus dangereuse. Mais la variante à appairage forgé reste possible si les permissions CreateChild/GenericWrite ne sont pas resserrées.

Comment repérer les droits CreateChild à risque sur mes OU ?

BloodHound reste l’outil de référence pour cartographier ce type de délégation ; combine-le avec un audit SACL avant de promouvoir ton premier DC Windows Server 2025, pas après.

Prochaine étape

Si tu as déjà des contrôleurs de domaine Windows Server 2025, vérifie dès aujourd’hui la présence du correctif CVE-2025-53779 sur chacun d’eux, puis lance un audit BloodHound des droits CreateChild sur tes OU. C’est le genre de chantier qu’on repousse facilement — jusqu’au jour où un pentest ou un incident le fait remonter à ta place.

Commentaires

Une réponse à « BadSuccessor : le correctif dMSA ne suffit pas »

  1. […] être industrialisé dans des frameworks d’attaque une fois le mécanisme bien documenté, comme ça a été le cas pour BadSuccessor quelques mois plus […]

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *