Las herramientas de Nightmare-Eclipse pasan de una prueba de concepto pública a una intrusión real

Agradecimientos: Un agradecimiento especial a Dani Lopez, Tanner Filip, Anton Ovrutsky, Lindsey O’Donnell-Welch y John Hammond por sus aportes a esta investigación y redacción. Este artículo también se escribió con asistencia de IA.

Resumen: Huntress ha observado el uso de herramientas Nightmare-Eclipse, incluidas BlueHammer, RedSun y UnDefend, durante una investigación de intrusión en un caso real. En el caso más claro, la actividad incluyó binarios sospechosos ubicados en directorios con permisos de escritura para el usuario, reconocimiento manual (hands-on-keyboard), acceso probablemente comprometido a través de SSL VPN de FortiGate, y comportamiento posterior de tunelización. Las organizaciones deben revisar los registros de VPN, investigar los artefactos y rutas que se detallan a continuación, y tratar cualquier ejecución confirmada como actividad de incidente de alta prioridad.

Antecedentes

Para entender la actividad que observó Huntress, ayuda comenzar por la historia pública detrás de esto. Chaotic Eclipse, también conocido en algunos lugares como Nightmare-Eclipse, es el alias de un investigador de seguridad que se frustró con la forma en que Microsoft manejaba los procesos de divulgación de vulnerabilidades. Como resultado de esa frustración, publicó una serie de técnicas de escalada de privilegios locales, llamadas BlueHammer, RedSun y UnDefend.

Como parte de sus actualizaciones de abril de 2026, Microsoft lanzó un parche para la vulnerabilidad BlueHammer (registrada como CVE-2026-33825). Sin embargo, al momento de publicar este blog (20 de abril de 2026), las otras dos fallas siguen sin parchear.

En términos generales, BlueHammer es el abuso de una vulnerabilidad de condición de carrera/Time Of Check, Time Of Use (TOCTOU) en Windows Defender, y la investigación de Huntress indica que BlueHammer y RedSun se pueden usar como técnicas de escalada de privilegios para llevar a un atacante de una cuenta sin privilegios a SYSTEM. En la práctica, ese tipo de elevación puede darle a un operador la capacidad de volcar credenciales, establecer persistencia y mezclarse con la actividad normal del sistema mientras avanza dentro de un entorno.

En ese contexto, Huntress observó por primera vez el uso sospechoso en entornos reales de la actividad de BlueHammer a mediados de abril de 2026, durante investigaciones de clientes. A medida que avanzaba la investigación, Huntress correlacionó actividad relacionada que involucraba a BlueHammer, RedSun y UnDefend, todas vinculadas a las herramientas públicas de Nightmare-Eclipse.

La actividad también pareció ser parte de una intrusión más amplia y no una prueba de concepto (PoC) aislada. Huntress identificó acceso sospechoso vía SSL VPN de FortiGate vinculado al entorno comprometido, incluida una IP de origen geolocalizada en Rusia, con infraestructura sospechosa adicional observada en otras regiones. Esos hallazgos se detallan más adelante.

El trío terrible

Los dos scripts PoC principales de Nightmare-Eclipse se enfocan en lograr acceso a nivel SYSTEM en entornos Windows actualizados.

Tanto BlueHammer como RedSun comparten ideales temáticos fuertes, como el uso de oplocks (o bloqueos de operación) que intentan mantener los archivos "abiertos" como forma de identificar cuándo Defender está realizando activamente una acción, ya sea escaneando archivos, remediando malware, etc. Dado que Defender puede eliminar activamente estos oplocks, esto se convierte principalmente en el método de sincronización para saber cuándo podría cumplirse una condición previa para la condición de carrera.

Además, Nightmare-Eclipse se enfoca intensamente en el sistema de Volume Shadow Copy. Cuando Defender intenta remediar un archivo malicioso determinado o entra en ciertas rutas de actualización, se crea una Volume Shadow Copy como método para garantizar la integridad del sistema.

Y, por último, hay un fuerte enfoque en las condiciones de carrera. Al observar acciones específicas, ya sea mediante oplocks (BlueHammer y RedSun) o mediante monitoreo de cambios de directorio (UnDefend), las herramientas de Nightmare-Eclipse suelen "correr una carrera" para realizar alguna acción una vez que identifican una ventana en la que el sistema es vulnerable a acciones inesperadas. Mientras que los dos primeros PoC pueden considerarse una vulnerabilidad TOCTOU (más sobre esto a continuación), UnDefend simplemente aprovecha una acción del sistema muy benigna y necesaria que lleva a bloqueos exclusivos sobre archivos.

BlueHammer

BlueHammer (CVE-2026-33825) es un exploit de escalada de privilegios local contra Windows Defender, publicado por Nightmare-Eclipse el 2 de abril de 2026. BlueHammer aprovecha principalmente dos conceptos novedosos para lograr un identificador de lectura arbitrario hacia la base de datos Security Account Manager (SAM), que almacena materiales de credenciales en el sistema Windows.

Figura 1: Página de actualización de Microsoft para CVE-2026-33825

El primero es Common Weakness Enumeration (CWE) 367, un concepto conocido como Time Of Check, Time Of Use (TOCTOU). Las vulnerabilidades TOCTOU, clasificadas en términos generales como condiciones de carrera, son una carrera por realizar una acción/modificar un valor entre el momento en que se verifica un valor y el momento en que el código realmente lo usa. Un ejemplo conceptual de TOCTOU implica que alguien haga clic en un enlace para abrir un archivo, pero para cuando Windows realmente "ejecuta" el archivo, un adversario ya lo cambió por un ejecutable malicioso, ejecutando así ese archivo. En la realidad, TOCTOU suele ser mucho más sutil, y ha provocado algunas de las vulnerabilidades más importantes de la historia, como la falla de escalada de privilegios del kernel de Linux de 2016 Dirty COW y numerosas vulnerabilidades de enlaces simbólicos en Linux.

El segundo concepto no tiene un CWE particular, sino que aprovecha la capacidad del autor del exploit de "pausar" Windows Defender mientras su Volume Shadow Copy queda expuesta. Las vulnerabilidades TOCTOU suelen ser difíciles de mitigar, pero se aceptan hasta cierto punto porque la ventana para generar una condición de carrera válida es excepcionalmente pequeña. Este no es el caso de BlueHammer; al pausar el proceso de Defender con la Volume Shadow Copy abierta, un adversario puede controlar el tiempo de esta ventana tan estrecha.

Al combinar estas dos técnicas novedosas, el autor del exploit demuestra cómo un usuario no autenticado puede leer una ubicación de archivo que normalmente es sensible.

De manera secuencial, BlueHammer se utiliza como arma en las siguientes etapas para obtener control sobre (cualquier) usuario que esté actualmente desconectado en el endpoint:

Reconocimiento de actualizaciones

• BlueHammer consulta la API de Windows Update en busca de una actualización pendiente y obtiene su propia copia de los archivos de actualización.

Forzar la creación de VSS y congelar Windows Defender

• BlueHammer escribe en el disco una cadena de prueba estándar para antivirus, una que Defender detectará sin duda. Esto hace que Defender cree una instantánea congelada del volumen como parte de su proceso de remediación; BlueHammer monitorea la creación de esa instantánea antes de continuar.
• Para confirmar que Defender está escaneando activamente, BlueHammer coloca un bloqueo sobre un archivo del sistema al que Defender accede durante el escaneo. Cuando ese bloqueo se libera, se confirma que el escaneo está en curso.
• Luego, BlueHammer registra un proveedor de sincronización en la nube falso, estructuralmente idéntico a OneDrive, en su propio directorio, y coloca un archivo dentro de él. El proveedor de sincronización dispara una devolución de llamada cada vez que un proceso enumera el directorio, e incluye la identidad del que la invoca. Cuando Defender lo enumera y activa esa devolución de llamada, BlueHammer confirma que la identidad corresponde específicamente a Defender.
• Este es el punto de sincronización. Se coloca un bloqueo sobre el archivo, y solo entonces la devolución de llamada le entrega a Defender el listado del directorio, que incluye el archivo. Defender intenta abrirlo para escanearlo. Esa apertura suspende las operaciones silenciosamente. El hilo de escaneo de Defender ahora espera indefinidamente un archivo que BlueHammer controla.

