BlueHammer: Zero Day y exploit que usa Windows Defender para hackear Windows (sin parche)

BlueHammer es un Zero-Day sin parche (CVE-2026-33825 ya parcheado el 14 de abril por Microsoft ) que permite a un usuario local con bajos privilegios escalar a NT AUTHORITY\SYSTEM en menos de un minuto, sin exploits del kernel ni corrupción de memoria. El investigador Will Dormann lo confirmó como operativamente relevante. El código de explotación es público y no ha sido parcheado.

Windows Defender, el antivirus integrado que se ejecuta en todas las máquinas con Windows, tiene un exploit de Zero-Day con el código fuente completo en GitHub. Sin parche, sin CVE, y se confirmó que funciona en Windows 10 y 11 completamente actualizado. Un investigador, que dice que Microsoft incumplió su palabra, simplemente está entregando un escalamiento de privilegios que lleva cualquier cuenta con pocos privilegios directamente a NT AUTHORITY\SYSTEM. En Windows Server el resultado es diferente pero sigue siendo grave: un usuario estándar termina con acceso de administrador elevado.

Historia de BlueHammer

El 2 de abril, el investigador publicó la divulgación pública en un blog personal, y el 3 de abril, el código fuente completo del exploit se publicó en GitHub. Ambos publicados bajo el alias Chaotic Eclipse, también conocido como Nightmare Eclipse, con un mensaje al Centro de Respuesta de Seguridad de Microsoft que se reduce a: "Les dije que esto sucedería".

Antes de entrar en el aspecto técnico, hay una historia de fondo que vale la pena conocer. A finales de marzo, el mismo investigador abrió un blog con una sola publicación en la que explicaba que no quería volver nunca más a la investigación pública. Alguien había llegado a un acuerdo con ellos y luego lo había roto, sabiendo exactamente cuáles serían las consecuencias. La publicación dice que dejó al investigador sin hogar y sin nada. No es alguien molesto por un proceso de revisión lento. Es alguien que no tiene nada que perder.

El exploit

Pasemos ahora al exploit en sí, porque realmente vale la pena entenderlo.

BlueHammer no es un error tradicional y no necesita código shell, corrupción de memoria ni un exploit del kernel para funcionar. Lo que hace es encadenar cinco componentes de Windows completamente legítimos en una secuencia que produce algo que sus diseñadores nunca pretendieron. Esos cinco componentes son: Windows Defender, Volume Shadow Copy Service, la API de archivos en la nube, los bloqueos oportunistas y la interfaz RPC interna de Defender.

Una limitación práctica que vale la pena conocer: el exploit necesita una actualización pendiente de la firma de Defender para estar disponible en el momento del ataque. Sin uno en la cola, la cadena no se activa. Eso lo hace menos confiable que un "exploit de botón", pero no hace que sea seguro ignorarlo.

Así es como funciona la cadena de ataque. Cuando Defender ejecuta una actualización de la definición de antivirus, parte de ese proceso implica la creación de una instantánea de volumen temporal, que es el mismo mecanismo de instantánea que utiliza Windows para realizar copias de seguridad y restaurar. Esa instantánea contiene archivos que normalmente están completamente bloqueados durante el funcionamiento normal, incluida la base de datos SAM, que almacena los hash de contraseña para cada cuenta local en la máquina.

BlueHammer se registra como proveedor de sincronización de Cloud Files, el mismo tipo de cosas que usan OneDrive o Dropbox para sincronizar archivos. Cuando Defender toca un archivo específico dentro de esa carpeta, el exploit recibe una devolución de llamada e inmediatamente coloca un bloqueo oportunista en ese archivo. El defensor se detiene, bloqueado, esperando una respuesta que nunca llega. La instantánea que acaba de crear todavía está montada. La ventana está abierta.

Con Defender congelado, el exploit lee las secciones de registro SAM, SYSTEM y SECURITY directamente desde la instantánea. Descifra los hashes de contraseña NTLM almacenados utilizando la clave de arranque extraída de la sección SYSTEM, cambia la contraseña de una cuenta de administrador local, inicia sesión con esa cuenta, copia el token de seguridad del administrador, lo envía al nivel SYSTEM, crea un servicio temporal de Windows y genera un símbolo del sistema que se ejecuta como NT AUTHORITY\SYSTEM. Luego, para cubrir sus huellas, devuelve el hash de la contraseña original. La contraseña de la cuenta local parece completamente sin cambios. Ningún accidente, ninguna alerta, nada.

Toda la cadena se ejecuta en menos de un minuto desde una sesión de usuario normal. Toda la cadena usa VSS, Cloud Files API y oplocks: herramientas legítimas de Windows, lo que dificulta enormemente la detección por firmas estáticas.

El nombre del proveedor de Cloud Files codificado en el código fuente del exploit es IHATEMICROSOFT. La contraseña de administrador utilizada durante el escalamiento está codificada como $PWNed666!!!WDFAIL. Estos no son errores dejados por accidente. Son mensajes, escritos directamente en el código, y solo hay un lector previsto.

Will Dormann, analista principal de vulnerabilidades de Tharros, probó el exploit y confirmó que funciona lo suficientemente bien como para ser una amenaza real.

Microsoft ha estado recortando costos. Los analistas experimentados que sabían cómo analizar un exploit complejo y comprenderlo realmente han sido reemplazados por personal que sigue rígidas listas de verificación de procesos. Uno de esos requisitos de la lista de verificación es una demostración en video del exploit. Los investigadores que se niegan a grabar un vídeo cierran sus informes.

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.
• Monitorear la enumeración de VSS proveniente de procesos de usuario regulares. Las llamadas a NtQueryDirectoryObject dirigidas a objetos HarddiskVolumeShadowCopy desde cualquier cosa fuera de la copia de seguridad o las herramientas del sistema son una señal de alerta que casi no tiene una explicación inocente.
• Esté atento al registro raíz de sincronización de Cloud Files mediante procesos desconocidos. Vale la pena comprobar de inmediato que se llama a CfRegisterSyncRoot desde cualquier otro dispositivo que no sea OneDrive, Dropbox o Box. Esa llamada es exactamente cómo BlueHammer prepara su trampa.
• Alerta sobre procesos con pocos privilegios que crean servicios de Windows o obtienen tokens a nivel de SYSTEM. BlueHammer usa CreateService para registrar brevemente un servicio malicioso durante el escalamiento, y eso aparece en la telemetría de EDR.
• Estar atento a los cambios rápidos de contraseña consecutivos en las cuentas de administrador local. BlueHammer restablece la contraseña, la usa y luego la restablece. Los ID de eventos de seguridad 4723 y 4724 que se activan dos veces en rápida sucesión en la misma cuenta no tienen una explicación normal.
• Mantener estrictos los permisos. BlueHammer necesita una sesión local para ejecutarse, por lo que cada permiso que un usuario estándar en realidad no necesita es una superficie de ataque que se puede eliminar.
• 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. Hasta ahora solo ha actualizado la firma de Defender como Exploit:Win32/DfndrPEBluHmr.BB, capaz de detectar el binario original del PoC. Sin embargo, esta protección se puede eludir fácilmente simplemente recompilando el código fuente. Investigadores de Cyderes y el reconocido experto Will Dormann ya han corregido la PoC (video) para lograr una explotación más confiable.

Fuente: HackingPassion