Por Canuto  

Un investigador publicó SignDrop, una prueba de concepto que, según afirma, aprovecha una mitigación de Windows para elevar privilegios y podría interferir con la autoprotección de antivirus. El caso plantea una paradoja: la misma defensa diseñada para limitar ataques contra CLFS puede abrir una vía de abuso cuando un proceso privilegiado manipula archivos de registro.

***

  • SignDrop apunta a clfs.sys y abusa de la creación de archivos de autenticación asociados a registros CLFS.
  • El investigador dice que puede inducir a Windows Defender a crear archivos con privilegios SYSTEM y que la técnica podría afectar a otros motores antimalware.
  • No hay una solución alternativa sin costo: desactivar la mitigación elimina esta vía, pero vuelve a exponer el sistema a fallos de corrupción de memoria en CLFS.

 

 

Un investigador de seguridad que usa el nombre Chaotic Eclipse publicó una prueba de concepto de SignDrop, un exploit de escalada local de privilegios en Windows que, según su análisis, aprovecha una mitigación contra ataques al Common Log File System (CLFS).

La falla estaría en la forma en que el controlador clfs.sys gestiona ciertos archivos de autenticación, y la cadena puede llevar a que un proceso con privilegios elevados cree archivos en nombre de un usuario local. SecurityAffairs informó que el investigador difundió el código y un análisis técnico en GitHub.

El caso tiene una consecuencia adicional, más allá de conseguir privilegios SYSTEM: Chaotic Eclipse afirma que la misma técnica podría utilizarse contra mecanismos de autoprotección de antivirus y otros productos de seguridad. Su demostración apunta a Windows Defender, aunque el investigador sostiene que el patrón podría aplicarse también a otros motores antimalware. Microsoft no aparece en el material como autor de una confirmación o de un parche disponible, y desactivar la mitigación no es una salida inocua.

Una protección de CLFS que puede volverse contra el sistema

CLFS es un componente de Windows que procesa archivos de registro complejos en modo kernel, una característica que lo ha convertido en objetivo de vulnerabilidades de corrupción de memoria. Para reducir ese riesgo, Microsoft introdujo una mitigación de autenticación de CLFS que comenzó a llegar al canal público el 28 de octubre de 2025. El mecanismo busca comprobar que cada archivo de registro tenga un código de autenticación válido antes de permitir su uso.

La implementación se despliega en dos etapas, según el análisis divulgado por el investigador. Durante los primeros 90 días el sistema opera en un modo de aprendizaje y, después, la protección completa exige una autenticación válida para cada archivo de registro. Chaotic Eclipse atribuye SignDrop a la lógica de este despliegue, aunque su descripción de qué sistemas siguen expuestos no resulta completamente clara.

El experto estima que cerca del 80% de las instalaciones de Windows en el mundo podrían ser vulnerables, pero esa cifra es una estimación suya y no una medición independiente presentada en el material. También sostiene que los equipos que conservan el modo de aprendizaje o tienen la mitigación habilitada solo parcialmente permanecen expuestos. En otra afirmación, dice que en general una instalación de Windows con más de 90 días puede ser vulnerable, una frase que no encaja de manera directa con la explicación de que la protección completa se activa después de ese período.

El investigador propone revisar la configuración del registro en HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCLFSAuthenticationMode. Según su guía, los valores 0 o 1 indican que el equipo es vulnerable, mientras que 2 o 3 señalan que está protegido. También recomienda ejecutar la prueba de concepto para comprobar si esta logra abrir una consola con privilegios SYSTEM, aunque esa comprobación implica ejecutar código de explotación y no debe confundirse con una revisión pasiva de la configuración.

Cómo SignDrop utiliza el proceso privilegiado de Defender

El problema descrito se ubica en clfs.sys, específicamente en la creación del archivo de autenticación con extensión .cnpf asociado a un nuevo contenedor de registro. CLFS sí realiza comprobaciones de acceso cuando un proceso crea sus propios archivos de registro: utiliza la opción OBJ_FORCE_ACCESS_CHECK para que los objetos nuevos permanezcan sujetos al contexto del proceso que inició la operación. La falla, según el investigador, aparece cuando un contenedor tiene otro archivo vinculado.

Al abrir el archivo original, CLFS también puede abrir el archivo asociado; si este último está vacío, el controlador intenta firmarlo, incluso cuando ya existe un archivo de firma. Esa operación se vuelve peligrosa si un proceso con más privilegios abre el registro preparado por un usuario distinto. Chaotic Eclipse afirma que un usuario estándar no necesita permisos especiales para abrir un archivo CLFS si conoce la ruta correcta, por lo que podría preparar el archivo y tratar de inducir a un proceso privilegiado a manipularlo.

En la demostración, el investigador hace que Windows Defender abra el contenedor mediante una llamada a ServerMpUpdateEngineSignature y cambios en enlaces simbólicos del Administrador de Objetos de Windows. Defender utiliza entonces la ruta guardada en el contenedor original para localizar el archivo asociado. Si ese archivo carece de firma, CLFS puede crear la autenticación correspondiente dentro del contexto privilegiado de Defender, de acuerdo con el análisis publicado.

