SignDrop : élévation de privilèges Windows CLFS vers SYSTEM

En bref

• Une preuve de concept publique appelée SignDrop abuse de la fonction d'authentification du Common Log File System de Windows pour transformer un utilisateur standard en SYSTEM sur Windows 11 et Server 2025 corrigés. Le chercheur MSNightmare l'a publiée le 10 novembre 2026.
• Les systèmes concernés sont Windows 11 25H2, 26H1, 26H2 et Windows Server 2025 avec le mode d'authentification CLFS 0 ou 1. La chaîne publiée exige aussi Windows Defender activé.
• Aucune CVE, aucun avis Microsoft et aucun correctif n'existent. Un test indépendant a confirmé que l'exploit fonctionne mais n'est pas assez fiable pour un usage opérationnel. Aucune attaque n'est signalée et la faille n'est pas dans le KEV de la CISA au 13 novembre 2026.
• Ne désactivez pas l'authentification CLFS pour l'éviter : les modes 2 ou 3 rouvrent les failles de corruption mémoire que l'atténuation doit arrêter. Gardez-la active, limitez l'accès local des utilisateurs standard et surveillez la publication d'un avis Microsoft. Voir « Comment corriger ? ».

Suis-je concerné ?

Vous êtes exposé lorsque toutes ces conditions sont réunies :

• L'appareil exécute Windows 11 25H2, 26H1 ou 26H2, ou Windows Server 2025. Le chercheur a testé Windows 11 26H2, une version expérimentale 26H2 et une version expérimentale de Windows Server 2025.
• Le mode d'authentification CLFS est 0 (appliqué) ou 1 (apprentissage). Microsoft active l'atténuation par défaut et fait passer un système de l'apprentissage à l'application après 90 jours, donc les deux modes sont concernés.
• Windows Defender est activé. La chaîne publiée force le moteur de mise à jour de Defender à ouvrir le journal préparé par l'attaquant.
• Un utilisateur standard local peut exécuter du code sur l'appareil. La faille est une élévation de privilèges locale, pas une attaque distante.

Les versions plus anciennes de Windows n'ont pas la fonction d'authentification CLFS, donc le chemin SignDrop ne s'y applique pas. Leur pilote CLFS analyse toujours des fichiers journaux, et les failles de corruption mémoire que l'atténuation devait arrêter restent un risque distinct.

Lisez le mode d'authentification CLFS sur l'appareil :

reg query "HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication" /v Mode

PowerShell lit la même valeur :

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\CLFS\Authentication' -Name Mode

Un Mode de 0 ou 1 entre dans le périmètre revendiqué par le chercheur. Un Mode de 2 signifie qu'un administrateur a désactivé l'atténuation, et 3 que le système l'a désactivée. Aucune de ces valeurs ne rend l'appareil sûr : les deux laissent CLFS analyser des journaux falsifiés, ce qui est l'exposition à la corruption mémoire que l'atténuation devait réduire.

Vérifiez la version de Windows avec winver ou :

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Comment corriger ?

Aucun correctif n'existe. Microsoft n'a attribué aucune CVE, publié aucun avis ni livré aucun correctif, et les mises à jour de sécurité de novembre 2026 ne traitent pas SignDrop.

1. Gardez l'authentification CLFS active. Laissez Mode à 0 ou 1. Ne le réglez pas sur 2 ou 3 pour éviter cette faille, car cela rouvre le chemin de corruption mémoire CLFS.
2. Limitez l'ouverture de session locale et les comptes standard aux personnes qui en ont besoin. La chaîne publiée part d'une session utilisateur standard.
3. Surveillez le Security Update Guide de Microsoft et l'article de support sur l'authentification CLFS pour une CVE, un avis ou une atténuation modifiée.
4. Exécutez les contrôles de « Comment vérifier si j'ai été compromis ? » sur les appareils où un utilisateur standard peut exécuter du code.

Aucun contournement prouvé ne bloque la chaîne publiée tout en laissant l'atténuation active. La protection contre les altérations de Windows Defender n'aide pas dans le chemin publié, car la chaîne demande au processus privilégié de Defender de créer le fichier. Supprimer l'exécution locale de code, par exemple en déplaçant les utilisateurs non fiables vers une session distante ou un autre appareil, supprime la condition préalable mais n'est pas toujours praticable.

L'article de support de Microsoft décrit l'atténuation et les valeurs de registre. Il avertit aussi que désactiver l'atténuation laisse CLFS analyser des journaux non authentifiés, raison pour laquelle le réglage doit rester actif.

Quelle est la cause racine ?

Le pilote CLFS crée le fichier d'authentification d'un journal dans le contexte du processus qui ouvre le journal, mais donne au nouveau fichier les permissions du journal d'origine, donc un ouvreur privilégié peut être amené à créer un fichier appartenant à SYSTEM qu'un utilisateur standard peut écrire.

CLFS est le Common Log File System, un sous-système de journalisation en mode noyau de Windows. Microsoft a ajouté une atténuation d'authentification en octobre 2025. Le pilote attache un code d'authentification de message basé sur un hachage au fichier journal, avec une clé stockée dans le registre et lisible uniquement par les administrateurs et SYSTEM.

Chaque journal peut avoir un conteneur associé et un fichier compagnon .cnpf qui contient des données de récupération. Le fichier compagnon est créé avec les mêmes attributs de sécurité que le journal d'origine, selon la documentation de Microsoft.

L'analyse publiée décrit ce qui se passe lorsqu'un journal avec un conteneur associé est ouvert. Le pilote ouvre aussi le conteneur associé. Si le fichier associé est vide et que son fichier d'authentification est absent, CLFS crée le fichier .cnpf.

La création s'exécute dans le contexte du processus qui a ouvert le journal, donc un processus privilégié crée le fichier en tant que SYSTEM. Le nouveau fichier hérite de la liste de contrôle d'accès discrétionnaire du journal d'origine, que l'utilisateur standard contrôle.

La seconde partie est la redirection. Un lien symbolique du gestionnaire d'objets peut pointer le chemin .cnpf vers un emplacement choisi par l'attaquant. Lorsque le processus privilégié ouvre le journal, CLFS suit le lien et crée le fichier au chemin de l'attaquant, toujours en tant que SYSTEM et toujours avec les permissions du journal d'origine.

L'exemple du chercheur ouvre \CLFS\??\C:\test\t, qui ouvre t.blf et son conteneur associé.

La documentation de Microsoft définit les valeurs de mode :

• 0 : l'atténuation est appliquée. CLFS refuse les journaux dont les codes d'authentification sont absents ou invalides.
• 1 : mode apprentissage. CLFS ouvre les journaux et écrit les codes d'authentification lorsqu'ils manquent.
• 2 : un administrateur a désactivé l'atténuation.
• 3 : le système a désactivé l'atténuation.

Les modes 0 et 1 sont les configurations vulnérables, car le fichier d'authentification est créé dans les deux.

Comment la faille est-elle exploitée ?

1. Un utilisateur standard crée un journal CLFS et un conteneur associé avec des chemins qu'il contrôle, et fait en sorte que le conteneur associé soit vide pour que son fichier d'authentification manque.
2. L'utilisateur crée un lien symbolique du gestionnaire d'objets qui redirige la création du .cnpf vers un chemin qu'il peut atteindre.
3. L'utilisateur force un processus privilégié à ouvrir le journal. La preuve de concept publiée appelle l'interface de mise à jour de Windows Defender, ServerMpUpdateEngineSignature.
4. CLFS crée le fichier .cnpf dans le contexte de sécurité du processus privilégié, donc le fichier appartient à SYSTEM. Le nouveau fichier hérite de la liste de contrôle d'accès discrétionnaire du journal d'origine, que l'utilisateur peut écrire.
5. L'utilisateur écrit dans le fichier créé par SYSTEM et enchaîne l'écriture vers un shell SYSTEM.

Le dépôt publié contient le code de preuve de concept et l'analyse. Le chercheur l'a testé sur Windows 11 26H2, une version expérimentale de Windows 11 26H2 et une version expérimentale de Windows Server 2025. Le dépôt indique que la technique peut fonctionner contre tout moteur antimalware dont le processus s'exécute avec des privilèges élevés ; cette affirmation plus large n'a pas été testée indépendamment.

