Bypassing Windows authentication reflection mitigations for SYSTEM shells - Part 1

Introduction

CVE-2025-33073

La CVE-2025-33073 était une vulnérabilité critique de réflexion d'authentification menant à une exécution de commandes à distance (RCE) sur les systèmes Windows. Cette classe de vulnérabilité consiste à forcer un client sur une machine à s'authentifier auprès d'un serveur contrôlé, puis à relayer son authentification vers un service de la même machine, afin d'usurper l'identité du client. La lecture de notre analyse détaillée de la CVE-2025-33073 est fortement recommandée avant de plonger dans cet article, afin de bien comprendre les détails techniques. Cependant, les éléments clés du fonctionnement interne de la vulnérabilité sont rappelés ci-dessous :

• Lors de l'authentification auprès d'une cible, il est possible d'ajouter des informations de cible supplémentaires après le nom de la cible, sous forme de données en base64.
• Ces données supplémentaires sont retirées du nom de la cible par LSASS avant la construction des blobs d'authentification (NTLM ou Kerberos). Par exemple, l'utilisation du nom de cible srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA amène LSASS à générer des blobs d'authentification pour srv1. Ce fonctionnement sera appelé la technique CMTI (CredMarshalTargetInfo) dans les articles.
• srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA est un enregistrement DNS valide. De plus, par défaut, les utilisateurs du domaine peuvent ajouter des enregistrements DNS dans un environnement Active Directory.
• Lorsqu'on force un service privilégié (LSASS par exemple, s'exécutant en tant que NT AUTHORITY\SYSTEM) à s'authentifier auprès d'un serveur pointé par un tel enregistrement DNS, des comportements intéressants se produisent pour les deux packages d'authentification NTLM et Kerberos :
  • Pour NTLM, comme le nom de cible assaini est égal au nom de la machine, une authentification locale NTLM aura lieu. De plus, comme l'enregistrement DNS avec les informations de cible supplémentaires pointe vers une adresse IP contrôlée, il sera donc possible de relayer l'authentification locale NTLM vers la machine et d'usurper l'identité du service privilégié.
  • Pour Kerberos, comme le nom de cible a été assaini, le SPN utilisé pour demander un ticket de service (ST) sera CIFS/SRV1. Une fois encore, comme l'enregistrement DNS avec les informations de cible supplémentaires pointe vers une adresse IP contrôlée, le client enverra l'AP-REQ à notre serveur et ce dernier sera relayé vers la même machine afin d'usurper l'identité du service privilégié.
• Différents mécanismes sont en place dans les packages d'authentification pour déduire que le client initial s'exécutait en tant que NT AUTHORITY\SYSTEM, mais le point important est le suivant : une fois le relai réussi, nous disposons d'une session SMB authentifiée en tant que NT AUTHORITY\SYSTEM sur la machine cible, ce qui suffit pour la compromettre.

Le correctif

Pour atténuer la vulnérabilité, Microsoft a décidé de modifier le client SMB (mrxsmb.sys) afin qu'il refuse de se connecter à des cibles dont les noms contiennent des informations de cible supplémentaires. Cela nous a immédiatement semblé être une manière étrange d'atténuer le problème : si, par un moyen quelconque, une autre technique était découverte pour recevoir une authentification NTLM locale ou un AP-REQ Kerberos sur un serveur contrôlé, la vulnérabilité serait réintroduite ! Nous avons donc décidé de vérifier si cela était effectivement possible.

Tout d'abord, nous décrirons la méthodologie de contournement générique et itérative qui a été suivie durant la recherche. Cette méthodologie sera immédiatement illustrée par la divulgation de la première vulnérabilité que nous avons découverte : une élévation de privilèges locale triviale via la réflexion NTLM.

Méthodologie

Principe

La chose la plus importante lorsqu'on essaie de contourner une mesure d'atténuation est de bien comprendre ce qu'elle fait. De même, avoir une compréhension approfondie de la vulnérabilité originale est essentiel pour trouver des variantes. Dans notre cas, c'était facile car nous avions déjà fait cette analyse il y a un an lors de la remontée de la vulnérabilité à Microsoft.

Ensuite, l'objectif est d'imaginer autant de scénarios d'attaque théoriques que possible, qui ne sont pas couverts par le correctif. À cette étape, il n'est pas important que les scénarios soient viables : ils doivent simplement ne pas être affectés par le correctif.