El detalle relevante es que CLFS crea el archivo de autenticación nuevo usando la DACL del archivo original, una lista que determina quién puede acceder a ese objeto. El investigador plantea que, si todos los pasos de la cadena se coordinan, una mitigación legítima puede terminar facilitando una elevación de privilegios. No presenta el comportamiento como una vulnerabilidad en la que cada comprobación individual esté necesariamente ausente, sino como un abuso de la lógica que conecta la apertura del registro con la creación del archivo asociado.

El riesgo para antivirus y la falta de una salida sencilla

Chaotic Eclipse sostiene que SignDrop podría dirigirse a cualquier motor antimalware, no solo a Windows Defender, porque la solicitud de creación de archivos parecería originarse en el proceso legítimo del propio producto. Según su explicación, esa apariencia puede hacer que los controladores del antivirus acepten la operación como una acción autorizada y permitan sortear defensas contra manipulaciones. Se trata de una posibilidad planteada por el investigador, no de una confirmación de que todos los antivirus hayan sido probados o afectados.

Si la técnica funcionara contra otros productos como él afirma, el impacto potencial abarcaría tanto la elevación de privilegios como la interferencia con controles diseñados para impedir que un atacante desactive el software de seguridad. Esa distinción importa: el material describe una prueba dirigida a Defender y luego extrapola el mecanismo a otros motores. No ofrece una lista de productos verificados ni detalla resultados de pruebas independientes que confirmen ese alcance más amplio.

El investigador probó la prueba de concepto en Windows 11 26H2, Windows 11 26H2 Experimental y Windows Server 2025 Experimental. Esas versiones son las que cita para sus ensayos, pero la publicación también presenta una estimación general de exposición que no equivale a una validación de todas las ediciones de Windows. La configuración de autenticación indicada por el propio investigador es, en su propuesta, una referencia para distinguir equipos protegidos de los que mantienen valores vulnerables.

Deshabilitar la mitigación de autenticación de CLFS impediría la vía específica que describe SignDrop, pero también eliminaría una barrera que Microsoft introdujo para frenar vulnerabilidades de corrupción de memoria en ese sistema de archivos. Por eso, el investigador afirma que no existe por ahora una solución alternativa sin costo y que los usuarios deben esperar un parche de Microsoft. El material no ofrece una fecha de corrección ni señala que la compañía haya publicado una actualización para resolver el problema.

La trayectoria de Chaotic Eclipse y sus divulgaciones

Chaotic Eclipse también es conocido por los alias INFINITE NIGHTMARE, MSNightmare y Nightmare-Eclipse, entre otros. La fuente lo describe como un investigador que suele publicar pruebas de concepto de fallos zero-day, en ocasiones después de cuestionar cómo los proveedores gestionan los reportes de vulnerabilidades. Sus divulgaciones se han concentrado sobre todo en productos de Microsoft, incluidos Windows y Defender, y algunas vulnerabilidades que publicó fueron explotadas posteriormente, según el artículo fuente.

Entre los casos anteriores que menciona la publicación figuran Undefend y RedSun, dirigidos a Defender. En septiembre, el investigador también divulgó BigDiskBuster, un exploit que, según su descripción, provoca una denegación de servicio en Windows Defender Update; ese mismo mes publicó exploits contra Nvidia, bajo el nombre GreenSection, y contra Microsoft Defender, bajo el nombre ShieldCrash. El material no detalla aquí resultados independientes para cada uno de esos casos.

La lista de divulgaciones incluye además HardBreacher, una prueba de concepto contra Kaspersky Endpoint Security que el investigador presentó como una falla de escalada de privilegios. Naceri advirtió que el exploit era inestable y podía requerir varios intentos, pero sostuvo que, cuando funcionaba, creaba una DLL en System32 con permisos completos de usuario. También afirmó que tomar el control del proceso de interfaz de Kaspersky podía interrumpir el antivirus e interferir con controles de acceso a archivos, con el riesgo de dejar el sistema inestable.

El investigador publicó asimismo PrettyPrague, dirigido a Avast, de GenDigital, y descrito como un exploit de escalada de privilegios; además, presentó FalconFlank contra la plataforma de ciberseguridad Crowdstrike Falcon con el mismo tipo de objetivo. La publicación señala que recientemente reveló que su nombre es Abdelhamid Naceri y que antes trabajó con Microsoft en Reino Unido y Alemania. La historia sobre su salida de la empresa y sus disputas legales proviene de su propio relato, no de una resolución independiente incluida en el material.

En una publicación que luego eliminó, Naceri dijo que Microsoft puso fin a su empleo sin darle una explicación clara y que rechazó varios acuerdos financieros porque quería una justificación formal y ayuda para permanecer en Alemania. Afirmó que impugnó el despido ante un tribunal laboral alemán, que la empresa cambió sus argumentos durante el proceso y que el tribunal finalmente ratificó la decisión. También contó que la disputa le dejó casi sin compensación y le causó dificultades financieras y emocionales, incluido un tratamiento en un hospital psiquiátrico.

Naceri admitió además que había inventado una afirmación anterior sobre supuestas acciones legales de Microsoft en su contra, surgida durante la controversia por amenazas legales contra investigadores que divulgaron vulnerabilidades zero-day. Ese antecedente da contexto a la publicación de SignDrop, pero no resuelve por sí mismo la validez técnica del exploit ni sustituye una evaluación del fabricante. Por ahora, el punto central para los usuarios es distinguir entre las afirmaciones del investigador, las pruebas que publicó y una eventual confirmación o corrección oficial.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

 


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados