Un investigador de seguridad que opera bajo el alias Chaotic Eclipse (@ChaoticEclipse0) ha publicado públicamente un exploit de día cero de escalada de privilegios locales (LPE) para Windows, denominado BlueHammer, junto con el código fuente completo de la prueba de concepto (PoC) en GitHub. La divulgación fue confirmada por el investigador de vulnerabilidades Will Dormann, quien señaló que el exploit funciona y que el propio proceso de respuesta de seguridad de Microsoft podría haber contribuido directamente 

Un investigador de seguridad que opera bajo el alias Chaotic Eclipse (@ChaoticEclipse0) ha publicado públicamente un exploit de día cero de escalada de privilegios local (LPE) funcional para Windows, denominado BlueHammer, junto con el código fuente completo de la prueba de concepto (PoC) en GitHub.

La divulgación fue confirmada por el investigador de vulnerabilidades Will Dormann, quien señaló que el exploit funciona y que el propio proceso de respuesta de seguridad de Microsoft podría haber causado directamente esta publicación no coordinada.

BlueHammer es un exploit de día cero de LPE para Windows que permite a un usuario local con bajos privilegios escalar su acceso a NT AUTHORITY\SYSTEM, el nivel de privilegio más alto en una máquina con Windows.

Una captura de pantalla compartida junto con la divulgación demuestra dramáticamente el impacto: un símbolo del sistema lanzado desde C:\Users\limited\Downloads> —claramente una cuenta de usuario restringida— logra una shell completa de SYSTEM en cuestión de segundos, con whoami confirmando nt authority\system.

La salida del exploit también revela capacidades de recolección de credenciales, mostrando hashes de contraseñas NTLM para cuentas locales, incluyendo un usuario administrativo con IsAdmin: TRUE, y confirmaciones de SYSTEMShell: OK, Shell: OK y PasswordRestore: OK.

El sistema comprometido ejecuta Windows 11 (Build 10.0.26200.8037), lo que indica que la vulnerabilidad afecta a instalaciones modernas y completamente actualizadas de Windows.

El investigador citó la frustración con el Microsoft Security Response Center (MSRC) como la principal motivación detrás de la divulgación pública no coordinada.

Según Chaotic Eclipse, la calidad del MSRC ha deteriorado significativamente en los últimos años, atribuyendo este declive a que Microsoft despidió a personal de seguridad con experiencia y los reemplazó con empleados que siguen flujogramas procedimentales rígidos en lugar de ejercer un juicio informado.

Un detalle particularmente crítico en la divulgación: el MSRC supuestamente exigió al investigador que enviara un video demostrando el exploit como parte del proceso de reporte de vulnerabilidades, un requisito que muchos en la comunidad de seguridad han considerado inusual y exigente.

El investigador sugiere que esta demanda pudo haber sido un punto de fricción deliberado que finalmente llevó al cierre o estancamiento del caso sin resolución.

Este tipo de divulgación, a veces llamada "full drop" o divulgación no coordinada, es cada vez más común cuando los investigadores sienten que sus reportes son ignorados o mal gestionados por los proveedores. Ejerce presión inmediata sobre el proveedor para que actúe, pero también pone en riesgo a los usuarios antes de que haya una solución disponible.

Chaotic Eclipse señaló que el exploit no funciona con un 100% de fiabilidad, pero reconoció que funciona "lo suficientemente bien" como para ser operativamente útil. En manos de un actor de amenazas habilidoso, incluso un exploit de LPE parcialmente fiable puede ser refinado y convertido en un arma.

Grupos de ransomware y actores de APT suelen integrar código PoC publicado públicamente en sus herramientas en cuestión de días después de su divulgación.

Mitigaciones

Hasta que Microsoft emita un parche oficial o un aviso de mitigación, los equipos de seguridad deben tomar las siguientes medidas preventivas:

• Monitorear herramientas de detección y respuesta en endpoints (EDR) en busca de actividad inusual de escalada de privilegios.
• Restringir los permisos de usuarios locales al mínimo necesario para las operaciones.
• Aplicar un registro mejorado en sistemas Windows para detectar procesos anómalos a nivel de SYSTEM.
• Estar atentos a una actualización de seguridad de Microsoft o un aviso que aborde la vulnerabilidad BlueHammer.

Microsoft aún no ha emitido una declaración pública ni asignado un CVE para esta vulnerabilidad en el momento de la publicación.