L'évaluation indépendante de 78researchlab, rapportée par The Hacker News, a conclu que l'exploit fonctionne mais ne s'exécute pas assez fiablement pour un usage opérationnel. Son exécution change chaque invite de contrôle de compte d'utilisateur en un shell utilisateur standard et un shell SYSTEM, ce qui rend l'attaque visible pour toute personne devant l'appareil.

Comment se déroule l'attaque ?

Un utilisateur standard prépare un journal CLFS et un chemin compagnon redirigé, puis force Defender à ouvrir le journal pour que CLFS crée un fichier appartenant à SYSTEM que l'utilisateur peut écrire.

Que peut faire un attaquant ?

Un utilisateur standard local peut obtenir les privilèges SYSTEM sur un appareil concerné. C'est le plus haut privilège local sur une station de travail ou un serveur Windows, et il permet à l'attaquant de lire les données d'autres utilisateurs, de modifier la configuration système, de charger des pilotes et de désactiver des logiciels de sécurité.

Les conditions font partie de l'impact :

• L'attaquant a besoin d'une session utilisateur standard et de la possibilité d'exécuter du code sur l'appareil.
• Le mode d'authentification CLFS doit être 0 ou 1.
• Windows Defender doit être activé pour la chaîne publiée, car la chaîne utilise l'interface de mise à jour de Defender pour ouvrir le journal.
• La chaîne publiée est une élévation de privilèges locale. Elle ne donne pas d'accès distant à elle seule et ne se propage pas à d'autres appareils.

Le chercheur indique que la technique peut être utilisée contre tout moteur antimalware qui exécute un processus privilégié. Cette affirmation est plus large que le test publié, qui a utilisé Defender sur des versions spécifiques de Windows. Le test indépendant confirme un shell SYSTEM sur les versions testées, pas une exploitation fiable sur chaque configuration.

Pourquoi le correctif fonctionne-t-il ?

Aucun correctif n'existe, donc cette section décrit ce qu'un correctif doit changer. Un correctif complet doit empêcher un ouvreur privilégié de créer un fichier avec des permissions que l'ouvreur ne contrôle pas.

Trois changements fermeraient le chemin publié :

• Créer le fichier d'authentification dans le contexte de sécurité du propriétaire du journal d'origine, ou revérifier l'identité de l'ouvreur avant de le créer.
• Ne pas hériter d'une liste de contrôle d'accès discrétionnaire que le créateur du journal contrôle lorsque le fichier est créé dans un contexte privilégié.
• Valider le chemin du conteneur associé par rapport au répertoire du journal, et refuser la redirection du gestionnaire d'objets pour une création privilégiée.

Microsoft n'a publié ni correctif ni CVE. Jusqu'à ce que ce soit le cas, garder l'atténuation active est le contrôle qui préserve la protection pour laquelle la fonction a été introduite. La désactiver échange une élévation de privilèges locale contre les failles de corruption mémoire que l'atténuation devait arrêter.

Comment vérifier si j'ai été compromis ?

Aucun indicateur de compromission n'a été publié et aucune attaque n'est signalée. L'exploit publié est visible, donc ces contrôles cherchent l'état qu'il crée.

• Cherchez des fichiers .cnpf à des emplacements inattendus, surtout dans des répertoires inscriptibles par l'utilisateur et avec la propriété SYSTEM. Un fichier compagnon se trouve normalement à côté de son journal.
• Cherchez des liens symboliques du gestionnaire d'objets qui pointent d'un chemin CLFS vers un emplacement inscriptible par l'utilisateur. WinObj ou un visualiseur similaire montre l'espace de noms \CLFS.
• Vérifiez un changement du comportement du contrôle de compte d'utilisateur. L'exploit publié change les invites UAC en un shell utilisateur standard et un shell SYSTEM.
• Examinez les événements Defender et système autour d'ouvertures inattendues de journaux, et cherchez de nouveaux comptes locaux ou services créés après une session utilisateur standard.
• Vérifiez la présence de processus SYSTEM ou de pilotes chargés hors d'une fenêtre de maintenance.

