BadSuccessor dMSA Privilege Escalation : comment un utilisateur à faibles privilèges devient Domain Admin

BadSuccessor dMSA privilege escalation — baptisée BadSuccessor par Akamai — est une technique qui abuse des Delegated Managed Service Accounts (dMSA), une fonctionnalité introduite dans Windows Server 2025, pour permettre à un utilisateur à faibles privilèges d'usurper n'importe quel compte du domaine, jusqu'à Domain Admin. Elle a été documentée par le chercheur Akamai Yuval Gordon en mai 2025 et s'est vu attribuer l'identifiant CVE-2025-53779 ; Microsoft a livré un correctif dans la mise à jour de sécurité du 12 août 2025 (KB5064010).

Cet article explique le mécanisme, pourquoi il touche une si large part des environnements réels, et comment le détecter et le corriger — y compris ce que le correctif a réellement changé et ce que la recherche publique dit qu'il reste à surveiller après coup.

Pour les chemins d'escalade Active Directory voisins, voir Délégation Kerberos non contrainte : de l'abus à RBCD et Abus ACL et DCSync : les chemins silencieux vers Domain Admin. BadSuccessor est un mécanisme distinct des deux — il ne touche ni les ACL ni les paramètres de délégation d'un compte existant ; il abuse des droits de création d'objets sur une OU pour en fabriquer un nouveau. Il partage aussi un air de famille avec Shadow Credentials : abuser de msDS-KeyCredentialLink dans Active Directory — les deux techniques escaladent les privilèges en écrivant dans un attribut de liaison d'identité plutôt qu'en cassant un identifiant.

Qu'est-ce que BadSuccessor dMSA Privilege Escalation ?

Les Delegated Managed Service Accounts (dMSA) sont une fonctionnalité de Windows Server 2025 conçue pour permettre aux organisations de migrer d'anciens comptes de service vers un modèle d'identité géré, sans mot de passe, sans avoir à re-provisionner chaque dépendance. Cette conception de migration inclut un mécanisme de « succession » : un dMSA peut être lié à un ancien compte qu'il est censé remplacer, et Active Directory reporte une partie des accès de ce compte pendant la transition.

Pourquoi le dMSA existe

Microsoft a conçu le dMSA pour résoudre un vrai problème opérationnel : les anciens comptes de service autonomes portent souvent des mots de passe statiques, rarement renouvelés, et des privilèges étendus, car migrer vers un modèle d'identité géré impliquait traditionnellement de re-provisionner chaque application dépendante. Le modèle de succession du dMSA — lier le nouveau compte géré à l'ancien qu'il remplace — visait à rendre cette migration quasi transparente. BadSuccessor abuse de la confiance intégrée à cette transparence, pas d'un bug dans la gestion des mots de passe elle-même.

Le mécanisme BadSuccessor

Selon la recherche originale d'Akamai (corroborée par Unit 42, Semperis et Tarlogic), l'attaque abuse de deux attributs dMSA que le KDC accepte sans vérification croisée pendant la « migration » qu'ils sont censés représenter :

• msDS-ManagedAccountPrecededByLink — un lien (DN, distinguished name) vers le compte que le dMSA est censé « succéder ». La recherche publique décrit le KDC pré-correctif comme construisant le PAC (Privilege Attribute Certificate) du compte à partir de n'importe quel DN présent dans ce champ, sans vérifier qu'une véritable relation de migration existe.
• msDS-DelegatedMSAState — l'état de migration (0 = aucun, 1 = en cours, 2 = terminé).

Étape par étape : comment fonctionnait l'attaque pré-correctif

1. L'attaquant identifie une OU ou un conteneur où il détient les droits CreateChild — selon les tests d'Akamai, un droit à la fois courant et rarement audité de près.
2. L'attaquant crée un nouvel objet dMSA dans cette OU.
3. L'attaquant écrit le DN du compte cible (par exemple, un Domain Admin) dans msDS-ManagedAccountPrecededByLink.
4. L'attaquant définit msDS-DelegatedMSAState à 2 (« terminé »), marquant la migration fabriquée comme achevée.
5. La recherche publique décrit le KDC pré-correctif traitant ensuite chaque authentification en tant que dMSA comme une continuation de l'identité du compte cible — construisant le PAC avec les SID et appartenances de groupe de la cible, sans jamais modifier le compte cible lui-même.

Les tests d'Akamai ont rapporté que 91 % des environnements examinés comptaient au moins un utilisateur non-admin disposant des droits suffisants pour réaliser cette attaque, en grande partie parce que la délégation CreateChild au niveau des OU est courante et rarement auditée de près.

Impact du correctif d'août 2025

La mise à jour du 12 août 2025 de Microsoft (KB5064010, CVE-2025-53779) a changé la façon dont kdcsvc.dll valide la relation de succession : l'émission de tickets exige désormais que le lien reflète un appariement mutuel authentique plutôt que d'accepter une écriture à sens unique de msDS-ManagedAccountPrecededByLink. Le simple fait de pointer un dMSA nouvellement créé vers un compte privilégié, comme décrit ci-dessus, ne produit plus de ticket d'usurpation après la mise à jour.

L'évaluation de sévérité de Microsoft

