SignDrop: elevación de privilegios de Windows CLFS a SYSTEM

Resumen

• Una prueba de concepto pública llamada SignDrop abusa de la función de autenticación del Common Log File System de Windows para convertir a un usuario estándar en SYSTEM en Windows 11 y Server 2025 corregidos. El investigador MSNightmare la publicó el 10 de noviembre de 2026.
• Los sistemas afectados son Windows 11 25H2, 26H1, 26H2 y Windows Server 2025 con el modo de autenticación CLFS 0 o 1. La cadena publicada también necesita Windows Defender activado.
• No existe CVE, aviso de Microsoft ni parche. Una prueba independiente confirmó que el exploit funciona pero no es lo bastante fiable para uso operativo. No se reportan ataques y la falla no está en el KEV de la CISA al 13 de noviembre de 2026.
• No desactive la autenticación CLFS para evitarlo: los modos 2 o 3 reabren las fallas de corrupción de memoria que la mitigación debe detener. Manténgala activa, limite el acceso local de usuarios estándar y vigile por si Microsoft publica un aviso. Consulte «¿Cómo lo corrijo?».

¿Estoy afectado?

Está expuesto cuando se cumplen todas estas condiciones:

• El dispositivo ejecuta Windows 11 25H2, 26H1 o 26H2, o Windows Server 2025. El investigador probó Windows 11 26H2, una compilación experimental 26H2 y una compilación experimental de Windows Server 2025.
• El modo de autenticación CLFS es 0 (aplicado) o 1 (aprendizaje). Microsoft activa la mitigación por defecto y pasa un sistema de aprendizaje a aplicación tras 90 días, así que ambos modos están en el alcance.
• Windows Defender está activado. La cadena publicada obliga al motor de actualización de Defender a abrir el registro preparado por el atacante.
• Un usuario estándar local puede ejecutar código en el dispositivo. La falla es una elevación de privilegios local, no un ataque remoto.

Las versiones anteriores de Windows no tienen la función de autenticación CLFS, así que la ruta SignDrop no se aplica. Su controlador CLFS sigue analizando archivos de registro, y las fallas de corrupción de memoria que la mitigación debía detener siguen siendo un riesgo aparte.

Lea el modo de autenticación CLFS en el dispositivo:

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

PowerShell lee el mismo valor:

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

Un Mode de 0 o 1 entra en el alcance que reclama el investigador. Un Mode de 2 significa que un administrador desactivó la mitigación, y 3 que el sistema la desactivó. Ninguno de esos valores hace seguro el dispositivo: ambos permiten que CLFS analice registros manipulados, que es la exposición a corrupción de memoria que la mitigación debía reducir.

Compruebe la compilación de Windows con winver o:

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

¿Cómo lo corrijo?

No existe parche. Microsoft no ha asignado una CVE, publicado un aviso ni entregado un parche, y las actualizaciones de seguridad de noviembre de 2026 no abordan SignDrop.

1. Mantenga activada la autenticación CLFS. Deje Mode en 0 o 1. No lo ponga en 2 o 3 para evitar esta falla, porque reabre la ruta de corrupción de memoria CLFS.
2. Limite el inicio de sesión local y las cuentas estándar a quienes los necesitan. La cadena publicada parte de una sesión de usuario estándar.
3. Vigile la Security Update Guide de Microsoft y el artículo de soporte sobre la autenticación CLFS por si aparece una CVE, un aviso o una mitigación modificada.
4. Ejecute las comprobaciones de «¿Cómo compruebo si estuve comprometido?» en los dispositivos donde un usuario estándar pueda ejecutar código.

No hay un rodeo probado que bloquee la cadena publicada y mantenga la mitigación activa. La protección contra alteraciones de Windows Defender no ayuda en la ruta publicada, porque la cadena pide al propio proceso privilegiado de Defender que cree el archivo. Eliminar la ejecución local de código, por ejemplo trasladando a los usuarios no confiables a una sesión remota o a otro dispositivo, elimina la condición previa pero no siempre es práctico.

El artículo de soporte de Microsoft describe la mitigación y los valores del registro. También advierte que desactivar la mitigación deja que CLFS analice registros no autenticados, por lo que el ajuste debe permanecer activo.

¿Cuál es la causa raíz?

El controlador CLFS crea el archivo de autenticación de un registro en el contexto del proceso que abre el registro, pero da al archivo nuevo los permisos del registro original, así que se puede hacer que un proceso privilegiado cree un archivo propiedad de SYSTEM que un usuario estándar puede escribir.

CLFS es el Common Log File System, un subsistema de registro en modo kernel de Windows. Microsoft añadió una mitigación de autenticación en octubre de 2025. El controlador adjunta un código de autenticación de mensaje basado en hash al archivo de registro, con una clave almacenada en el registro y legible solo por administradores y SYSTEM.

Cada registro puede tener un contenedor asociado y un archivo compañero .cnpf que contiene datos de recuperación. El archivo compañero se crea con los mismos atributos de seguridad que el registro original, según la documentación de Microsoft.