La carrera hacia SAM

• BlueHammer tiene en su poder dos cosas: una instantánea congelada del volumen que contiene una copia desbloqueada de la base de datos de contraseñas del sistema, y un Defender suspendido. Lo que falta es obtener una lectura de esa base de datos, algo que normalmente requeriría acceso a nivel de sistema.
• BlueHammer construye una ruta redirigible hacia sus archivos de actualización preparados e instruye a Defender, a través de su propia interfaz interna de actualización, a importar una actualización de firmas desde esa ubicación. Defender arma un nuevo directorio de actualización de definiciones y comienza a leer los archivos preparados.
• Cuando Defender abre el archivo de definición principal, se activa un bloqueo. En esa ventana, la ruta se intercambia: ahora apunta hacia la instantánea congelada del volumen, directamente a la base de datos de contraseñas del sistema. Una segunda redirección mapea el nombre de archivo esperado hacia ese destino.
• El bloqueo se libera. Defender continúa por la ruta ahora redirigida y lee la base de datos de contraseñas, creyendo que se trata de un archivo de definiciones. Defender lo escribe en su propio directorio de salida. BlueHammer abre el destino y obtiene un identificador hacia la base de datos de contraseñas.

Esto, en esencia, es BlueHammer. Lo que sigue son detalles de implementación. Podríamos detenernos aquí, copiar la base de datos SAM comprometida mediante cualquier cantidad de técnicas, y el exploit seguiría siendo válido.

BlueHammer lleva esto un paso más allá: analiza la colmena SAM y descifra el hash NT (representación de la contraseña) de cada usuario. Con hashes válidos en mano, BlueHammer cambia temporalmente la contraseña de cada usuario a $PWNed666!!!WDFAIL, la cual luego usa para generar sesiones de administrador.

Estas sesiones de administrador finalmente se aprovechan para escalar a nivel SYSTEM, copiando el token de SYSTEM y creando procesos con este usuario.

RedSun

Con el exploit de BlueHammer fresco en la mente, RedSun debería resultarle muy similar al lector. En lugar de leer la base de datos SAM desde el VSS, RedSun actúa de una manera particular. Busca lograr acceso a nivel SYSTEM sobrescribiendo archivos críticos del sistema, pero usa técnicas similares para lograrlo. La técnica elegida por RedSun (que de ninguna manera es prescriptiva) usa el objeto COM Storage Tiers Management Engine (motor de administración de almacenamiento por niveles), y lo secuestra para invocar un TieringEngineService.exe colocado maliciosamente, que simplemente es una copia de RedSun con una verificación específica para entrar en una ruta de código si ya se está ejecutando como SYSTEM, a fin de evitar la recursión.

En última instancia, RedSun puede considerarse como la identificación de una condición de carrera en la detección y el manejo de remediación de Defender Cloud File.

Configuración y activador

• La configuración de RedSun se comporta de forma similar a la de BlueHammer. En este caso, no necesitamos la actualización de Defender, así que se omitió. 
• En su lugar, se crea una canalización con nombre “REDSUN” como método de comunicación entre procesos. Esto funciona principalmente como un mecanismo de sincronización para que el proceso se autogenere y rastree estados entre su ejecución sin privilegios y con privilegios. 
• RedSun toma una instantánea del estado actual de Volume Shadow Copy y luego monitorea nuevas adiciones a esa instantánea. 
• Se crea un directorio de preparación (%TEMP%\RS-{GUID}\), y la cadena de prueba EICAR se escribe allí como el archivo TieringEngineService.exe.
• Al abrir el archivo con acceso FILE_EXECUTE, Defender escanea este archivo. 

