Sommaire
Synthèse
- Les chercheurs d'Akamai ont analysé le correctif de Microsoft pour la vulnérabilité appelée BadSuccessor (CVE-2025-53779) afin d'évaluer son efficacité.
- Nous avons conclu que, bien que le correctif ait été efficace pour atténuer une part importante du risque lié à BadSuccessor, cette technique n'a pas dit son dernier mot et reste pertinente dans certains scénarios.
- Dans cet article de blog, nous présentons en détail deux techniques reposant sur les mêmes principes que BadSuccessor et permettant aux attaquants de récupérer des identifiants et de compromettre des comptes utilisateur.
Lors de la DEF CON 2025, nous avons présenté l'histoire de BadSuccessor, une vulnérabilité d'Active Directory (AD) qui exploite le nouveau type de compte de Windows Server 2025 : le compte de service géré délégué (dMSA). Cette vulnérabilité permet à un utilisateur à faible privilège de passer directement au niveau administrateur de domaine.
Moins d'une semaine plus tard, Microsoft a attribué l'identifiant CVE-2025-53779 à la vulnérabilité et publié un correctif. La voie d'élévation directe est désormais fermée.
Dans cet article de blog, nous allons analyser le correctif, expliquer ce qui a changé et ce qui reste inchangé, et montrer que, bien que BadSuccessor ne permette plus une élévation instantanée, ses mécanismes sous-jacents restent pertinents.
Pour comprendre les origines de BadSuccessor, lisez notre précédent article de blog sur BadSuccessor.
Qu'était BadSuccessor (avant le correctif) ?
BadSuccessor exploitait le dMSA, un type de compte Windows Server 2025 destiné à simplifier la gestion des comptes de service. Lorsqu'un dMSA contrôlé était lié à un compte dans AD, le centre de distribution de clés (KDC) le considérait comme le successeur lors de l'authentification.
Ce lien entraînait deux actions dangereuses à la fois : la fusion des privilèges effectifs du compte cible dans le Privilege Attribute Certificate (PAC) du dMSA et le renvoi d'un package de clés dMSA contenant les clés Kerberos (identifiants) de la cible. Aucune modification de groupe, aucun outil exotique : un simple lien et des utilitaires Windows intégrés.
Ce qui est préoccupant, c'est que le seuil d'entrée était très bas : il suffisait de prendre le contrôle de n'importe quelle unité organisationnelle (OU). Un attaquant pouvait y créer un dMSA et le lier à n'importe quelle cible, y compris les contrôleurs de domaine, les administrateurs de domaine, les utilisateurs protégés ou les comptes marqués comme « sensibles et ne pouvant pas être délégués », et les compromettre immédiatement.
Pour en savoir plus et regarder une démonstration, consultez notre précédent article de blog sur BadSuccessor.
Correctif Microsoft pour CVE-2025-53779
Avant le correctif, notre hypothèse était simple : le bug principal était qu'une migration réelle via l'opération rootDSE migrateADServiceAccount n'était pas requise. Une simple modification des attributs de lien d'un dMSA suffisait pour que le KDC l'accepte.
Nous nous attendions à ce que Microsoft protège cet attribut afin que seul le chemin de migration approprié puisse le définir, ce qui empêcherait les migrations « simulées ».
Après avoir installé le correctif, nous avons tenté un test évident : en tant qu'utilisateur contrôlant un dMSA, j'ai écrit l'attribut de lien exactement comme auparavant. L'écriture a réussi (pas de nouvelle protection sur l'attribut) et j'ai pu lier un dMSA à n'importe quel compte. Mais lorsque je me suis authentifié en tant que dMSA pour « hériter » des privilèges et des clés de la cible, le KDC a refusé d'émettre un ticket (Figure).
The error when authenticating a dMSA with a one-sided link — failure occurs at ticket issuance
Nous nous sommes donc penchés sur le KDC. Les modifications apportées au fichier kdcsvc.dll obligent le KDC à valider la relation au moment du ticket. Un lien unidirectionnel du dMSA vers la cible ne fonctionne plus.
Dans notre test, la seule façon d'obtenir un ticket valide pour un dMSA lié à un autre compte après le correctif a consisté à rendre le lien mutuel : la cible doit également faire référence au dMSA, comme le ferait une migration réelle. Ainsi, contrairement à auparavant, la « réussite » nécessite désormais de contrôler l'objet du compte lui-même, et pas seulement le dMSA.
Cela signifie que l'application du correctif a été mise en œuvre dans la validation du KDC, et non dans les protections côté répertoire de l'attribut. L'attribut peut toujours être écrit, mais le KDC ne le prend en compte que si le lien ressemble à une migration légitime.
Un autre fait intéressant est que la migration continue de fonctionner même si le compte cible reste activé (alors que le flux de migration formel le désactive une fois terminé).
Qu'est devenu BadSuccessor (après le correctif) ?
Bien que la vulnérabilité ait pu être corrigée, la technique BadSuccessor reste exploitable, c'est-à-dire quela vérification du KDC supprime la voie d'élévation avant correctif, mais n'atténue pas l'intégralité du problème.
Comme le correctif n'a pas introduit de protection pour l'attribut de lien, un attaquant peut toujours hériter d'un autre compte en liant un dMSA contrôlé et un compte cible.
Ce constat permet (au moins) deux primitives pratiques que les défenseurs doivent connaître et surveiller :
- Acquisition d'identifiants et de privilèges
- Vidage ciblé des identifiants dans des domaines déjà contrôlés
Primitive 1 : acquisition des identifiants et des privilèges (alternative aux informations d'identification fantômes)
Aujourd'hui, si un attaquant contrôle un principal cible (par exemple, dispose de GenericWrite sur un utilisateur ou un ordinateur), il peut le compromettre en ajoutant des identifiants fantômes ou en lançant une attaque Kerberoasting ciblée.
BadSuccessor ouvre une nouvelle voie d'attaque : si un attaquant contrôle un dMSA, il peut effectuer une liaison mutuelle et demander un ticket pour le dMSA. Il peut alors :
- Agir avec les privilèges effectifs de la cible lors de l'utilisation de l'identité du dMSA (utile lorsque le compte cible est étroitement surveillé)
- Obtenir les clés de la cible à partir du package de clés dMSA, ce qui est plus rapide et plus fiable que d'ajouter un SPN et de lancer une attaque Kerberoasting (réservée aux utilisateurs, dépendante du craquage et franche)
- Adapter la télémétrie pour que l'attaque génère uniquement des journaux sur les modifications de lien dMSA↔cible et l'émission d'un ticket d'octroi de ticket (TGT) pour le dMSA
Primitive 2 : vidage ciblé des identifiants dans des domaines déjà contrôlés (alternative à DCSync)
Dans un domaine déjà compromis, BadSuccessor fournit un moyen de vider les clés des principaux via l'émission normale de tickets. Il ne s'agit pas d'un remplacement de DCSync, mais plutôt d'une voie différente avec d'autres signaux qui peuvent échapper aux détections existantes.
Comment l'exploitation de BadSuccessor peut être détectée après le correctif
BadSuccessor peut toujours être exploité par deux primitives différentes après la publication du correctif Microsoft. Pour détecter une activité potentielle, essayez l'une des pistes suivantes :
- Listes de contrôle d'accès au système (SACL) : Auditer la création des dMSA et les modifications apportées aux attributs de lien de migration des deux côtés : le lien du dMSA et le lien du compte remplacé/précédent
- Indices comportementaux :
- Des entrées de journal répétées indiquant que le mot de passe d'un dMSA a été récupéré dans un court laps de temps
- Un utilisateur activé semblant être lié à un dMSA (ce qui devrait être inhabituel)
- Un utilisateur précédemment désactivé lié à un nouveau dMSA
Pour obtenir des conseils de détection plus détaillés, lisez notre précédent article de blog sur BadSuccessor.
Atténuation des menaces
- Première étape : le correctif. Mettez à jour vos contrôleurs de domaine Windows Server 2025 pour CVE-2025-53779.
- Réduction de la surface d'attaque. Vérifiez les autorisations sur les OU, les conteneurs et les objets dMSA eux-mêmes. Renforcez les délégations et supprimez les droits étendus afin que seuls les administrateurs de niveau 0 puissent créer ou modifier les dMSA et leurs attributs de lien de migration.
Conclusion
Microsoft a fermé la voie d'élévation directe en imposant une liaison mutuelle qui ressemble à une vraie migration ; un lien unilatéral ne permet plus d'obtenir des privilèges ou des clés. Mais BadSuccessor n'a jamais été qu'un simple bug : c'est une véritable technique. Il s'agit d'un problème grandissant dans le secteur : on ferme une porte, mais l'attaquant passe par la serrure.
BadSuccessor persiste après le correctif en tant que (1) primitive d'acquisition d'identifiants et de privilèges lorsqu'un attaquant contrôle un principal cible et un dMSA, et (2) méthode sans réplication pour extraire des secrets dans des domaines déjà contrôlés.
Ces résultats ne sont pas nouveaux : il existe d'autres moyens d'y parvenir. Cependant, ils imposent tous des exigences et une télémétrie différentes, c'est pourquoi un attaquant peut préférer BadSuccessor.
Une dernière remarque
Petite remarque sur le dMSA lui-même : à mes yeux, le dMSA post-correctif est une amélioration précieuse pour la sécurité AD. Bien utilisé, il améliore l'hygiène des comptes de service et réduit les secrets de longue durée. Je reviendrai plus en détail sur le dMSA et son intérêt dans un prochain article de blog. Restez à l'écoute !
Balises