MSRC a initialement évalué le problème signalé comme ne franchissant pas le seuil d'un correctif immédiat et l'a jugé de sévérité modérée lorsqu'Akamai l'a signalé pour la première fois ; il a été livré comme un correctif standard dans le cycle Patch Tuesday d'août 2025, plutôt que comme une publication hors bande. L'évaluation actuelle de Microsoft juge l'exploitation « peu probable », et les informations publiques ne décrivent, à la date de publication, aucune exploitation confirmée dans la nature.

Ce que dit la recherche sur le correctif

La recherche de suivi d'Akamai elle-même (« BadSuccessor Is Dead, Long Live BadSuccessor(?) ») et un article de suivi de la communauté publié par AlteredSecurity (« BetterSuccessor ») décrivent tous deux le correctif comme fermant le chemin direct à lien unilatéral, tout en notant que la recherche sur l'abus des dMSA s'est poursuivie dans des scénarios plus étroits. Cet article ne reproduit pas ces techniques dérivées ; considérez que le correctif ferme substantiellement — pas forcément totalement — le chemin BadSuccessor d'origine, et priorisez les étapes de détection et de durcissement de la délégation ci-dessous, indépendamment du statut du correctif.

Pourquoi c'est si répandu

BadSuccessor est inhabituelle parmi les techniques d'escalade de privilèges AD car elle ne nécessite pas de mauvaise configuration au sens traditionnel. Elle fonctionne contre le modèle de permissions par défaut du dMSA dès qu'un DC Windows Server 2025 existe dans le domaine. L'exposition réelle vient de l'étendue avec laquelle les droits CreateChild sur les OU et conteneurs sont délégués dans les environnements réels — souvent à des équipes de support, des équipes applicatives, ou des délégations héritées jamais réexaminées. La recherche publique de Semperis et Unit 42 pointe toutes deux vers la même cause racine : des pratiques de délégation d'OU et de racine de domaine plus larges que prévu, pas un simple correctif manquant.

Cela rejoint directement un schéma traité dans Chemins d'attaque AD : comment les mauvaises configurations s'enchaînent : les expositions les plus dangereuses ne sont presque jamais un bug critique isolé — ce sont des délégations et des permissions accumulées que personne n'a réexaminées depuis leur création.

Détection

Remédiation

1. Corriger en premier

Appliquez la mise à jour de sécurité du 12 août 2025 (KB5064010 / CVE-2025-53779) sur chaque contrôleur de domaine Windows Server 2025.

2. Auditer et restreindre la délégation CreateChild

Passez en revue les permissions des OU et de la racine de domaine pour les comptes et groupes pouvant créer des objets — en particulier des objets msDS-DelegatedManagedServiceAccount — et retirez les délégations qui ne sont pas activement nécessaires. C'est ce contrôle qui détermine si le chemin d'attaque existe, indépendamment du statut du correctif.

3. Activer l'audit basé sur les SACL

Configurez l'audit pour la création d'objets dMSA (ID d'événement 5137) et pour les modifications de msDS-ManagedAccountPrecededByLink / msDS-DelegatedMSAState (ID d'événement 5136), et alertez sur tout changement de ce type effectué par un compte non privilégié.

4. Inventorier les dMSA existants

Confirmez que chaque dMSA du domaine correspond à une migration légitime attendue, et vérifiez la valeur de msDS-ManagedAccountPrecededByLink pour chacun.

# Inventorier tous les objets dMSA et leur lien de succession, pour revue manuelle
Get-ADServiceAccount -Filter "ObjectClass -eq 'msDS-DelegatedManagedServiceAccount'" -Properties msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState |
  Select-Object Name, msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState

Comment EtcSec détecte ceci

Le catalogue de vulnérabilités AD d'EtcSec inclut un contrôle dédié, BADSUCCESSOR_DMSA_ESCALATION, qui signale ce risque d'escalade dMSA. Comme l'exposition racine est l'étendue de la délégation plutôt qu'un objet mal configuré isolé, EtcSec fait aussi remonter les constats DELEGATION_PRIVILEGE — délégations larges au niveau des OU ou de la racine de domaine — comme la condition sous-jacente qui rend BadSuccessor viable dans un environnement donné, indépendamment de la présence ou non d'un DC Windows Server 2025. Les équipes qui suivent déjà la dérive des accès privilégiés avec Dérive des accès privilégiés Active Directory : comment les droits admin reviennent après un audit observent le même problème sous-jacent — une délégation jamais réexaminée — sous un angle différent.

Références principales

• Akamai : BadSuccessor — Abusing dMSA to Escalate Privileges in Active Directory
• Akamai : BadSuccessor Is Dead, Long Live BadSuccessor(?)
• Microsoft Security Update Guide : CVE-2025-53779
• NVD : CVE-2025-53779
• Help Net Security : Microsoft fixes "BadSuccessor" Kerberos vulnerability (CVE-2025-53779)
• Unit 42 (Palo Alto Networks) : When Good Accounts Go Bad — Exploiting Delegated Managed Service Accounts in Active Directory
• Semperis : BadSuccessor — How to Detect and Mitigate dMSA Privilege Escalation
• Tarlogic : BadSuccessor — Escalating Privilege Using dMSA Abuse in Active Directory
• AlteredSecurity : BetterSuccessor — Still Abusing dMSA for Privilege Escalation (BadSuccessor After Patch)