Sincronización de oplock

• De la misma manera exacta que BlueHammer, se usan oplocks para identificar cuándo Windows Defender ha iniciado una acción sobre el archivo. Se adquiere un oplock contra la versión de Volume Shadow Copy de TieringEngineService.exe. 
• Una vez que comienza el escaneo, se elimina el archivo del directorio original, y su directorio se registra como una raíz de sincronización de Cloud Files con un marcador de posición en la nube en TieringEngineService.exe. Esto hace que Defender trate este archivo de forma un poco diferente a un archivo convencional. 

Intercambio de uniones de directorio (TOCTOU) 

• El directorio de trabajo (%TEMP%\RS-{GUID}\) se renombra con el sufijo .TMP, y la ruta original se vuelve a crear como un directorio vacío. 
• El archivo marcador de posición en la nube TieringEngineService.exe se vuelve a abrir, y se adquiere un oplock sobre este archivo para sincronización. Luego, este archivo se renombra con el sufijo .TEMP2 y se marca para eliminación. 
• En esta ventana sumamente estrecha, el autor del exploit ahora tiene un directorio vacío al que Defender intentará restaurar el marcador de posición del archivo en la nube. 
• En esta ventana TOCTOU, la ruta %TEMP%\RS-{GUID} se convierte en un punto de montaje en C:\Windows\System32 en su lugar. 

Escritura arbitraria y escalada de privilegios

• Defender intenta restaurar el “archivo malicioso” en %TEMP\RS-{GUID}\TieringEngineService.exe. Casualmente, esto ahora es C:\Windows\System32\TieringEngineService.exe. 
• Cuando Defender restaura este archivo, RedSun se copia a sí mismo a la ubicación restaurada, ahora en C:\Windows\System32. Normalmente, los usuarios sin privilegios no pueden escribir aquí, pero debido a un comportamiento en Windows Defender, el proceso de restauración del archivo hace que se aplique temporalmente la DACL predeterminada al nuevo archivo; y así el propietario original tiene control total del archivo durante esta ventana.
• RedSun luego llama al objeto COM del motor de administración de niveles de almacenamiento, que se ejecuta localmente como SYSTEM. Esto, a su vez, ejecuta C:\Windows\System32\TieringEngineService.exe, que es una copia de RedSun.
• El binario se relanza, pasa la verificación de SYSTEM y genera un shell con el token de SYSTEM.

UnDefend

UnDefend es la versión de Nightmare-Eclipse de un 'asesino' moderno de Windows Defender. No viene con modos seleccionables por el usuario, contrario a lo que dice el README. Todo se ejecuta simultáneamente desde el momento en que se inicia, atacando la canalización de firmas de Defender en múltiples frentes a la vez.

El mecanismo es sencillo: UnDefend vigila el directorio de Actualizaciones de Definiciones de Windows Defender y el directorio de la Herramienta de Eliminación de Software Malintencionado de Microsoft mediante notificaciones de cambios de directorio. Cuando aparece un archivo de definición nuevo o modificado, la herramienta se apresura a abrirlo y bloquearlo antes de que Defender pueda usarlo. Los archivos de definición de respaldo (mpavbase.lkg y mpavbase.vdm) ni siquiera tienen ese período de gracia; se bloquean de inmediato al iniciar.

La parte más interesante apunta al ciclo de reinicio de Defender. UnDefend registra una notificación de estado de servicio para WinDefend y espera a que se detenga, no específicamente durante una actualización importante de la plataforma como sugiere el README, sino durante cualquier evento de detención del servicio. Cuando esto ocurre, UnDefend bloquea de inmediato mpavbase.vdm en la ubicación activa de firmas, impidiendo que Defender vuelva a cargar su base de firmas al reiniciar.