Enfin, chaque stratégie d'attaque doit être évaluée selon divers critères : faisabilité, prérequis, etc. À l'exception de la viabilité réelle de l'attaque, la plupart des critères sont arbitraires et dépendent des préférences. Pour cette recherche, nous avons choisi de nous en tenir aux règles suivantes :

• L'attaque doit fonctionner au moins sur la dernière version de Windows 11 ou Windows Server 2025 (pour être éligible à un bounty).
• L'attaque doit fonctionner sur la configuration par défaut.
• L'attaque ne doit requérir aucune interaction utilisateur.
• L'attaque doit aboutir soit à une RCE, soit à une LPE.

Si une stratégie d'attaque satisfait tous les critères prédéfinis, alors elle est sélectionnée et testée. Cette méthodologie de contournement générique peut être résumée par le diagramme suivant :

Utiliser d'autres protocoles clients

Comme le correctif ne s'applique qu'au client SMB, nous pourrions essayer d'utiliser d'autres protocoles clients pour forcer l'authentification. En effet, la technique CMTI n'est pas liée au protocole SMB et peut théoriquement être appliquée à tout protocole qui utilise l'authentification NTLM ou Kerberos. Outre SMB, deux autres protocoles peuvent être utilisés pour forcer des authentifications avec des niveaux de prérequis variables : RPC (DCOM inclus) et HTTP.

RPC

L'authentification forcée RPC est souvent induite via DCOM en utilisant une astuce documentée il y a 10 ans par James Forshaw. Cependant, depuis octobre 2022, le client DCOM s'authentifie toujours avec au moins le niveau d'authentification RPC_C_AUTHN_LEVEL_PKT_INTEGRITY, ce qui signifie que la signature sera négociée lors du relai vers SMB.

Nous pourrions changer la cible du relai vers HTTP, qui ne supporte pas les mécanismes d'intégrité (sauf le channel binding sur HTTPS). Cependant, par défaut, les machines Windows n'exposent aucun serveur HTTP pouvant être exploité pour compromettre la machine, ce qui ne correspond pas à notre critère de « configuration par défaut ». Il existe certains services HTTP bien connus qui peuvent mener à une compromission de la machine (ou du domaine), tels que l'inscription Web ADCS ou l'AdminService de SCCM, mais nous voulions un exploit applicable aux machines Windows sans aucun rôle ou logiciel spécifique installé. C'est pourquoi nous avons décidé d'écarter cette piste d'attaque.

Il convient de noter que cette stratégie d'attaque a été envisagée par @decoder_it et a mené à la découverte de la CVE-2026-26119, qui attaque le service HTTP du Windows Admin Center.

HTTP

Les authentifications forcées HTTP sont principalement obtenues via le service WebClient qui implémente un client WebDAV. Pour qu'une machine s'authentifie via WebDAV (et donc HTTP), le service doit donc être en cours d'exécution. Ce n'est pas le cas pour les postes de travail Windows, bien qu'il existe des méthodes pour le démarrer, mais elles requièrent une interaction utilisateur, ce qui ne correspond pas à nos critères. Sur les serveurs Windows, le service n'est même pas installé.

De plus, au moins la majorité des clients HTTP Windows met en minuscules le nom de la cible avant de générer le blob d'authentification, ce qui empêche la technique CMTI de fonctionner, car celle-ci repose sur des données en base64 (qui sont sensibles à la casse).

Pour les raisons ci-dessus, nous avons décidé de ne pas emprunter cette voie non plus.

Jouer avec la nom de cible

Une autre possibilité était de garder SMB comme client relayé et comme cible du relai, mais de trouver d'autres moyens de forcer le client à s'authentifier auprès d'un serveur contrôlé, tout en conservant l'aspect d'authentification locale de l'attaque.

Authentification vers localhost

Notre première idée était d'essayer de forcer une authentification vers localhost. Le nom de cible étant localhost (ou une adresse IP locale), le package d'authentification NTLM initierait une authentification NTLM locale, que nous pourrions relayer vers le service SMB. La seule difficulté est de forcer le client SMB à s'authentifier auprès de notre serveur SMB au lieu de celui par défaut. De plus, cela signifierait que l'impact serait limité à une LPE, mais cela correspond tout de même à nos critères.

Trouver une autre primitive d'authentification forcée Kerberos

