Comment j'ai obtenu les droits d'administrateur de domaine via SafeNet Agent pour la connexion Windows à travers ESC1
Feb 2, 2026
Netwrix a découvert que les versions 4.0.0–4.1.2 de SafeNet Agent pour Windows Logon créent par défaut un modèle de certificat AD CS non sécurisé, permettant un chemin ESC1 qui permet à tout utilisateur authentifié de s'élever au rang d'Administrateur de Domaine. Thales a corrigé le problème dans la version 4.1.3 en restreignant l'inscription des certificats au compte de service NDES.
Description
Recherche en sécurité Netwrix a récemment signalé un risque de sécurité lié à SafeNet Agent for Windows Logon versions 4.0.0, 4.1.1, et 4.1.2. Par conception, l'agent s'appuie sur un modèle de certificat dans les services de certificats Active Directory (AD CS), et la configuration de ce modèle crée un chemin ESC1. Cela permet aux utilisateurs authentifiés de s'élever au niveau d'administrateur de domaine, même si le modèle est destiné à prendre en charge la fonctionnalité de connexion Windows sans mot de passe.
SafeNet Agent for Windows Logon est un composant léger installé sur les machines Windows pour renforcer la sécurité de la connexion avec une authentification multi-facteurs (MFA). Il aide à garantir que les ressources sensibles ne sont accessibles que par des utilisateurs autorisés et sécurise les applications de bureau et les processus qui s'appuient sur CredUI. Ce faisant, il vise à fournir une expérience de connexion sécurisée et cohérente pour les utilisateurs finaux. La connexion Windows sans mot de passe, qui est basée sur SafeNet Agent for Windows Logon, supprime le besoin de mots de passe lors de l'accès à la machine et à d'autres ressources. La connexion Windows sans mot de passe utilise MFA basée sur des certificats X.509 (PKI) et est conçue comme un point d'entrée pour les organisations qui commencent leur transition vers l'authentification sans mot de passe. Elle aide à réduire les appels au service d'assistance pour les réinitialisations de mots de passe, offre aux employés une expérience de connexion plus fluide qui soutient la productivité et prépare l'environnement à une adoption plus large de l'authentification sans mot de passe et moderne.
Voici un diagramme d'architecture de haut niveau de la solution de connexion Windows sans mot de passe et comment ses composants interagissent.
Comme mentionné précédemment, l'installation nécessite un AD CS et la création d'un modèle de certificat pour activer la connexion sans mot de passe. Thales fournit également un fichier ZIP dans la documentation officielle contenant deux scripts PowerShell pour automatiser ces tâches.
Lorsque nous extrayons le fichier ZIP qui accompagne l'installation, nous trouvons un fichier JSON intéressant nommé CertTemplate.json, qui est utilisé pour automatiser et remplir le modèle de certificat. La première chose qui a attiré mon attention était l'ensemble des usages de clé étendus qui permettent l'authentification, combinés avec msPKI-Certificate-Name-Flag défini sur 1, ce qui active le ENROLLEE_SUPPLIES_SUBJECT drapeau. Si vous êtes familier avec les abus d'AD CS, cette configuration suggère fortement un problème de style ESC1.
Ce script installe les outils PowerShell requis pour Active Directory et AD CS, puis crée un nouveau modèle de certificat AD CS appelé WLAPwdlessLogon en utilisant les paramètres de CertTemplate.json et le publie. Après cela, il accorde au groupe Authenticated Users la permission d'inscription sur le modèle et redémarre le service des services de certificats.
L'exécution du script PowerShell dans notre laboratoire confirme que le modèle est créé et que les utilisateurs authentifiés se voient accorder la permission d'inscription.
Après avoir publié le modèle de certificat, nous avons vérifié s'il était réellement vulnérable en exécutant Certify.exe pour lister les modèles non sécurisés. La sortie montre que toutes les conditions ESC1 sont remplies, ce qui signifie que ce modèle permet à tout utilisateur authentifié d'escalader au niveau d'administrateur de domaine.
Nous pouvons maintenant demander un certificat pour n'importe quel compte utilisateur ou ordinateur et utiliser ESC1 pour usurper cette identité, y compris un administrateur de domaine. Dans cet exemple, nous allons le faire avec le MSOL_1191fa1e45e4 compte, car il a des permissions DCSync.
À ce stade, nous pouvons demander un TGT Kerberos pour cette identité et l'utiliser pour nous déplacer latéralement en tant que ce compte.
Chronologie de divulgation
- Nous avons signalé ce problème de sécurité à Thales PSIRT le 24 novembre 2025, y compris une preuve de concept montrant que le produit est vulnérable par conception et permet aux utilisateurs authentifiés d'utiliser ESC1 pour atteindre l'administrateur de domaine. Thales a reconnu le rapport le même jour et l'a transmis à l'équipe responsable de la solution.
- Le 28 novembre 2025, nous avons contacté Thales pour demander une mise à jour sur ce cas, car nous croyons qu'il représente un défaut de conception significatif.
- Le 4 décembre 2025, Thales a répondu qu'ils attendaient toujours des retours de leur équipe d'ingénierie.
- Le 10 décembre 2025, Netwrix Security Research a fait un suivi pour demander une mise à jour.
- Le 12 décembre 2025, Thales a confirmé que son équipe d'ingénierie avait identifié le problème et travaillait à la fois sur une solution et un bulletin de sécurité pour informer les clients.
- Le 5 janvier 2026, Netwrix Security Research a de nouveau suivi pour demander une mise à jour sur le bulletin de sécurité Thales couvrant les mesures d'atténuation pour ce problème.
- Le 12 janvier 2026, Thales a répondu et a confirmé qu'ils avaient publié un bulletin de sécurité et sorti une version mise à jour du produit qui atténue le problème.
Atténuation
Au moment de la rédaction, Thales avait réservé CVE-2026-0872 et a publié un bulletin de sécurité recommandant aux clients de mettre à jour SafeNet Agent pour Windows Logon vers la version 4.1.3 pour atténuer le problème.
Dans la version mise à jour, les directives du modèle AD CS ont également été révisées.Utilisateurs authentifiés n'ont plus le droit de s'inscrire, et seul le compte de service NDES est autorisé à s'inscrire pour ce modèle.
Si nous relançons Certify.exe, nous pouvons confirmer que Read/Enroll les permissions sont désormais limitées au compte de service NDES, et Utilisateurs authentifiés n'ont plus ces droits.
Conclusion
Ce cas montre un exemple concret d'un produit MFA qui peut encore introduire un risque significatif s'il repose sur une mauvaise conception de l'AD CS. La fonctionnalité sans mot de passe a été construite sur un modèle de certificat qui permet à tout utilisateur authentifié de demander un certificat avec des EKU d'authentification client et ENROLLEE_SUPPLIES_SUBJECT, et le script du fournisseur accorde même par défaut l'inscription aux utilisateurs authentifiés. Ensemble, cela transforme une fonctionnalité de sécurité en un chemin ESC1 prêt à l'emploi vers l'administrateur de domaine.
Références
FAQ
Partager sur
En savoir plus
À propos de l'auteur