Una advertencia importante: nada de esto es permanente. Los bloqueos se mantienen mediante identificadores abiertos rastreados en memoria durante la ejecución. Cuando el proceso de UnDefend termina, el sistema operativo libera todos los identificadores y Defender se recupera. Esto es una interrupción mientras la herramienta está en ejecución, no una desactivación duradera.

Detalles de la intrusión

Ejecución desde rutas con privilegios bajos

Figura 2: Ejecuciones de payload detectadas

Uno de los patrones más claros que observó Huntress fue el uso de directorios con permisos de escritura para usuarios comunes, tanto para preparar como para ejecutar los archivos. En la ocurrencia más reciente, los binarios se prepararon desde la carpeta Pictures de un usuario con privilegios bajos y desde subcarpetas cortas de dos letras dentro de Downloads.

Los nombres de los archivos también llamaron la atención porque coincidían estrechamente con los repositorios públicos de PoC. Huntress observó binarios llamados FunnyApp.exe, RedSun.exe, undef.exe, y una variante renombrada, z.exe.

El 10 de abril, Huntress observó C:\Users\[REDACTED]\Pictures\FunnyApp.exe, y Windows Defender lo bloqueó y puso en cuarentena como Exploit:Win32/DfndrPEBluHmr.BZ. Huntress confirmó más tarde que el binario en cuarentena era una compilación del repositorio público de GitHub de BlueHammer.

El 16 de abril, Huntress observó C:\Users\[REDACTED]\Downloads\RedSun.exe, lo que generó una alerta EICAR de Defender que los analistas identificaron como parte del comportamiento normal de la técnica. Huntress también observó actividad de UnDefend ese mismo día, incluyendo:

• C:\Users\[REDACTED]\Downloads\ks\undef.exe
• C:\Users\[REDACTED]\Downloads\ks\undef.exe -h
• C:\Users\[REDACTED]\Downloads\kk\undef.exe -agressive
• C:\Users\[REDACTED]\Downloads\ks\z.exe

Cabe destacar que, durante la ejecución de UnDefend, el adversario demostró que no estaba particularmente familiarizado con la herramienta que estaba usando.

Como se mencionó antes, UnDefend no tiene modos seleccionables por el usuario. En cambio, el autor describe los dos mecanismos de acción como “modos” del binario. Tampoco tiene texto de ayuda ni ninguna interfaz de línea de comandos propiamente dicha. Así que, aunque el indicador -h tradicionalmente muestra texto de ayuda, en este caso ese parámetro de línea de comandos no hace nada.

Además, el intruso escribió mal su intento de ejecutar el modo ‘aggressive’, e invocó UnDefend con el parámetro -agressive. Es evidente que el adversario no leyó ni entendió el mecanismo de acción de UnDefend, y probablemente actuaba por intuición a partir del README incluido con la herramienta.

También vale la pena señalar que, si bien observamos la ejecución de varias de estas herramientas maliciosas, ninguna parece haber tenido éxito. RedSun no logró sobrescribir TieringEngineService.exe en la carpeta System32. BlueHammer no logró extraer las credenciales SAM. Y aunque UnDefend pudo haberse ejecutado con cierto éxito, el proceso fue terminado sin dificultad por el centro de operaciones de seguridad de Huntress durante la respuesta y remediación, eliminando de inmediato el daño que la herramienta UnDefend pudiera haber causado.

Actividad práctica de posexplotación por parte del operador

Lo que llevó esto más allá de una simple ejecución de PoC fue el comportamiento del operador a su alrededor. Huntress documentó comandos de enumeración típicos, como:

• whoami /priv
• cmdkey /list
• net group

