Tres zero-days de Windows en la naturaleza. Uno tiene parche. Esto es lo que debe hacer con los otros dos.

Qué ocurrió
Un investigador de seguridad conocido como «Chaotic Eclipse» publicó en GitHub el 3 de abril código funcional de un exploit para una vulnerabilidad de escalada local de privilegios en Windows llamada BlueHammer. Sin divulgación coordinada, sin asignación de CVE, sin parche. Según se informó, el investigador estaba frustrado con la forma en que se gestionó su reporte de vulnerabilidad y decidió hacerlo público.
Después las cosas empeoraron. Aparecieron dos exploits más: RedSun y UnDefend, ambos dirigidos a los propios procesos de Windows Defender para elevar un usuario con bajos privilegios a acceso de nivel SYSTEM. Microsoft publicó un parche para BlueHammer (ahora CVE-2026-33825) en la actualización del Patch Tuesday del 15 de abril, pero RedSun y UnDefend siguen sin parche a día de hoy. Y los atacantes no están esperando. Huntress confirmó esta semana que los tres exploits se están utilizando contra objetivos empresariales en producción.
Por qué este caso importa más que el ruido habitual del Patch Tuesday
El Patch Tuesday de abril ya era masivo por sí solo: 167 vulnerabilidades corregidas, ocho de ellas calificadas como críticas, más un zero-day de Adobe Reader que ha sido explotado desde noviembre de 2025. Es mucho. Pero la historia de BlueHammer es la que no deja de rondarnos, porque no es solo una historia de vulnerabilidades. Es una historia de fallo de proceso.
Los propios exploits son ingeniosos. BlueHammer abusa de una falla de sincronización en el flujo de actualización de firmas de Windows Defender, encadenando Volume Shadow Copy, callbacks de la Cloud Files API y bloqueos oportunistas para pausar a Defender en el momento exacto y leer colmenas del registro (SAM, SYSTEM, SECURITY) que normalmente están bloqueadas. Sin exploit de kernel, sin corrupción de memoria, sin shellcode. Solo características legítimas de Windows combinadas en el orden equivocado. El equipo Cyderes Howler Cell verificó de forma independiente que la cadena completa funciona en sistemas Windows 10 y 11 parcheados.
RedSun es, sin lugar a dudas, más peligroso. Engaña al motor de protección en tiempo real de Defender para que entre en un ciclo de detección y corrección usando un archivo de prueba EICAR como señuelo, y luego explota la lógica de corrección para sobrescribir archivos del sistema y obtener privilegios de administrador. Funciona incluso después de aplicar los parches de abril.
Lo que hace que esto sea especialmente incómodo para los equipos de desarrollo: estos exploits atacan Windows Defender, la herramienta que la mayoría de las organizaciones asume que está protegiendo sus endpoints. Si su equipo desarrolla y despliega en Windows, sus máquinas de desarrollo, sus runners de CI y sus servidores de staging están todos en el alcance.
Qué significa esto para los equipos de desarrollo
Durante nuestro trabajo de pruebas de penetración con estudios de videojuegos y clientes empresariales, hemos visto una y otra vez que la escalada local de privilegios es el paso que convierte un punto de apoyo menor en un compromiso total. Alguien hace clic en un enlace de phishing, obtiene una shell limitada, y si la LPE es sencilla, el juego termina. Estos tres exploits hacen que la LPE sea muy fácil en máquinas Windows sin parche.
La preocupación práctica para los equipos de desarrollo es esta: las estaciones de trabajo de los desarrolladores suelen ser el eslabón más débil. Tienden a tener más software instalado, más excepciones en las políticas de seguridad y más acceso de administrador local del que deberían. Hemos encontrado este patrón repetidamente, ya sea que estemos evaluando plataformas de viajes o despliegues de SaaS empresarial. La máquina del desarrollador es la puerta de entrada de los atacantes, y la escalada de privilegios es lo que les permite quedarse.
Con dos de los tres exploits todavía sin parche, esta vez no basta con «aplicar la actualización y seguir adelante».
Qué debe hacer ahora mismo
Primero, aplique las actualizaciones del Patch Tuesday de abril de inmediato si aún no lo ha hecho. Eso cubre BlueHammer y las otras 166 vulnerabilidades, incluyendo el zero-day de Adobe Reader y un RCE crítico de Active Directory (CVE-2026-33826). Esto no es opcional.
Segundo, para RedSun y UnDefend necesita controles compensatorios hasta que Microsoft publique los parches:
- Busque los indicadores conocidos. Huntress informó que los atacantes están colocando binarios llamados FunnyApp.exe, RedSun.exe y z.exe en las carpetas Imágenes de los usuarios y en subcarpetas de dos letras dentro de Descargas. Realice búsquedas de estos archivos. Configure alertas para ejecutables inesperados en los directorios de perfil de usuario.
- Supervise la escalada de privilegios y el acceso a SAM. Cualquier proceso que salte repentinamente de usuario estándar a SYSTEM, o cualquier acceso inesperado a la base de datos SAM, debe disparar una alerta. Si su EDR no está detectando esto, tiene un problema mayor.
- Aplique el principio de mínimo privilegio de forma estricta. Estos exploits requieren acceso local. Cada reducción en quién puede iniciar sesión, qué puede ejecutar y qué derechos de administrador local posee hace que la explotación sea más difícil. Esta es una buena semana para auditar las políticas de las máquinas de los desarrolladores.
- Revise sus runners de CI/CD. Si utiliza agentes de compilación basados en Windows, asegúrese de que no sean accesibles desde internet, de que no se ejecuten con privilegios innecesarios y de que no almacenen credenciales que puedan ser recolectadas tras una explotación.
Tercero, no olvide el zero-day de Adobe Reader. Si su equipo recibe archivos PDF —y todos los equipos lo hacen—, actualice Reader y Acrobat. Este ha sido explotado desde finales de 2025 y acaba de recibir parche.
El panorama general: la divulgación coordinada se está resquebrajando
La frustración del investigador con el proceso de divulgación no es nueva, pero se está volviendo más frecuente. Cuando reportar vulnerabilidades parece gritar al vacío, algunos investigadores optan por hacerlo público por despecho. Eso es malo para todos, pero la respuesta de los fabricantes afectados necesita ser más rápida y más respetuosa con quienes encuentran estos fallos.
En nuestro trabajo de seguridad hemos estado en ambos lados. Hemos reportado hallazgos a fabricantes que actuaron con rapidez y lo tomaron en serio. También hemos tenido reportes en el limbo durante meses. El proceso del MSRC ya ha recibido críticas antes, y este incidente —en el que el investigador dijo explícitamente que había advertido lo que sucedería— es un claro ejemplo de lo que se rompe cuando la confianza entre investigadores y fabricantes se erosiona.
Para los equipos que dependen de infraestructura Windows, esto significa que no pueden confiar simplemente en que las vulnerabilidades serán parcheadas en silencio antes de convertirse en su problema. Necesitan capacidades de detección y respuesta que asuman que los zero-days van a ocurrir, porque seguirán ocurriendo.
También merece atención esta semana
Más allá del drama de Windows, vale la pena revisar Apache ActiveMQ CVE-2026-34197. Un investigador usó un asistente de inteligencia artificial para encontrar una vulnerabilidad de ejecución remota de código que llevaba 13 años oculta en el código. Si ejecuta ActiveMQ, aplique el parche. Y la variante de malware Chaos que ahora apunta a servidores Linux en la nube mal configurados —que antes se limitaba a routers— es un recordatorio de que cada servicio expuesto a internet necesita ser reforzado, no solo los que se cree que interesan a los atacantes.
Cuando configuramos infraestructura en la nube y establecemos protección DDoS para nuestros clientes, el primer paso es siempre un inventario honesto de lo que realmente está expuesto. La mayoría de los equipos se sorprenden con lo que encuentran.
Conclusión
Esta semana es un recordatorio de que la seguridad de los endpoints no es algo que se configura una vez y se olvida. Dos zero-days de escalada de privilegios sin parche están en uso activo, apuntando a la propia herramienta (Windows Defender) en la que la mayoría de las organizaciones confía para su protección. Los equipos de desarrollo con los que trabajamos conocen este patrón: la seguridad no es un producto que se compra, es un proceso que se mantiene.
Parchee lo que pueda, detecte lo que no pueda parchear y refuerce las políticas de acceso local en sus máquinas de desarrollo y servidores de compilación. Si no está seguro del estado de su entorno Windows o quiere ayuda para analizar la exposición a estos zero-days, hablemos.