Las investigaciones en materia de seguridad a veces dan lugar a situaciones incómodas. A principios de abril, un investigador conocido como Chaotic Eclipse o Nightmare-Eclipse publicó en GitHub un código de explotación de prueba de concepto para tres vulnerabilidades de Windows Defender, no como parte de un proceso de divulgación coordinada, sino como protesta directa contra la forma en que el Centro de Respuesta de Seguridad de Microsoft gestionó el proceso de notificación. En menos de dos semanas, Huntress Labs confirmó que los autores de amenazas habían utilizado los tres exploits contra objetivos empresariales reales.
No publicamos esto para criticar a Microsoft. El «Patch Tuesday» seguirá siendo una tarea periódica de gestión de parches para todas las organizaciones que utilicen Windows. Lo que sí merece la pena analizar es el problema estructural que ponen de manifiesto estas tres vulnerabilidades: tu capa de protección de terminales no es un observador neutral. Es un participante activo en el sistema de archivos, y los atacantes expertos han aprendido a utilizar esa participación en tu contra.
Analicemos qué hace cada vulnerabilidad, cómo se encadenan entre sí desde el punto de vista operativo y por qué la Vectra AI —concretamente a través de la interfaz Respond UX (RUX) y sus integraciones EDR— está preparada para detectar esta actividad allí donde las herramientas de perímetro y de endpoints no llegan.
Las tres vulnerabilidades: qué hacen realmente
BlueHammer (CVE-2026-33825): una carrera contra el defensor
BlueHammer es una condición de carrera de «tiempo de comprobación a tiempo de uso» (TOCTOU) oculta en el flujo de trabajo de actualización de firmas de Windows Defender. El exploit encadena bloqueos oportunistas (oplocks), la API de Windows Cloud , uniones NTFS y enlaces simbólicos de Object Manager para redirigir una lectura de archivo iniciada por Defender, desviándola de una actualización de firmas legítima y dirigiéndola hacia el subárbol del registro SAM en una instantánea de Copia de seguridad instantánea de volumen.
En pocas palabras: Defender intenta leer un archivo de actualización en el que confía, y un atacante aprovecha una condición de carrera que redirige esa lectura a una copia de la base de datos SAM a la que normalmente no se podría acceder. Defender realiza la lectura con sus privilegios de SYSTEM y entrega al atacante el contenido de SAM. A partir de ahí, el exploit extrae los hash NTLM, utiliza el método «pass-the-hash» para hacerse con el control de una cuenta de administrador local y genera un shell con privilegios de SYSTEM.
No hay ningún exploit del núcleo. No hay corrupción de memoria. Solo un ingenioso aprovechamiento de la forma en que Defender interactúa con el sistema de archivos durante una actualización.
RedSun: El parche no lo solucionó
RedSun sigue un patrón de ataque similar —la API Cloud , oplocks y una unión de directorios que redirige una reescritura activada por Defender a una ruta del sistema protegida—, pero se centra en un componente diferente: TieringEngineService.exe. Lo que hace que RedSun sea más significativo desde el punto de vista operativo es que funciona en sistemas con Windows 10, Windows 11 y Windows Server 2019 y versiones posteriores totalmente actualizados, incluso tras las actualizaciones del «Patch Tuesday» de abril.
El exploit engaña al motor de protección en tiempo real de Defender utilizando una cadena de prueba EICAR integrada. Defender detecta una firma conocida, inicia un ciclo de corrección y RedSun se adelanta para redirigir la reescritura del archivo resultante. En ese momento, la infraestructura Cloud ejecuta el archivo binario implantado por el atacante con privilegios de SYSTEM.
RedSun no necesita una nueva vulnerabilidad. Lo único que necesita es que Defender esté en funcionamiento y cumpla con su cometido. Esa es la parte incómoda.
El investigador de seguridad Will Dormann confirmó que el exploit funciona en sistemas con todos los parches instalados, y Huntress detectó archivos binarios ocultos en directorios de usuarios con pocos privilegios —carpetas de «Imágenes» y subcarpetas de dos letras dentro de «Descargas»— con nombres de archivo procedentes de los repositorios originales de PoC (FunnyApp.exe, RedSun.exe) y en variantes renombradas como z.exe.
UnDefend: Deteriorando silenciosamente la capa de defensa
UnDefend no eleva los privilegios directamente. En su lugar, altera el mecanismo de actualización de definiciones de Defender para reducir progresivamente, con el paso del tiempo, la precisión de detección de la capa de protección del punto final. Si lo ejecutas como un proceso secundario de cmd.exe en el Explorador y lo ejecutas con el indicador -agressive —exactamente el patrón que Huntress observó en incidentes reales—, empezarás a privar a Defender de la inteligencia sobre amenazas actual sin provocar el tipo de fallo grave que generaría una alerta evidente.
Esta combinación tiene importancia desde el punto de vista operativo. Un atacante utiliza BlueHammer o RedSun para obtener privilegios de sistema y, a continuación, implementa UnDefend para garantizar que la capa de protección del terminal sea cada vez menos capaz de detectar la actividad posterior. Se trata de una estrategia de degradación por capas, no de un exploit puntual.
El patrón de ataque observado por la Cazadora
La actividad observada en el entorno real no consiste en una propagación automática. El análisis de los incidentes realizado por Huntress a fecha de 16 de abril describe un patrón compatible con una intrusión manual: se ejecutan comandos de enumeración manuales antes de la explotación, entre ellos «whoami /priv» para determinar los privilegios actuales. Los archivos binarios se colocan deliberadamente en directorios de usuario poco visibles. Se trata de una intrusión selectiva, no malware genérico.
Ese contexto es importante a la hora de determinar cómo deben enfocar la detección los defensores. Un escáner estándar que busque hash o firmas de amenazas conocidas podría detectar los binarios originales del PoC. Sin embargo, un archivo z.exe renombrado con una cadena EICAR cifrada —que, como demostró Dormann, reduce fácilmente las detecciones en VirusTotal— no lo hará. La huella de comportamiento es lo que se mantiene constante en todas las variantes.
El patrón de reconocimiento observado antes de la explotación —enumeración de privilegios, instalación deliberada en directorios en los que el usuario tiene permisos de escritura, generación de procesos secundarios bajo el Explorador— es detectable. No en la capa del terminal que es el objetivo, sino en la capa de red e identidad situada por encima de ella.
Vectra AI en este contexto
Las herramientas de protección de terminales son el objetivo directo de estos exploits. Esto no es una crítica al EDR, sino una descripción precisa de la superficie de ataque. Cuando los exploits tienen éxito, actúan dentro del perímetro de confianza del que dependen los agentes de los terminales. Para detectar lo que ocurre a continuación se necesita una visibilidad que no dependa de la integridad del agente del terminal.
La detección y respuesta en la red —concretamente, la Vectra AI que opera a través de RUX— proporciona esa visibilidad. Aquí es donde resulta fundamental a lo largo de toda la cadena de ataque.
Pre-explotación: enumeración basada en el comportamiento
La enumeración manual documentada por Huntress (whoami /priv, inventario de privilegios) genera eventos de ejecución de procesos y de línea de comandos que las integraciones EDR de Vectra muestran como señales de terceros directamente dentro de RUX. Para las organizaciones que utilizan CrowdStrike Falcon, la correlación de procesos EDR —que entró en fase de disponibilidad general en RUX en marzo de 2026— identifica automáticamente qué proceso de un punto final ha desencadenado el comportamiento de red sospechoso detectado por Vectra, eliminando la brecha de correlación manual entre la telemetría de NDR y EDR. La integración de IA de Microsoft Defender for Endpoint está prevista para el primer semestre de 2026, y la integración MDE existente ya admite el enriquecimiento del contexto del host y el bloqueo del host. SentinelOne proporciona intercambio bidireccional de metadatos y capacidad de bloqueo. En los tres casos, Attack Signal Intelligence estos comportamientos a nivel de host con el contexto de red de la cuenta y el dispositivo, aplicando una puntuación de urgencia que tiene en cuenta los privilegios de la cuenta, la amplitud del movimiento lateral y la velocidad.
Un analista de RUX no recibe una alerta aislada de «whoami». Recibe una vista de entidad priorizada que muestra la cuenta en cuestión, los activos a los que ha accedido, cómo se presenta la enumeración de privilegios en comparación con su línea de base y cuál es la puntuación de urgencia, todo ello en un solo lugar, sin necesidad de cambiar de pestaña.
Escalada de privilegios: anomalías en los procesos de la red
La ejecución de procesos con privilegios de «SYSTEM» tras una acción correctiva de Defender genera anomalías detectables. Un proceso iniciado con privilegios de «SYSTEM» en la carpeta «Imágenes» de un usuario, que establece conexiones salientes hacia una infraestructura a la que no debería acceder, es susceptible de ser detectado por varios modelos de Vectra: vinculación sospechosa entre procesos y la red, elevación anómala de privilegios y patrones inusuales de conexiones salientes.
La IA de Vectra integra estas señales en tiempo real, independientemente de los cambios en las direcciones IP y los contextos de sesión. Cuando un analista inicia la investigación en RUX, el gráfico del ataque ya está completo: el host comprometido original, el evento de escalada de privilegios correlacionado con la señal de EDR a nivel de proceso y cualquier conexión lateral iniciada desde la sesión recién elevada.
UnDefend: La degradación como señal de detección
Aquí es donde la ventaja de NDR se hace más evidente. Una herramienta de punto final cuyo rendimiento se ve mermado por UnDefend se vuelve cada vez menos fiable, lo que significa que la brecha de detección aumenta con el tiempo a nivel del host. Vectra no depende de esa herramienta para mantener la visibilidad. Las referencias de comportamiento de red se mantienen independientemente del estado del agente del punto final.
En términos más prácticos: el hecho de que UnDefend se ejecute como un proceso secundario de cmd.exe en el Explorador, con el parámetro -agressive, constituye el tipo de relación anómala entre procesos principal y secundario que las integraciones de EDR detectan en RUX como una alerta de terceros. Al correlacionarse con los patrones de supresión de actualizaciones salientes de Defender en la capa de red, la señal adquiere un alto grado de fiabilidad y permite una investigación rápida.
Respuesta: Contención con un solo clic
La capacidad de respuesta integrada de RUX —que permite pasar con un solo clic a CrowdStrike, Microsoft Defender for Endpoint o SentinelOne— significa que un analista que detecte un host que esté siendo objeto de un ataque activo no tiene que cambiar de consola. Las acciones de bloqueo del host, suspensión de la cuenta y aislamiento de la red están disponibles directamente desde la vista de investigación.
Para las organizaciones que utilizan Vectra MXDR, esa capacidad de respuesta incluye una cobertura de analistas las 24 horas del día, los 7 días de la semana. Un intento de ataque a las 2 de la madrugada de un sábado no espera a que sea horario de oficina.
Qué significa esto en la práctica
En el momento de redactar este artículo, dos de estas tres vulnerabilidades siguen sin tener parche. RedSun funciona en sistemas con todas las actualizaciones de abril de 2026 instaladas. UnDefend no tiene parche. La ventana de oportunidad no se está cerrando rápidamente.
Las organizaciones que mejor capearán este periodo de exposición son aquellas que cuentan con una visibilidad de la red que funciona de forma independiente de la capa de terminales. Los patrones de comportamiento de estos ataques —enumeración de privilegios, anomalías en los procesos del sistema, supresión de actualizaciones de Defender, actividad inusual entre procesos y la red— son detectables a través de la telemetría de red e identidad que la Vectra AI analiza de forma continua.
Para los equipos de seguridad que evalúan su situación actual frente a estas amenazas específicas, la pregunta que deben plantearse es sencilla: si RedSun logra explotar mi EDR y se establece un acceso a nivel del SISTEMA, ¿cuál es mi siguiente capa de detección? Si la respuesta implica otra herramienta que dependa de la misma pila de endpoint, la vulnerabilidad es real.
Aplica todos los parches que puedas. Instala las actualizaciones de abril de 2026 para protegerte contra BlueHammer. Vigila los indicadores de comportamiento de RedSun y UnDefend en la capa de red. Y asegúrate de que la herramienta que supervisa la red no comparta un límite de confianza con la herramienta que está siendo atacada.
Descubre cómo Vectra AI la actividad posterior a la explotación
Si quieres comprender cómo la Vectra AI detecta la escalada de privilegios, las anomalías en los procesos y el movimiento lateral en un entorno en tiempo real, estos son los mejores puntos de partida.