Estos comandos son consistentes con un operador que verifica privilegios, revisa credenciales almacenadas e identifica oportunidades adicionales de movimiento o acceso posterior dentro del entorno de la víctima. Huntress señaló explícitamente que esta secuencia indicaba actividad práctica de un actor de amenazas.

Otro detalle a destacar sobre estos comandos de enumeración es que uno de ellos (whoami /priv) se generó desde un proceso de M365Copilot (M365Copilot.exe). Investigaciones posteriores no revelaron hallazgos sobre cómo ocurrió esto ni qué sucedía detrás de escena. Lo que sí sabemos es que esto ocurrió después de que se había iniciado el compromiso inicial y después de que el adversario había intentado ejecutar BlueHammer por primera vez.

Figura 3: whoami /priv se generó desde un proceso de M365Copilot (M365Copilot.exe)

Probable acceso inicial a través de SSL VPN de FortiGate

A medida que avanzaba la investigación, Huntress obtuvo visibilidad adicional a partir de los registros de VPN proporcionados por el cliente. Esos registros mostraron que el 15 de abril de 2026, a las 13:44:19 UTC, un actor de amenazas inició una conexión SSL VPN a un firewall FortiGate desde 78.29.48[.]29, geolocalizado en la Federación de Rusia, usando credenciales de la cuenta del usuario víctima.

También se observaron sesiones no autorizadas posteriores vinculadas a la misma cuenta desde:

• 212.232.23[.]69 (Singapur)
• 179.43.140[.]214 (Suiza)

Esta visibilidad de FortiGate ayudó a responder una pregunta clave planteada internamente luego de que se publicaran las primeras publicaciones en redes sociales: la herramienta Nightmare-Eclipse no aparecía en el vacío, sino junto con evidencia de un probable abuso de acceso remoto y una actividad de intrusión más amplia.

BeigeBurrow: un agente de túnel inverso Yamux basado en Go

Huntress también identificó un binario llamado agent.exe ejecutándose en el contexto del usuario víctima comprometido, con la siguiente línea de comandos:

agent.exe -server staybud.dpdns[.]org:443 -hide

Huntress evalúa con alta confianza que este binario actuaba como un agente de túnel o proxy que enviaba señales (beaconing) hacia infraestructura controlada por el atacante a través del puerto 443. Un análisis interno posterior también vinculó staybud.dpdns[.]org con observaciones previas y señaló que una muestra similar de agent.exe de un incidente anterior parecía ser una herramienta de tunelización basada en Go.

En conjunto, la actividad observada sugiere un flujo de intrusión práctico: probable acceso inicial mediante credenciales VPN, ejecución local de herramientas públicas de escalada de privilegios, reconocimiento y mantenimiento de acceso posterior mediante tunelización o herramientas remotas. No incluye ejecución de shell, ni capacidades de sistema de archivos, ni robo de credenciales. Existe con un solo propósito: darle a un operador un relevo TCP encubierto y multicanal dentro de una red comprometida.

Análisis técnico de BeigeBurrow

BeigeBurrow es un binario de Windows compilado en Go que establece un túnel inverso persistente y multiplexado hacia un servidor de comando y control (C2) usando la biblioteca yamux de HashiCorp.

Vale la pena señalar que Huntress ha observado BeigeBurrow en al menos otro evento de intrusión no relacionado con el compromiso de VPN descrito anteriormente. Dado el número limitado de avistamientos y la falta de prácticas operativas distintivas entre los incidentes, no podemos evaluar con confianza si BeigeBurrow se vende activamente en mercados clandestinos, se comparte entre un conjunto informal de operadores, o lo usa exclusivamente un grupo específico de actores de amenazas. Compartimos los detalles de esta herramienta para ayudar a los defensores en la detección y fomentar más reportes de la comunidad que puedan ayudar a aclarar la atribución.

