Étude des vulnérabilités d’élévation de privilèges dans les environnements Microsoft Server.
Veille réalisée le 15/01/2026.
Cette veille technologique a pour but de passer en revue une faille de sécurité autour de l’OS Microsoft Server 2025 patché ces 6 derniers mois, permettant ainsi, avant leur correction, à un utilisateur malintentionné d’acquérir plus de privilèges et de droits qu’il ne devrait normalement.
Comment fonctionne et est exploitée une vulnérabilité d’élévation de privilèges ?
L’utilisateur va pouvoir, à travers diverses manipulations sur un système faillible, passer par exemple d’utilisateur standard à administrateur ou de passer d’un compte de domaine à un compte de domaine administrateur. C’est une faille qui est critique puisqu’elle permet de prendre entièrement le contrôle d’un serveur, d’accéder et de modifier l’Active Directory et de déployer des malwares ou des portes dérobés (backdoors).
Dans le cadre de cette étude, nous nous attarderons sur une faille récente, la faille BadSuccessor (CVE-2025-53779) qui permet une élévation de privilèges sur Kerberos et/ou dans un Active Directory Microsoft Server 2025.
Pourquoi ai-je choisi ces types d’attaques et de failles ?
Dans le cadre de ma formation en BTS SIO option SISR, nous travaillons très souvent avec Microsoft Server 2025 et des Active Directory, comprendre comment la sécurité des systèmes de ce type peuvent être compromis me semble donc important. De plus, les attaques exploitant des failles d’élévation de privilèges sont largement utilisées dans le domaine de la cybercriminalité et de la cybersécurité ; on estime en effet au mois d’Août 2025 que 39,3% des CVE (Common Vulnerabilities and Exposures, c’est-à-dire l’identifiant d’une faille de sécurité précise) corrigées comprenaient ce type de vulnérabilité.
La vulnérabilité BadSuccessor
Cette vulnérabilité utilise la fonction de compte de service géré délégué (dMSA), qui est un compte de service managé dans l’Active Directory, prévu pour remplacer un compte utilisateur lors d’une migration.
Elle utilise la confiance qu’attribue le KDC, c’est-à-dire le composant de Kerberos qui délivre des tickets d’authentification et qui décide quels comptes ont quels droits, afin d’effectuer des migrations non légitimes.
Le prérequis pour ce type d’attaques sont d’avoir le droit de créer ou de modifier un objet dans une unité organisationnelle. Ainsi, l’attaquant, en modifiant un attribut du dMSA, peut devenir le successeur d’un utilisateur, ce qui, parce qu’aucune vérification n’est effectuée côté KDC sur la légitimité de la demande de migration, permet d’hériter des privilèges d’un utilisateur qui obtient donc les droits du compte visé.
Ce nouveau compte comporte donc :
- Les groupes du compte copié
- Mais aussi ses permissions
- Ses privilèges sur Kerberos
- Les accès aux ressources et aux fichiers du compte
Cette méthode fonctionne donc sur les comptes importants comme sur les comptes d’administrateurs de domaine, permettant ainsi de contrôler tout le domaine.
Comment utiliser une telle vulnérabilité pour s’accorder des droits d’administrateurs sur un domaine ?
Bien que la vulnérabilité soit aujourd’hui corrigée, on peut toujours effectuer des tests sur d’anciennes versions de Windows Server 2025 et de Windows 11 24H2 afin de comprendre comment la vulnérabilité fonctionne.
Premièrement, il faut vérifier que nous disposons de droits afin de créer des objets dans une unité d’organisation. Dans notre exemple, il existe une unité d’organisation appelée « temp » sur laquelle nous disposons simplement de droits d’écriture afin de créer des objets.
Il faut ensuite créer notre dMSA, avec la commande cmdlet « New-ADServiceAccount comme indiqué dans l’image ci-dessous. Notre dMSA est donc non-fonctionnel pour le moment, mais nous disposons d’autorisations sur l’objet nous permettant d’effectuer les deux commandes suivantes :
(la commande permettant de créer notre dMSA – Akamai)
- msDS-ManagedAccountPrecededByLink afin de définir le compte managé (dMSA) comme remplaçant d’un autre compte, il succède ou clone celui-ci.
- msDS-DelegatedMSAState afin de simuler la fin d’une migration
(les commandes simulant une migration — Akamai)
Il suffit ensuite de s’authentifier auprès de notre dMSA, c’est-à-dire obtenir un ticket Kerberos en son nom. Ici, l’attaquant choisi de ne pas créer un service et de le configurer pour qu’il s’exécute avec le compte dMSA mais tout simplement d’utiliser Rubeus, un toolkit spécifiquement conçu pour les manipulations sur Kerberos.
(L’outil Rubeus, permettant de s’authentifier auprès de notre dMSA -Akamai)
Désormais, le contrôleur du domaine considère notre dMSA comme le successeur légitime du compte ciblé, du compte que l’on souhaitait cloner.
Lorsque la demande du ticket Kerberos va avoir lieu, le KDC va générer un PAC (Privilege Attribute Certificate) contenant à la fois les informations du dMSA mais également les identifiants de sécurité et les groupes du compte remplacé, comme les groupes d’administrateurs.
Ainsi, l’attaquant dispose désormais des droits d’administrateurs du domaine et contrôle désormais celui-ci.
Pour conclure :
En conclusion, cette attaque simple et efficace qui se base sur une vulnérabilité Windows Server et très intéressante et permet donc de prendre le contrôle d’un domaine. Aujourd’hui, comme dit précédemment, cette faille a été corrigée et une simple mise à jour d’un serveur Windows Server 2025 permet de ne pas être victime de cette attaque. L’analyse de cette vulnérabilité m’a permis d’en apprendre plus sur le fonctionnement de Kerberos et même globalement de l’architecture d’un serveur Windows.
SOURCES :