El análisis publicado describe qué ocurre cuando se abre un registro con un contenedor asociado. El controlador abre también el contenedor asociado. Si el archivo asociado está vacío y su archivo de autenticación falta, CLFS crea el archivo .cnpf.

La creación se ejecuta en el contexto del proceso que abrió el registro, así que un proceso privilegiado crea el archivo como SYSTEM. El archivo nuevo hereda la lista de control de acceso discrecional del registro original, que controla el usuario estándar.

La segunda parte es la redirección. Un enlace simbólico del administrador de objetos puede apuntar la ruta .cnpf a una ubicación elegida por el atacante. Cuando el proceso privilegiado abre el registro, CLFS sigue el enlace y crea el archivo en la ruta del atacante, todavía como SYSTEM y todavía con los permisos del registro original.

El ejemplo del investigador abre \CLFS\??\C:\test\t, que abre t.blf y su contenedor asociado.

La documentación de Microsoft define los valores de modo:

• 0: la mitigación se aplica. CLFS rechaza los registros con códigos de autenticación ausentes o inválidos.
• 1: modo aprendizaje. CLFS abre los registros y escribe los códigos de autenticación cuando faltan.
• 2: un administrador desactivó la mitigación.
• 3: el sistema desactivó la mitigación.

Los modos 0 y 1 son las configuraciones vulnerables, porque el archivo de autenticación se crea en ambos.

¿Cómo se explota?

1. Un usuario estándar crea un registro CLFS y un contenedor asociado con rutas que controla, y hace que el contenedor asociado esté vacío para que falte su archivo de autenticación.
2. El usuario crea un enlace simbólico del administrador de objetos que redirige la creación del .cnpf a una ruta a la que puede llegar.
3. El usuario obliga a un proceso privilegiado a abrir el registro. La prueba de concepto publicada llama a la interfaz de actualización de Windows Defender, ServerMpUpdateEngineSignature.
4. CLFS crea el archivo .cnpf en el contexto de seguridad del proceso privilegiado, así que el archivo es propiedad de SYSTEM. El archivo nuevo hereda la lista de control de acceso discrecional del registro original, que el usuario puede escribir.
5. El usuario escribe en el archivo creado por SYSTEM y encadena la escritura a un shell SYSTEM.

El repositorio publicado incluye el código de prueba de concepto y el análisis. El investigador lo probó en Windows 11 26H2, una compilación experimental de Windows 11 26H2 y una compilación experimental de Windows Server 2025. El repositorio dice que la técnica puede funcionar contra cualquier motor antimalware cuyo proceso se ejecute con privilegios elevados; esa afirmación más amplia no se ha probado de forma independiente.

La evaluación independiente de 78researchlab, reportada por The Hacker News, concluyó que el exploit funciona pero no se ejecuta con la fiabilidad suficiente para uso operativo. Su ejecución cambia cada aviso de Control de cuentas de usuario por un shell de usuario estándar y un shell SYSTEM, lo que hace visible el ataque para cualquiera que esté ante el dispositivo.

¿Cómo se desarrolla el ataque?

Un usuario estándar prepara un registro CLFS y una ruta compañera redirigida, y luego obliga a Defender a abrir el registro para que CLFS cree un archivo propiedad de SYSTEM que el usuario puede escribir.

¿Qué puede hacer un atacante?

Un usuario estándar local puede obtener privilegios SYSTEM en un dispositivo afectado. Es el privilegio local más alto en una estación de trabajo o servidor Windows, y permite al atacante leer datos de otros usuarios, cambiar la configuración del sistema, cargar controladores y desactivar software de seguridad.

Las condiciones forman parte del impacto:

• El atacante necesita una sesión de usuario estándar y poder ejecutar código en el dispositivo.
• El modo de autenticación CLFS debe ser 0 o 1.
• Windows Defender debe estar activado para la cadena publicada, porque la cadena usa la interfaz de actualización de Defender para abrir el registro.
• La cadena publicada es una elevación de privilegios local. No da acceso remoto por sí sola y no se propaga a otros dispositivos.

El investigador dice que la técnica puede usarse contra cualquier motor antimalware que ejecute un proceso privilegiado. Esa afirmación es más amplia que la prueba publicada, que usó Defender en compilaciones específicas de Windows. La prueba independiente confirma un shell SYSTEM en las compilaciones probadas, no una explotación fiable en cada configuración.

¿Por qué funciona la corrección?

No existe parche, así que esta sección describe qué debe cambiar una corrección. Una corrección completa debe impedir que un proceso privilegiado cree un archivo con permisos que ese proceso no controla.

Tres cambios cerrarían la ruta publicada:

• Crear el archivo de autenticación en el contexto de seguridad del propietario del registro original, o volver a comprobar la identidad del proceso que abre antes de crearlo.
• No heredar una lista de control de acceso discrecional que controle el creador del registro cuando el archivo se crea en un contexto privilegiado.
• Validar la ruta del contenedor asociado contra el directorio del registro, y rechazar la redirección del administrador de objetos para una creación privilegiada.

