Les utilisateurs non privilégiés avec la permission de créer des objets dans une unité organisationnelle Active Directory peuvent abuser de la nouvelle fonctionnalité de comptes de services gérés (DMSA) délégués pour élever leur privilège à l’administrateur de domaine.
Les chercheurs ont découvert un nouveau chemin d’attaque dans les environnements Active Directory (AD) qui utilisent Windows Server 2025 dans la configuration par défaut. En exploitant la faiblesse, les attaquants peuvent compromettre tout utilisateur dans l’environnement conduisant à un compromis complet du domaine.
« Ce problème affecte probablement la plupart des organisations qui s’appuient sur la publicité », a écrit le chercheur d’Akamai Yuval Gordon dans un rapport publié aujourd’hui. «Dans 91% des environnements que nous avons examinés, nous avons trouvé des utilisateurs en dehors du groupe d’administrateurs de domaine qui avait les autorisations requises pour effectuer cette attaque.»
L’attaque tire parti d’une nouvelle fonctionnalité appelée Delegated Managed Service Comptes (DMSA) qui a été introduite dans Windows Server 2025 comme atténuation des attaques de kerberoasting dans lesquelles les attaquants extraient les informations d’identification de compte de service hachée à partir des environnements AD, puis effectuent une fissure hors ligne pour obtenir les mots de passe en texte clair.
Le problème que Gordon et son équipe ont découvert est que l’héritage d’autorisation pour les comptes DMSA des comptes de services remplacés a été mis en œuvre d’une manière qui permet la migration et l’utilisation transparentes des billets précédemment émis sans effectuer une validation suffisamment forte. Cela ouvre la possibilité d’identifier avec succès tout utilisateur, y compris les administrateurs de domaine.
«Cette vulnérabilité introduit un chemin d’abus auparavant inconnu et à fort impact qui permet à tout utilisateur de CreateChild les autorisations sur une OU (unité organisationnelle) de compromettre tout utilisateur dans le domaine et de gagner un pouvoir similaire au privilège des changements de répertoire de réplication pour effectuer des attaques DCSYNC», ont écrit les chercheurs d’Akamai.
Microsoft a reconnu le problème, mais la société l’a évaluée à une gravité modérée et n’est pas suffisamment urgente pour s’adresser avec un correctif immédiat, déclarant que les risques liés à l’autorisation CreateChild avaient déjà été documentés. Les chercheurs d’Akamai sont en désaccord avec l’évaluation de Microsoft, car aucune pratiques ou outils standard de l’industrie ne traite cette permission comme la préoccupation critique que ce nouveau vecteur d’attaque en fait.
Tiches de migration DMSA incomplètes
Lorsqu’un compte DMSA est créé, il hérite des autorisations du compte de service qu’elle remplace. Ce processus, appelé migration, implique plusieurs étapes qui mettent à jour les attributs sur l’objet DMSA pour indiquer le compte qu’il remplace.
L’intérêt de DMSA est de créer des comptes plus sécurisés que les comptes de service traditionnels, qui sont des comptes non humains créés dans la publicité pour être utilisés par les applications et les services. De telles identités non humaines ont fait l’objet d’un contrôle accru ces derniers temps que les problèmes de sécurité que les cyber-équipes et les fournisseurs doivent aborder.
«DMSA permet la migration des comptes de service traditionnels vers des comptes de machines avec des clés gérées et entièrement randomisées, tout en désactivant les mots de passe du compte de service d’origine», indique la documentation de Microsoft.
Certains attributs pertinents sur un compte DMSA sont msDS-DelegatedMSAStatece qui indique si le processus de migration est inconnu, en cours ou achevé; msDS-ManagedAccountPrecededByLinkqui indique le compte remplacé; et msDS-GroupMSAMembershipqui indique quels directeurs (utilisateurs, groupes et ordinateurs) peuvent s’authentifier comme compte.
Une fois la migration vers un compte DMSA terminé, toute machine qui s’authentifie en tant que compte de service remplacé recevra du contrôleur de domaine une erreur indiquant que l’ancien compte était désactivé, ainsi qu’un KERB-SUPERSEDED-BY-USER champ pour indiquer le DMSA qui l’a remplacé. La machine réessayera ensuite l’authentification en tant que DMSA pour obtenir un billet de session authentifié qui leur permet d’effectuer l’action.
C’est là que le centre de distribution de clés (KDC) entre en jeu. Dans le protocole Kerberos, que l’annonce utilise, le KDC garantit un accès sécurisé aux ressources du réseau en vérifiant les identités des utilisateurs, en leur accordant un accès en fonction de leurs autorisations.
Les chercheurs d’Akamai ont remarqué que lorsque le KDC génère le certificat d’attribut Privilege (PAC) pour le compte DMSA, il comprend les SIDS du compte de service remplacé et de ses groupes associés, accordant essentiellement le compte toutes les autorisations du compte remplacé. Cela se fait uniquement en vérifiant le ManagedAccountPrecededByLink attribut pour le compte remplacé et déterminer si le msDS-DelegatedMSAState L’attribut est défini sur 2indiquant que la migration s’est terminée.
Le problème? Ces deux attributs peuvent être modifiés arbitrairement par un compte d’utilisateur non privilégié sur n’importe quel compte DMSA qu’ils créent, ce qui signifie que le KDC peut être amené à vérifier qu’une migration pour tout compte de service arbitraire a été terminée, même si elle ne l’a pas fait – comme indiqué ci-dessous.
«Cette technique, que nous avons surnommée« Badsuccessor », travaille sur n’importe quel utilisateur, y compris les administrateurs de domaine», ont écrit les chercheurs d’Akamai. «Cela permet à tout utilisateur qui contrôle un objet DMSA pour contrôler l’ensemble du domaine. C’est tout ce qu’il faut. Pas de migration réelle. Pas de vérification. Pas de surveillance.»
Comment abuser des DMSA même dans des environnements qui ne les ont pas
Les chercheurs d’Akamai avertissent que les organisations qui n’ont créé aucun DMSA dans leurs environnements publicitaires ne sont pas non plus sûres car, en plus de pouvoir abuser d’un DMSA existant, un attaquant peut également en créer un s’il n’existe pas.
Pour ce faire, tout ce dont ils ont besoin, c’est de l’accès à un utilisateur improvisé avec des autorisations CreateChild dans une OU, ce qui leur permet de créer des objets au sein de l’OU. Selon Akamai, c’est une configuration courante qui est considérée comme bénigne et donc peu susceptible d’être surveillée ou durcie.
Par défaut, les comptes DMSA sont stockés dans le conteneur des comptes de services gérés (MSA), mais ils peuvent également être créés à l’intérieur de l’OU en utilisant l’argument de chemin. En conséquence, un utilisateur improvisé avec des autorisations CreateChild dans une OU peut créer un nouveau DMSA, puis accorder des autorisations d’écriture à ses attributs car ils sont propriétaires.
Ils peuvent ensuite modifier les DMSA ManagedAccountPrecededByLink attribut pour indiquer tout compte dont ils souhaitent hériter des autorisations, comme un administrateur de domaine, ainsi que le msDS-DelegatedMSAState Pour indiquer que la migration s’est terminée, même si ce n’est pas le cas. La dernière étape garantit que l’authentification sur le KDC se traduira par un billet PAC et session avec tous les privilèges du compte remplacé.
« Avec seulement deux changements d’attribut, un nouvel objet humble est couronné le successeur – et le KDC ne remet jamais en question la lignée; si le lien est là, les privilèges sont accordés », concluent les chercheurs d’Akamai. « Nous n’avons pas changé une seule abonnement de groupe, n’avons augmenté aucun compte existant et n’avons pas décroché aucune alerte d’escalade traditionnelle de privilèges. »
L’extraction des informations d’identification est également possible
Mais cela devient pire que l’obtention d’un billet de session avec les privilèges du compte ciblé. Les attaquants peuvent également obtenir les mots de passe cryptés de ce compte car ils sont inclus dans le KERB-DMSA-KEYPACKAGE Structure dans le cadre du billet émis dans un champ appelé previous-keys.
Étant donné qu’un DMSA est nouveau, il ne devrait pas avoir de «clés précédentes», ce qui signifie les mots de passe précédents qui ont été cryptés, mais c’est le cas, et c’est parce qu’il hérite également des clés du compte remplacé. Cela est probablement fait pour que les billets de session émis dans le passé, avant la migration d’un compte de service vers le DMSA, restent fonctionnels et ne provoquent pas de perturbations.
Cependant, cela permet également à Badsuccesseur d’être utilisé pour obtenir les clés pour potentiellement tous les utilisateurs et ordinateurs du domaine.
Atténuation
« Bien que Microsoft déclare qu’ils prévoient de résoudre ce problème à l’avenir, un correctif n’est pas actuellement disponible », ont déclaré les chercheurs d’Akamai. «Par conséquent, les organisations doivent prendre d’autres mesures proactives pour réduire leur exposition à cette attaque.»
Akamai a créé un script PowerShell qui permet aux équipes de sécurité d’identifier quels directeurs sont autorisés à créer des DMSA et dans lesquels ils ont accès. Les chercheurs conseillent que cette autorisation devrait être limitée aux administrateurs de confiance jusqu’à ce que Microsoft fournit un correctif.
Le rapport comprend également les listes de contrôle d’accès au système (SACLS) qui peuvent être utilisées pour enregistrer et surveiller la création de nouveaux msDSDelegatedManagedServiceAccount objets, modifications au msDSManagedAccountPrecededByLink Attribut et TGTS générés pour un DMSA qui inclut le KERBDMSA-KEY-PACKAGE structure.