L'autre stratégie d'attaque évidente serait de trouver une technique alternative à la technique CMTI, qui nous permettrait de recevoir un message AP-REQ pour un service arbitraire. En effet, aucune mesure d'atténuation spécifique n'existe pour empêcher les attaques par réflexion Kerberos (excepté l'intégrité ou la confidentialité des communications). Le principal défi est de forcer une authentification Kerberos pour un service arbitraire vers une adresse IP arbitraire, car Kerberos est fortement lié aux noms de domaine.

Les deux idées d'attaque précédentes ont donc été sélectionnées. Notre méthodologie de contournement générique appliquée à la CVE-2025-33073 est illustrée ci-dessous :

Réflexion locale

Port de connexion arbitraire du client SMB

Lors de nos recherches sur cette piste d'attaque, un précédent article de blog de James Forshaw nous est immédiatement venu à l'esprit. Dans cet article, il décrit une amélioration d'une ancienne technique pour retarder l'accès à de la mémoire virtuelle, qui utilisait un serveur SMB distant pour retarder l'accès aux données d'un fichier. L'amélioration consiste à utiliser une fonctionnalité relativement récente, introduite dans Windows 11 24H2 et Windows Server 2025, qui permet de spécifier un port arbitraire lors de la connexion à un partage SMB. C'est précisément ce dont nous avons besoin !

Cette nouvelle fonctionnalité est accessible à tout utilisateur d'un système Windows. Pour monter un partage SMB distant sur le port 12345, il est donc possible d'exécuter la commande suivante :

C:\> net use \\192.168.56.3\share /tcpport:12345

En termes d'implémentation, des composants à la fois en espace utilisateur et en espace noyau ont été modifiés pour introduire la fonctionnalité. Pour établir la connexion au partage distant, la fonction WNetAddConnection4W doit être appelée avec un buffer de données non documenté dans le paramètre lpUseOptions. Le buffer est un tableau de la structure suivante :

struct USE_OPTION
{
  DWORD OptionType;
  DWORD Size;
  BYTE OptionData[];
};

Actuellement, il existe quatre valeurs implémentées pour OptionType :

• TraP : paramètres de transport. Ce type d'option contient, entre autres, le port TCP arbitraire à utiliser pour la connexion SMB.
• DefC : paramètres de connexion différée.
• ComP : paramètres de compression.
• BloN : paramètres de blocage NTLM.

Le paramètre Size est égal à la taille de l'en-tête USE_OPTION (8 octets) + la taille des données d'option réelles.

Durant cette recherche, seule la structure de données pour les paramètres de transport a été rétro-ingénierée :

struct TRANSPORT_USE_OPTION
{
  DWORD TransportType;
  BOOLEAN SkipCertCheck;
  WORD TcpPort;
  WORD QuicPort;
  WORD RdmaPort;
  DWORD PortTypes;
};

Le champ TransportType prend les valeurs suivantes :

• 1 pour TCP.
• 2 pour QUIC.

Le champ PortTypes est une combinaison des valeurs suivantes :

• 1 pour TCP.
• 2 pour QUIC.
• 4 pour RDMA.

Les données stockées dans lpUseOptions sont passées à la fonction ntlanman!LmCreateEABufferForUseOptions. Celle-ci parse le buffer et en crée un nouveau qui sera plus tard transmis au noyau via un FSCTL. À terme, le client SMB recevra le buffer et le parsera dans mrxsmb!MRxSmbSetNetUseSpecifiedTransportInfo afin de déterminer si la connexion doit être effectuée sur un port alternatif.

Fait intéressant, en parlant de cette fonctionnalité, James mentionnait également :

Je pense personnellement que l'activer par défaut est une erreur qui reviendra causer des problèmes à Windows à l'avenir.

Eh bien, comme souvent, il avait raison.

L'idée de l'attaque est donc de mettre en place un serveur SMB local sur un port différent de 445 et de forcer un service privilégié à s'y authentifier. Cependant, le problème suivant s'est posé : comment informer le service privilégié qu'il doit se connecter à notre serveur sur un port personnalisé, au lieu du port 445 ? En effet, pour forcer un service à s'authentifier à un partage SMB arbitraire, nous lui demandons typiquement d'ouvrir un fichier en fournissant un chemin de fichier avec la syntaxe UNC : \\IP\SHARE. La syntaxe UNC ne permet pas de spécifier un port (sauf pour les partages WebDAV). De plus, net use n'affecte que la session utilisateur courante : pour des raisons de sécurité évidentes, un utilisateur ne doit pas pouvoir accéder à la session SMB authentifiée d'un autre utilisateur.

Multiplexage SMB

Il s'avère que ce n'est en fait pas un problème ! La spécification officielle MS-SMB2 (section 3.2.4.2) indique :

Si une nouvelle session est en cours d'établissement, le client PEUT réutiliser une connexion existante de sorte que plusieurs sessions soient multiplexées sur la même connexion. S'il ne réutilise pas une connexion existante, le client peut établir une nouvelle connexion pour la nouvelle session.

En d'autres termes, SMB fait la différence entre la connexion TCP et la session authentifiée : plusieurs sessions authentifiées peuvent utiliser la même connexion TCP comme transport. De plus, le client SMB de Windows réutilise les connexions TCP.

Élévation de privilèges locale

La stratégie d'exploitation comporte deux étapes principales :

1. Démarrer un serveur SMB local sur le port 12345 et le monter. Cela force le client SMB à établir une connexion TCP vers notre partage et à la maintenir ouverte pour une utilisation ultérieure. Notez qu'à cette étape, il n'est pas nécessaire de disposer d'identifiants valides : le partage local peut être configuré pour accepter des identifiants spécifiques (user:user par exemple) et net use peut être invoqué pour s'authentifier avec les mêmes identifiants.

2. Forcer un service privilégié (LSASS par exemple) à s'authentifier auprès du même partage que celui qui a été monté précédemment. Il est impératif d'utiliser le même chemin de partage, afin que le client SMB réutilise la même connexion TCP qui a été établie lors du montage du partage spécifique. Le service s'authentifiera auprès de notre serveur SMB personnalisé et l'authentification NTLM locale sera relayée vers le véritable service SMB de la machine, aboutissant à une session SMB privilégiée et donc à la compromission de la machine.

Pour construire un PoC fonctionnel, les outils suivants ont été utilisés :

• smbserver.py d'Impacket : Utilisé pour lancer un service SMB sur un port personnalisé, recevoir le blob d'authentification NTLM local privilégié et le transférer au serveur de relais. Quelques modifications ont été apportées à l'outil afin de parser le blob d'authentification privilégié reçu sur la même connexion TCP que celle sur laquelle le partage a été monté.
• ntlmrelayx.py d'Impacket : Utilisé pour relayer le blob d'authentification privilégié vers le vrai service SMB de la machine et exécuter des commandes en tant que NT AUTHORITY\SYSTEM.
• net.exe : Utilisé pour monter le partage SMB personnalisé sur un port TCP spécifié.
• PetitPotam.exe : Utilisé pour forcer LSASS à s'authentifier auprès du service SMB personnalisé. Quelques modifications ont été apportées pour le faire fonctionner localement.

Cette vulnérabilité s'est vu attribuer la CVE-2026-24294 et a été corrigée lors du Patch Tuesday de mars 2026. Ce scénario d'attaque fonctionne par défaut sur Windows Server 2025 mais pas sur Windows 11 24H2 car la signature SMB y est imposée.

Conclusion

Dans ce premier article de blog, les éléments clés de la CVE-2025-33073 ont été rappelés et le contexte de la recherche a été présenté. Nous avons également décrit la méthodologie de contournement générique qui a été suivie et l'avons immédiatement appliquée pour en déduire deux principales pistes d'attaque qui pourraient donner des résultats potentiellement intéressants.

Nous avons ensuite détourné une nouvelle fonctionnalité des versions récentes de Windows, à savoir la possibilité de se connecter à des partages SMB sur des ports TCP arbitraires, pour obtenir une élévation de privilèges locale sur des machines Windows Server 2025 à jour. En parallèle, cela a aussi prouvé que notre hypothèse initiale concernant l'insuffisance du correctif était juste : celui-ci n'adressait pas la source du problème. La capacité de relayer des authentifications locales met toujours les machines Windows en danger.

Dans la prochaine partie, nous aborderons l'autre scénario d'attaque mentionné dans la section méthodologie : trouver une autre primitive pour forcer une authentification Kerberos arbitraire. En partant d'un contrôle total du DNS, le vecteur d'attaque sera progressivement affiné pour finalement aboutir à une primitive RCE complète en tant qu'utilisateur du domaine, achevant ainsi notre quête visant à obtenir un contournement complet de la CVE-2025-33073.