Microsoft no ha publicado un parche ni una CVE. Hasta que lo haga, mantener la mitigación activa es el control que conserva la protección para la que se introdujo la función. Desactivarla cambia una elevación de privilegios local por las fallas de corrupción de memoria que la mitigación debía detener.

¿Cómo compruebo si estuve comprometido?

No se han publicado indicadores de compromiso y no se reportan ataques. El exploit publicado es visible, así que estas comprobaciones buscan el estado que crea.

• Busque archivos .cnpf en ubicaciones inesperadas, sobre todo en directorios en los que el usuario puede escribir y con propiedad SYSTEM. Un archivo compañero suele estar junto a su registro.
• Busque enlaces simbólicos del administrador de objetos que apunten de una ruta CLFS a una ubicación en la que el usuario puede escribir. WinObj o un visor similar muestra el espacio de nombres \CLFS.
• Compruebe un cambio en el comportamiento del Control de cuentas de usuario. El exploit publicado cambia los avisos UAC por un shell de usuario estándar y un shell SYSTEM.
• Revise los eventos de Defender y del sistema alrededor de aperturas inesperadas de registros, y busque nuevas cuentas locales o servicios creados tras una sesión de usuario estándar.
• Revise el dispositivo por si hay procesos SYSTEM inesperados o controladores cargados fuera de una ventana de mantenimiento.

Un intento fallido puede no dejar rastro. Si una comprobación da un resultado, conserve la imagen del disco y recree el dispositivo en lugar de limpiarlo en el mismo sitio.

Cronología

• 2025-10-28: Microsoft entrega la mitigación de autenticación CLFS en las actualizaciones de Windows 11 25H2, 26H1 y Windows Server 2025 (KB 5056852).
• 2026-11-10: MSNightmare publica la prueba de concepto y el análisis SignDrop en GitHub.
• 2026-11-12: The Hacker News informa de la falla y de la prueba independiente de 78researchlab, que concluyó que el exploit funciona pero no es fiable.
• 2026-11-13: ninguna CVE, ningún aviso de Microsoft y ningún parche. La falla no está en el KEV de la CISA.

Preguntas frecuentes

¿Hay una CVE para SignDrop?

No. Microsoft no ha asignado una CVE, publicado un aviso ni entregado un parche al 13 de noviembre de 2026. El investigador la llama zero-day, y el repositorio público es el único registro técnico.

¿Afecta a Windows 10?

La función de autenticación CLFS está en Windows 11 25H2, 26H1, 26H2 y Windows Server 2025. Las versiones anteriores no la tienen, así que la ruta SignDrop no se aplica. Su controlador CLFS sigue teniendo fallas de corrupción de memoria, que son un riesgo aparte.

¿Se puede explotar de forma remota?

No. La cadena publicada parte de una sesión de usuario estándar en el dispositivo y necesita ejecución local de código. Es una elevación de privilegios local, no una falla de ejecución de código remoto.

¿Debo desactivar la autenticación CLFS para protegerme?

No. Poner el modo en 2 o 3 desactiva la mitigación y deja que CLFS analice registros manipulados, lo que reabre las fallas de corrupción de memoria que la función debía detener. Mantenga el modo en 0 o 1.

¿La protección contra alteraciones de Defender bloquea el exploit?

No en la cadena publicada. La cadena pide a la interfaz de actualización del propio Defender que abra el registro, así que la creación del archivo ocurre dentro del proceso de confianza de Defender. El investigador dice que eso permite a la técnica eludir la autodefensa, y la prueba independiente confirma el shell SYSTEM en las compilaciones probadas.

¿Se explota en entornos reales?

No se reportan ataques al 13 de noviembre de 2026. El exploit es público, pero la prueba independiente lo encontró poco fiable y visible, y el catálogo KEV de la CISA no lo incluye.

Referencias

• MSNightmare, prueba de concepto y análisis técnico SignDrop, publicada el 2026-11-10: https://github.com/MSNightmare/SignDrop (verificado el 13 de noviembre de 2026)
• Microsoft, «Common Log File System (CLFS) Authentication Mitigation», KB 5056852, fecha de publicación original 2025-10-28, los valores de modo y los atributos de seguridad del archivo compañero: https://support.microsoft.com/en-us/servicing/os/windows/2025/03/common-log-file-system-clfs-authentication-mitigation (verificado el 13 de noviembre de 2026)
• The Hacker News, «New SignDrop Zero-Day Exploit Turns Windows CLFS Security Feature Into SYSTEM Access», 2026-11-12, la cadena de explotación, la prueba independiente y las compilaciones afectadas: https://thehackernews.com/2026/11/new-signdrop-zero-day-exploit-turns.html (verificado el 13 de noviembre de 2026)
• Flujo JSON del catálogo de vulnerabilidades explotadas de la CISA, comprobado para SignDrop el 13 de noviembre de 2026 (no incluido): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (verificado el 13 de noviembre de 2026)
• Security Update Guide de Microsoft, comprobado por una CVE o un aviso de SignDrop el 13 de noviembre de 2026 (ninguno): https://msrc.microsoft.com/update-guide (verificado el 13 de noviembre de 2026)