BeigeBurrow acepta tres parámetros de línea de comandos, visibles en su salida de uso a continuación. Esto nos dice mucho incluso antes de abrir un desensamblador: la muestra es un agente configurable que se conecta a un servidor especificado por el operador (-server string), puede ocultar su ventana de consola para mayor sigilo (-hide) y admite un modo "chain" para encadenarse a través de varios endpoints (-chain).

Figura 4: Parámetros de línea de comandos de BeigeBurrow

Después de procesar los parámetros, BeigeBurrow opcionalmente oculta la ventana de consola y luego entra en un bucle infinito que llama a runAgent(). Si la función del agente devuelve un error (C2 inalcanzable, sesión caída, etc.), registra el fallo y espera antes de reintentar. El agente reintenta en un intervalo fijo de 5 minutos. El proceso nunca termina por sí solo: mientras el binario esté en ejecución, seguirá reintentando la misma dirección del servidor indefinidamente.

Figura 5: Punto de entrada de BeigeBurrow que muestra el bucle infinito de reconexión

La función main.runAgent inicia la conexión con el servidor C2, crea una sesión multiplexada yamux sobre la conexión TCP directa y entra en un bucle de aceptación de flujos.

A partir de la salida descompilada, podemos extraer la configuración yamux que usa el agente. Cada valor de la configuración coincide exactamente con el DefaultConfig() de yamux. El autor no personalizó los parámetros de sesión.

Figura 6: Configuración yamux

La marca -chain no tiene efecto funcional en esta compilación. Cuando se establece, escribe de manera redundante true en el campo EnableKeepAlive de la configuración de yamux, que ya es true de forma predeterminada. No se puede determinar, solo a partir de esta muestra, si -chain tiene relevancia funcional en las herramientas del lado del servidor o en otra versión de este agente.

La función handleStream es donde BeigeBurrow genera valor para el operador. Por cada flujo yamux que abre el C2, el agente lee una dirección de destino terminada en salto de línea (por ejemplo, "10.0.0.5:445\n"), elimina el salto de línea final, establece una conexión TCP hacia el endpoint:puerto especificado y transmite el tráfico en ambas direcciones entre el flujo del C2 y la conexión de destino. Esto significa que el operador puede alcanzar cualquier endpoint accesible desde el equipo comprometido con solo abrir un nuevo flujo yamux y enviar una dirección de destino. Todo este tráfico pasa por una sola conexión TCP saliente.

Recomendaciones de mitigación

Las organizaciones deben tratar cualquier señal de ejecución de BlueHammer, RedSun o UnDefend como una actividad urgente de respuesta a incidentes, no solo como curiosidad de investigación.

Según lo que observó Huntress en esta investigación, recomendamos encarecidamente lo siguiente:

• Revisa la telemetría de endpoints en busca de ejecuciones desde rutas inusuales con permisos de escritura de usuario, como Pictures y subcarpetas cortas dentro de Downloads.
• Busca binarios llamados FunnyApp.exe, RedSun.exe, undef.exe y z.exe.
• Revisa la telemetría de seguridad en busca de Exploit:Win32/DfndrPEBluHmr.BZ y alertas sospechosas de EICAR vinculadas a binarios desconocidos.
• Busca comandos de reconocimiento relacionados, en especial whoami /priv, cmdkey /list y net group, que ocurran cerca de la ejecución de binarios sospechosos.
• Revisa los registros de VPN en busca de autenticación anómala del mismo usuario desde varias geografías en un período corto.
• Investiga la ejecución sospechosa de agent.exe -server staybud.dpdns[.]org:443 -hide o un comportamiento de tunelización similar.

¿Qué está haciendo Huntress?

Huntress aisló a la organización afectada y continuó investigando los binarios observados, los registros de acceso y las herramientas posteriores para comprender mejor el alcance y el comportamiento del atacante. Huntress también está monitoreando activamente actividad relacionada y comparte los hallazgos de manera interna y externa a medida que avanza la investigación.

Detecciones

BeigeBurrow - Regla de Yara

Indicadores de compromiso (IoC)