SignDrop en Windows: cómo comprobar si tu equipo está expuesto

SignDrop en Windows: cómo comprobar si tu equipo está expuesto

SignDrop es un exploit público que puede permitir a un usuario local elevar sus privilegios hasta SYSTEM en Windows, aprovechando la forma en que el sistema de registro CLFS crea archivos de autenticación. La investigación publicada lo probó en Windows 11 26H2 y versiones experimentales de Windows 11 y Windows Server 2025; Microsoft dijo a SecurityWeek que investiga el fallo, que Defender detecta y bloquea la explotación y que no ha observado ataques en circulación. Comprueba el modo de CLFS, pero no ejecutes el PoC.

Quién puede estar afectado y cómo comprobarlo

La vulnerabilidad, bautizada SignDrop por su autor, Abdelhamid Naceri, conocido como Nightmare Eclipse, gira en torno a CLFS, el subsistema de Windows que gestiona registros. El exploit prepara archivos de registro y busca que un proceso con privilegios los abra; según la explicación técnica, el archivo auxiliar de autenticación puede acabar creado con permisos SYSTEM y conservar permisos que permiten modificarlo al usuario que lo preparó.

La comprobación que proponen el investigador y las coberturas de The Hacker News y BleepingComputer consiste en leer el valor Mode de esta clave del Registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode

Los valores 0 y 1 indican exposición según el alcance descrito para SignDrop: corresponden a los modos de aprendizaje y aplicación de la autenticación. The Hacker News señala que los sistemas suelen pasar del modo de aprendizaje al de aplicación después de 90 días. Los valores 2 y 3 quedan fuera del ataque descrito, pero no son una solución recomendable: desactivar la mitigación permite que CLFS vuelva a procesar registros manipulados y puede exponer el equipo a vulnerabilidades de corrupción de memoria.

Las pruebas publicadas se realizaron en Windows 11 26H2, Windows 11 26H2 Experimental y Windows Server 2025 Experimental. Naceri estima que el fallo afecta a una gran parte de las instalaciones de Windows, pero esa cifra es una estimación suya, no una medición independiente. SecurityWeek recoge además que Cyderes compiló y probó el PoC; una evaluación independiente citada por The Hacker News encontró que el exploit funciona, aunque no con fiabilidad suficiente para uso operativo.

Qué hacer ahora

  1. Lee el valor, sin cambiarlo. Abre el Editor del Registro y navega hasta HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication; consulta el dato de Mode. Si no tienes experiencia con el Registro, pide ayuda al administrador del equipo en lugar de editar claves. La comprobación debe limitarse a observar si el valor es 0, 1, 2 o 3.

  2. Si aparece 0 o 1, trata el equipo como expuesto. No significa que el sistema haya sido atacado: indica que coincide con los modos que el investigador considera vulnerables. En equipos administrados, comunica el valor al equipo responsable de seguridad o de TI para que pueda evaluar el dispositivo y seguir las actualizaciones de Microsoft.

  3. Mantén activa la mitigación de CLFS. No cambies el valor a 2 o 3 para intentar cerrar SignDrop. Aunque esos modos quedan fuera del ataque publicado, tanto el investigador como la documentación citada advierten de que desactivar la autenticación deja de proteger frente a registros manipulados y a los fallos de corrupción de memoria que la mitigación busca contener.

  4. Deja activado Microsoft Defender. La cadena del PoC publicado requiere que Defender esté activo, según The Hacker News. SecurityWeek recoge que Microsoft afirma que Defender detecta y bloquea la explotación y alerta sobre la conducta de elevación de privilegios. No deshabilites el antivirus ni la protección contra manipulaciones para probar el fallo.

  5. Aplica las actualizaciones oficiales de Windows cuando estén disponibles y sigue la guía de actualizaciones de seguridad de Microsoft. Las actualizaciones de noviembre citadas por The Hacker News no incluyeron un parche para SignDrop. SecurityWeek informó de que Microsoft estaba investigando la vulnerabilidad; por tanto, no hay en estos datos una corrección específica que instalar ni una versión corregida que recomendar.

  6. Escala cualquier alerta o actividad sospechosa al administrador o al equipo de seguridad de tu organización. La información publicada no confirma ataques reales con SignDrop, y Microsoft dijo a SecurityWeek que no había observado explotación en circulación. Esa ausencia de casos observados no permite concluir que un dispositivo concreto esté limpio si hay otros indicios de compromiso.

Errores que pueden empeorar la situación

No ejecutes el exploit de prueba en tu ordenador para averiguar si es vulnerable. BleepingComputer recoge que Naceri propone usar el PoC o revisar el Registro, pero la comprobación del valor evita ejecutar código de explotación. Además, The Hacker News advierte que el PoC publicado puede cambiar las solicitudes de UAC para abrir una consola de usuario estándar y otra SYSTEM, bloqueando otras acciones y haciendo visible la prueba.

No confundas “fuera del alcance del PoC” con “más seguro”. Los valores 2 y 3 desactivan la mitigación de autenticación de CLFS; el propio mecanismo se introdujo para limitar ataques contra vulnerabilidades del controlador. Desactivar esa protección cambia un riesgo por otro, no aplica un arreglo para SignDrop.

Tampoco des por hecho que cualquier antivirus esté protegido frente a la técnica. Naceri afirma que podría afectar a motores antimalware con procesos privilegiados, pero The Hacker News señala que esa posibilidad más amplia no se ha probado. La cadena publicada se sirve de Defender; Microsoft sostiene que su producto detecta y bloquea la explotación.

Por último, no interpretes la publicación de un PoC como prueba de ataques en curso ni la falta de reportes como garantía de seguridad. La información disponible describe un riesgo local que puede elevar privilegios y una respuesta de Microsoft aún en investigación. Para el usuario, el paso práctico ahora es comprobar Mode sin alterarlo y esperar una corrección oficial.

Fuentes: BleepingComputer, The Hacker News, SecurityWeek, GitHub