Une tentative échouée peut ne laisser aucune trace. Si un contrôle donne un résultat, conservez l'image du disque et reconstruisez l'appareil au lieu de le nettoyer sur place.

Chronologie

• 2025-10-28 : Microsoft livre l'atténuation d'authentification CLFS dans les mises à jour de Windows 11 25H2, 26H1 et Windows Server 2025 (KB 5056852).
• 2026-11-10 : MSNightmare publie la preuve de concept et l'analyse SignDrop sur GitHub.
• 2026-11-12 : The Hacker News rapporte la faille et le test indépendant de 78researchlab, qui conclut que l'exploit fonctionne mais n'est pas fiable.
• 2026-11-13 : aucune CVE, aucun avis Microsoft et aucun correctif. La faille n'est pas dans le KEV de la CISA.

FAQ

Existe-t-il une CVE pour SignDrop ?

Non. Microsoft n'a attribué aucune CVE, publié aucun avis ni livré aucun correctif au 13 novembre 2026. Le chercheur la qualifie de zero-day, et le dépôt public est la seule trace technique.

Windows 10 est-il concerné ?

La fonction d'authentification CLFS est présente dans Windows 11 25H2, 26H1, 26H2 et Windows Server 2025. Les versions plus anciennes ne l'ont pas, donc le chemin SignDrop ne s'applique pas. Leur pilote CLFS conserve des failles de corruption mémoire, qui sont un risque distinct.

La faille peut-elle être exploitée à distance ?

Non. La chaîne publiée part d'une session utilisateur standard sur l'appareil et exige l'exécution locale de code. C'est une élévation de privilèges locale, pas une faille d'exécution de code à distance.

Dois-je désactiver l'authentification CLFS pour m'en protéger ?

Non. Régler le mode sur 2 ou 3 désactive l'atténuation et laisse CLFS analyser des journaux falsifiés, ce qui rouvre les failles de corruption mémoire que la fonction devait arrêter. Gardez le mode à 0 ou 1.

La protection contre les altérations de Defender bloque-t-elle l'exploit ?

Pas dans la chaîne publiée. La chaîne demande à l'interface de mise à jour de Defender d'ouvrir le journal, donc la création du fichier se fait dans le processus de confiance de Defender. Le chercheur dit que c'est ce qui permet à la technique de contourner l'autodéfense, et le test indépendant confirme le shell SYSTEM sur les versions testées.

Est-elle exploitée en environnements réels ?

Aucune attaque n'est signalée au 13 novembre 2026. L'exploit est public, mais le test indépendant l'a trouvé peu fiable et visible, et le catalogue KEV de la CISA ne le liste pas.

Références

• MSNightmare, preuve de concept et analyse technique SignDrop, publiée le 2026-11-10 : https://github.com/MSNightmare/SignDrop (vérifié le 13 novembre 2026)
• Microsoft, « Common Log File System (CLFS) Authentication Mitigation », KB 5056852, date de publication initiale 2025-10-28, les valeurs de mode et les attributs de sécurité du fichier compagnon : https://support.microsoft.com/en-us/servicing/os/windows/2025/03/common-log-file-system-clfs-authentication-mitigation (vérifié le 13 novembre 2026)
• The Hacker News, « New SignDrop Zero-Day Exploit Turns Windows CLFS Security Feature Into SYSTEM Access », 2026-11-12, la chaîne d'exploitation, le test indépendant et les versions concernées : https://thehackernews.com/2026/11/new-signdrop-zero-day-exploit-turns.html (vérifié le 13 novembre 2026)
• Flux JSON du catalogue des vulnérabilités exploitées de la CISA, vérifié pour SignDrop le 13 novembre 2026 (non listé) : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (vérifié le 13 novembre 2026)
• Security Update Guide de Microsoft, vérifié pour une CVE ou un avis SignDrop le 13 novembre 2026 (aucun) : https://msrc.microsoft.com/update-guide (vérifié le 13 novembre 2026)