El diablo, ocho millones de correos y mucha leche

Contexto

Un socio incorporó a un cliente pequeño (25 endpoints) a Huntress el 2026-05-15 18:48 UTC. En las primeras horas de la mañana siguiente, el SOC ya estaba viendo una detección crítica en uno de los endpoints.

La mayoría de los incidentes que documentamos involucran a clientes que ya tenían el Huntress Agent instalado en sus endpoints durante meses. Esto nos da una ventaja. Tenemos tiempo para establecer una línea base, recopilar registros y, lo más importante, aprender el contexto del entorno específico del cliente: qué cuentas inician sesión desde dónde, qué hosts se comunican entre sí y cómo se ve un día normal en la red. Implementa EDR en una red saludable, y el agente (y los analistas) pueden ver llegar al atacante y comprender mejor  las cosas que no encajan.

Como fuimos instalados en medio del incidente, esta incorporación no nos dio nada de eso. Las credenciales ya habían sido robadas, las herramientas ya estaban preparadas, y la única pregunta que quedaba era qué tan rápido podíamos desentrañar una intrusión en una red que conocíamos desde hacía solo nueve horas.

Un inicio de sesión para el que ya teníamos un nombre

La primera alerta que recibió Huntress no fue sutil. A las 2026-05-16 03:38:53 UTC, el Huntress Agent generó una detección crítica y expedita. La detección indicaba una autenticación (identificada a partir de una entrada del registro de auditoría de seguridad de Windows —Microsoft-Windows-Security-Auditing Event ID 4624, que indica inicios de sesión exitosos). El campo interesante en un evento de autenticación suele ser la IP de origen. Aquí, fue tanto la IP de origen como el nombre del host. El cliente RDP se había anunciado como DESKTOP-[REDACTED], un nombre de estación de trabajo que Huntress había visto antes en intrusiones de socios no relacionadas. La IP de origen, 212.93.152[.]37, geolocaliza en Rumania. Recuerda eso, vuelve a aparecer.

Figura 1: La primera señal, 03:38:53 UTC. Una detección crítica y expedita de autenticación que involucra la IP de origen 212.93.152[.]37. 

El host en sí es un servidor de sesiones de escritorio remoto (RD) (también conocido como servidor de terminal), un Windows Server que aloja simultáneamente las sesiones de escritorio remoto de varios usuarios.  También alojaba un portal público Microsoft IIS RDWeb Access (la página de inicio de sesión web para el acceso por escritorio remoto), y ejecutaba el rol de RD Gateway (esencialmente un intermediario entre internet y los servidores de terminal internos). Una sola máquina, expuesta directamente a internet, autenticando usuarios del dominio con un nombre de usuario y una contraseña. La inteligencia de amenazas externa vio lo mismo desde afuera: un portal RDWeb público respondiendo en el puerto 443. Ese portal era la puerta principal, y el actor tenía la contraseña.

Cuatro llaves para la misma cerradura

Los registros de IIS del host mostraron cómo el operador entró en primer lugar. RDWeb Access se ejecuta sobre IIS; sus registros capturan cada visita al portal, intento de inicio de sesión y solicitud de lanzamiento de aplicación, lo que los hace invaluables al investigar este incidente. Este servidor de terminal publicó su portal RDWeb Access directamente en internet y, de manera típica en internet, estaba siendo abusado por todo tipo de tráfico. Durante los cuatro días que abarcaron los registros, el portal respondió 657,521 solicitudes de 8,673 direcciones IP distintas, y más de 206,000 de esas fueron solicitudes HTTP POST a la página de inicio de sesión desde 8,197 fuentes separadas. Así es como se ve un portal RDWeb expuesto desde afuera: un formulario de inicio de sesión bajo ataque automatizado constante desde todas las direcciones a la vez. Una sola fuente, 87.251.64[.]134, lanzó aproximadamente 48,000 solicitudes; 10 hosts en 88.210.63[.]0/24 sumaron otras 84,000 entre ellos.

De 206,444 POSTs de inicio de sesión, exactamente cuatro devolvieron 302 en lugar de 200, y en este portal, esa diferencia lo es todo. Un inicio de sesión fallido en el formulario de RDWeb vuelve a renderizar la página con un 200; un éxito redirige con un 302. Cuatro redirecciones, cuatro llaves que giraron, cada una en la misma cerradura: la única cuenta de dominio publicada en la máquina. Coloca el momento en que el socio incorporó al cliente en la misma línea de tiempo, y los cuatro éxitos cuentan una historia mejor que "el atacante inició sesión".

80.94.95[.]37

212.93.152[.]37

216.152.151[.]168

212.93.152[.]37

Tres direcciones, cuatro inicios de sesión, y no son un solo par de manos. Dos de ellas claramente lo son. 80.94.95[.]37 y 212.93.152[.]37 se comportaron de la misma manera deliberada: cada una cargó la hoja de estilos y las imágenes del portal como un navegador real, inició sesión con el nombre de usuario totalmente calificado del dominio ([DOMAIN]\[user]), descargó el archivo .rdp publicado, y continuó a través de RD Gateway para abrir una sesión en la máquina. Ambas son rumanas. La primera es una dirección de hosting en Timisoara conocida en múltiples fuentes de inteligencia de amenazas externas por ser abusada; la segunda, la línea en la que se realizó el trabajo práctico, es una línea residencial fija limpia sin historial de abuso identificado. Leídas juntas, son la forma ordinaria de una sola operación: acceso temprano desde una IP de hosting desechable, luego el trabajo real desde una línea residencial tranquila que ninguna lista de bloqueo ha marcado.

216.152.151[.]168 es la pieza discordante, y el momento es lo que la delata. Es un host de centro de datos de EE. UU. marcado, y no era un navegador. Se identificó como Go-http-client/2.0 (y, en algunas solicitudes, una cadena simple Mozilla/5.0 sin motor detrás) y usó minúsculas en las rutas del portal como lo hacen las herramientas con scripts, en lugar de seguir los enlaces en mayúsculas y minúsculas mixtas que realmente se le sirven a un navegador. Envió el nombre de usuario simple sin dominio. Machacó el formulario de inicio de sesión en pares GET/POST desde el 14 de mayo en adelante; 127 POSTs fallidos, hasta que uno a las 21:51:16 del 15 de mayo finalmente devolvió 302. Luego, curiosamente, después de encontrar la contraseña, no hizo absolutamente nada y volvió directamente a adivinar:

21:51:16  POST  login.aspx  302  <- un éxito (nombre de usuario simple, Go-http-client/2.0)

21:53:36  POST  login.aspx  200  <- directo de vuelta a adivinar
22:18:15  POST  login.aspx  200
22:26:40  POST  login.aspx  200

Esto continuó hasta el 16 de mayo; el bot nunca descargó el .rdp, nunca llegó al gateway, y nunca apareció en ningún lugar de los registros de eventos de Windows del host.

Ahora compara ese único éxito con el resto de la línea de tiempo. El operador ya había estado iniciando sesión y descargando el escritorio publicado desde las 02:12 de esa mañana, y lo había estado haciendo desde otra dirección dos días antes. Vinculamos las dos direcciones rumanas a un solo operador por técnica, no por geografía: cada una carga el portal como un navegador real, inicia sesión con el mismo nombre de usuario totalmente calificado del dominio, descarga el mismo archivo .rdp publicado, y continúa a través del gateway hacia una sesión en la máquina. Para cuando el bot logró su 302 a las 21:51, las personas que dirigían esta intrusión ya habían mantenido una sesión activa en la máquina, intermitentemente, durante los dos días anteriores. Una operación que ya posee el host no gasta también dos días forzando la puerta principal para redescubrir una contraseña que ya está usando activamente. La infraestructura, el cliente, las rutas en minúsculas, el nombre de usuario simple y, sobre todo, el momento apuntan en una sola dirección, así que evaluamos a 216.152.151[.]168 como un atacante de fuerza bruta de credenciales separado y oportunista, del tipo que confirma un inicio de sesión y lo vende o lo lista, que dio con la misma contraseña débil y nunca volvió a usarla. Desde aquí, la dirección que seguimos es 212.93.152[.]37; el bot es la historia de otra persona, y una medida de lo poco que valía conservar esta credencial.

Eso deja la última fila en la línea de tiempo de la Tabla 1, la reconexión de las 03:36. En la tabla, ya la llamamos reconexión, y esa sola palabra está haciendo el trabajo real: una reconexión significa que la sesión a la que se reunió se abrió antes, antes de que estuviéramos siquiera en la máquina. No queríamos que esto dependiera de una sola línea de registro, así que lo confirmamos contra cada canal que registró el evento.

El registro de Security no ayudó. Este servidor de terminal tenía casi ninguna auditoría habilitada, 2 eventos de inicio de sesión en todo el registro, y cero ID de eventos que indicaran creación de procesos (4688). En un día normal, eso es una molestia. Durante una intrusión, significa que el primer registro al que recurres no tiene nada que decir. Sin embargo, los registros operativos de Terminal Services sí lo tenían, así que los analizamos con Chainsaw. Alineada, la secuencia de las 03:36 se lee con claridad:

IIS / ASP.NET

1315

RD Gateway

312, 200, 300, 302

TS-RemoteConnectionManager

1149

TS-LocalSessionManager

25

Cada canal captura una etapa diferente de la misma conexión: el portal registra una nueva reautenticación, el gateway abre el túnel, la autenticación RD tiene éxito, y el Local Session Manager resuelve lo que realmente fue. Ese último evento lo confirma: el evento 25 es una reconexión, no un nuevo inicio de sesión. El operador no inició una sesión a las 03:36; se reincorporó a la sesión 16, un escritorio que había quedado desconectado, esperándolo. Las personas no dejan sesiones RDP desconectadas abandonadas en un servidor al que recién iniciaron sesión ese mismo minuto.

El taller del diablo

Con el registro de Security como un callejón sin salida, el resto de la imagen vino de los registros operativos de Terminal Services y de los archivos dejados en el disco. Ahí es donde el incidente deja de ser una historia de acceso y se convierte en una historia de phishing. El directorio de preparación estaba en el escritorio del usuario comprometido, en una carpeta que el actor había nombrado dam pe uk puterniiicccc, jerga rumana que significa aproximadamente "le dimos fuerte al Reino Unido".

Figura 2: Contenido del directorio de preparación en el servidor de terminal. 

Como se ve en la Figura 2 anterior, el mailer (gm.exe) y las seis listas de destinatarios (milk (1) a (6)) comparten una única fecha de última modificación de 2026-05-15 02:15 UTC, horas antes de que se incorporara al cliente; solo el archivo del proyecto, dracii.mmp, se modificó después, a las 2026-05-16 03:28 UTC, la mañana en que se detectó la reconexión. Esto indica que el actor de amenazas había estado dentro el tiempo suficiente durante una sesión anterior para construir el kit y dejarlo en el escritorio; el operador regresó esa mañana presumiblemente para ejecutar la campaña.

Al abrirla, la carpeta contiene tres cosas:

• gm.exe: Gammadyne Mailer, una aplicación comercial de correo masivo para Windows de larga trayectoria. Esto explica por qué nunca se disparó ninguna alerta de antivirus. Gammadyne no es malware. Es una herramienta de correo legítima, firmada y vendida comercialmente. Microsoft Defender en este host había registrado bastantes detecciones a lo largo de su historia, incluyendo un generador de claves marcado como Trojan:Win32/Occamy.C, un escáner de red detectado como HackTool:Win32/Netscanner en septiembre de 2025, una muestra de Cryptinject en abril de 2026, pero todas ellas eran anteriores a este incidente por semanas o meses, y ninguna era el mailer. La máquina había sido un desastre durante mucho tiempo; el mailer pasó directamente ante Defender porque no había nada que un motor de firmas pudiera detectar.
• dracii.mmp: el archivo de proyecto de Gammadyne. Dracii es rumano para "los diablos". El archivo de proyecto contiene toda la configuración de la campaña, y analizarlo devolvió el remitente, los señuelos, el enlace de la carga útil y el método de entrega de una sola vez.
• Seis archivos de texto, milk (1).txt hasta milk (6).txt.

Figura 3: La carpeta de trabajo del operador reconstruida a partir de las rutas de las listas de destinatarios almacenadas en dracii.mmp. 

El archivo de proyecto nos dio más que la campaña. Debido a que dracii.mmp había sido transportado desde la propia máquina del operador, sus mapeos de archivos vinieron con él, y apuntaban directamente de vuelta a esa máquina. Las rutas de las listas de destinatarios hacían referencia a una carpeta de trabajo, C:\Users\Administrator\Desktop\ta\, y la Figura 3 muestra las siete listas de las que el proyecto se nutría. Los nombres de las carpetas hablan por sí solos: una está dedicada a HMRC, la oficina tributaria del Reino Unido (el error de ortografía es del actor), y la otra combina objetivos del Reino Unido con la criptomoneda Solana. Los nombres de archivo debajo son gestión de listas rutinaria. Una lista llamada fara gmail ("sin gmail" en rumano) tenía las direcciones de Gmail filtradas, y los archivos divididos son una lista más grande cortada en tres partes numeradas. El mismo archivo mostraba cómo estaba destinado a moverse el correo, y que este no era el primer servidor de terminal del operador. Estaba configurado para entrega directa con 666 hilos de envío (el tema diabólico llega hasta el conteo de hilos), sin firma DKIM ni DomainKeys, lotes de 50, y sin limitación, una configuración construida para vaciar las listas tan rápido como el host pudiera abrir sockets. Sus rutas de registro, alarma y correo entrante aún apuntaban a recursos compartidos UNC en un dominio RDS comprometido diferente, \\[REDACTED].local\RDS\RDSRedirections\...\Crack\gm.log, la máquina de una víctima anterior, de la que el proyecto simplemente había sido transportado. La propia fecha de creación del proyecto dice lo mismo: Gammadyne la marcó el 2025-07-18, casi diez meses antes de que este cliente fuera incorporado, así que la copia reguardada en este escritorio era una que el operador había estado moviendo de host en host desde el verano anterior. Este kit viaja.

En conjunto, eso es suficiente para ampliar la evaluación más allá de la campaña que realmente capturamos. El kit preparado en este escritorio suplantaba a Boots, la cadena de farmacias del Reino Unido, con una falsa encuesta de satisfacción del cliente como señuelo (la campaña en sí tiene su propia sección más abajo), pero nada en la carpeta de trabajo del operador indica un especialista en Boots. Las listas no se curan en torno a HMRC a menos que haya un señuelo con tema tributario para enviarles, y una carpeta que combina objetivos del Reino Unido con la criptomoneda Solana existe por la misma razón. A partir de lo que reconstruimos, esto es un operador trabajando en una rotación de temas dirigidos al Reino Unido, retail, impuestos y criptomoneda, y el conjunto de Boots fue simplemente el trabajo cargado la mañana en que estábamos observando. La copia filtrada fara gmail y los archivos divididos numerados son el sistema de archivo de un spammer en activo, no una estafa puntual, y un archivo de proyecto que ya había vivido en al menos otro servidor de terminal de una víctima indica que la rotación había estado funcionando desde al menos el año anterior. El nombre rumano del proyecto, el nombre rumano de la carpeta, los nombres rumanos de las listas, y una IP de origen rumana apuntan todos en la misma dirección.

Mucha, mucha leche

Los archivos "milk" son de donde el post toma su nombre, y el chiste es del atacante, no nuestro. El spammer está "ordeñando" las listas de leads, listas de distribución y conjuntos de destinatarios en bruto en busca de clics. Encontramos seis de estos archivos en total, y no son pequeños:

milk (1).txt

milk (2).txt

milk (3).txt

milk (4).txt

milk (5).txt

milk (6).txt

Muestrear estas mostró una amplia distribución de consumidores internacionales, Gmail, Hotmail, Yahoo, muchos dominios regionales, exactamente el tipo de lista masiva que se compra y revende en lugar de recopilarse. Ocho millones y pico de bandejas de entrada de otras personas, preparadas en el servidor de terminal de un cliente, listas para usarse.

Boots, un regalo gratis, y una encuesta que no deberías responder

El archivo de proyecto dracii.mmp definió la campaña. El correo se envió como Boots <hello[@]boots[.]com>, suplantando a la cadena de farmacias y retail del Reino Unido. El cuerpo ofrecía un "Free Gift from Boots", un "exclusive Boots beauty sample pack", un vale de descuento y acceso anticipado a promociones, a cambio de completar una breve encuesta de satisfacción del cliente, con tokens de personalización que insertaban la dirección de cada destinatario en el saludo y un número de referencia aleatorio en el asunto. El campo Subject en sí contenía una sola línea, repleta de tokens:

[[-Now-]] Share Your Feedback & Receive a Free Gift from Boots (@bootsUK)Your opinion matters—claim your thank-you gift! | Customer satisfaction survey  E-mail:[[-Email-]] NO:[[random_digits(7)]]-[[random_digits(5)]]

Los tokens de doble corchete son campos de combinación de Gammadyne, rellenados por mensaje en el momento del envío: [[-Now-]] se convierte en la fecha actual, [[-Email-]] inserta la propia dirección del destinatario en su línea de asunto, y los dos tokens [[random_digits]] fabrican un número de referencia falso, único para cada uno de los 8.9 millones de destinatarios. El mismo truco se usó en el saludo, que abría "Dear Valued Customer, [[-Email-]]". El efecto es que ningún par de destinatarios recibe asuntos idénticos, lo que se lee como personalización para la víctima y evade cualquier filtro antiphishing básico que intente agrupar mensajes idénticos.
Siete líneas de asunto más nunca llegaron tan lejos. Fueron pegadas en el campo Headers del proyecto, que contiene encabezados técnicos de correo, así que el mailer no tenía dónde usarlas. Son borradores sobrantes: un bloque numerado, cada entrada con un asunto y una vista previa coincidente (el fragmento que una bandeja de entrada muestra junto a la línea de asunto). La línea repleta de tokens de arriba es la que se envió. Estas siete se quedaron en la configuración:

1.

Asunto: Your opinion = a gift 🎁

Vista previa: Complete our September 2025 survey and receive a special thank-you gift.

2.

Asunto: Quick surveyspecial thank-you

Vista previa: Your insights help us improve—take a few minutes to share your feedback.

3.

Asunto: We'd love your feedback

Vista previa: We value your opinion. A short surveya thoughtful reward.

4.

Asunto: A few minutes for a reward

Vista previa: Your voice matters. Tell us how we're doing and enjoy a gift on us.

5.

Asunto: Tell us what you think

Vista previa: Help shape the future of [Your Company]. Survey inside + thank-you gift.

6.

Asunto: Your voice matters

Vista previa: It only takes a few minutes to share your thoughts and claim your gift.

7.

Asunto: Survey inside + thank-you gift

Vista previa: Your feedback guides us—thank you for helping us serve you better.

Dos de esas líneas se enviaron distorsionadas; eso es obra del archivo, no de la escritura del actor. Gammadyne almacenó el bloque como tres fragmentos codificados en Base64, y ambos cortes caen exactamente donde el codificador dividió el texto: uno a mitad del asunto dos, otro a mitad de la vista previa tres, un carácter engullido en cada costura. Los señuelos a su alrededor conservan los guiones largos intactos en las mismas posiciones ("improve—take", "guides us—thank"), así que el carácter faltante en cada costura casi con certeza era un guion. El bloque también se insertó exactamente como se escribió, nunca se releyó: la vista previa cinco aún tiene un marcador de posición sin completar "[Your Company]", y la vista previa uno ofrece una encuesta fechada en September 2025, meses obsoleta para cuando se preparó la campaña. Un solo pegado, sin revisión.

Hubo una pieza más de teatro. El cuerpo HTML del correo estaba envuelto en un bloque PGP cosmético. PGP (Pretty Good Privacy) es un estándar de larga data para firmar y cifrar correo: una firma PGP real se genera con la clave privada del remitente, y el cliente de correo del destinatario la verifica para probar quién envió el mensaje y que nada fue alterado en tránsito. Este correo tenía el disfraz, pero no la criptografía: un encabezado -----BEGIN PGP SIGNED MESSAGE----- y Hash: SHA512 sobre el contenido, y una estrofa completa -----BEGIN PGP SIGNATURE----- debajo, base64 y todo, pegada en el cuerpo como texto con estilo. Nada de eso hace algo en un correo HTML; ningún cliente lo verificaría jamás. Es decoración, está ahí para hacer que un mensaje de "regalo gratis" para el consumidor parezca firmado y oficial para cualquiera que se desplace hasta allí. La configuración entrega el remate: el mailer no estaba configurado para firmar nada de verdad, sin DKIM, sin DomainKeys, así que la única firma en cualquier parte de esta campaña fue la falsa en el cuerpo.

Cada variación de asunto llevaba al mismo lugar: un enlace con estilo [Start Survey] que apuntaba a hxxps://ipelc.gob[.]bo/boots_store/.

La carga útil vivía en un sitio web del gobierno boliviano

Ese dominio de la carga útil es la parte de este incidente que vale la pena detallar. ipelc.gob[.]bo no es infraestructura del atacante en el sentido habitual. El espacio de nombres gob.bo es el dominio de nivel superior gubernamental de Bolivia, administrado por ADSIB, la agencia estatal para el desarrollo de la sociedad de la información, con sede en La Paz. IPELC en sí es el Instituto Plurinacional de Estudio de Lenguas y Culturas, un instituto gubernamental boliviano real para el estudio de los idiomas y culturas del país. Su sitio web real es exactamente lo que cabría esperar: avisos oficiales, diccionarios y referencias gramaticales.

Figura 4: La página web de ipelc.gob[.]bo, que actores de amenazas comprometieron.

Figura 5: WHOIS del registro para el espacio de nombres. gob.bo es administrado por ADSIB, la agencia estatal de la sociedad de la información boliviana en La Paz, atendida por servidores de nombres anycast (incluyendo NS.DNS.BR y NS2.NIC.FR).
El actor había entrado por la fuerza en este sitio gubernamental y plantado su kit de phishing en un subdirectorio /boots_store/. Esta es una elección deliberada, y deprimentemente efectiva. Un boots-rewards-uk[.]xyz recién registrado activa heurísticas de antigüedad de dominio, puntuación de reputación y listas de bloqueo el primer día. Una ruta en un dominio legítimo, de larga data y propiedad del gobierno hereda toda la confianza de ese dominio. Es más antiguo que cualquier lista de bloqueo, resuelve limpiamente, lleva un .gob.bo que luce oficial, y pasa por filtros que habrían matado un dominio desechable al instante. Comprometer el sitio confiable de alguien más es más barato para el atacante que construir el suyo propio.

El kit en él era un clon completo de la tienda de Boots, y el embudo estaba diseñado para recolectar, no para vender:

Figura 6: La tienda clonada de Boots y el modal de "encuesta de satisfacción del cliente", servidos desde ipelc.gob[.]bo/boots_store/, ofreciendo un regalo gratis de un patrocinador falso, "Skinny Tan".
Figura 7: El paso "thank you for your feedback, redeem your gift", alcanzado después de un par de preguntas de encuesta desechables, con el patrocinador falso adjunto.

Figura 8: El paso "Secure Checkout / Your details", recolectando nombre completo, correo electrónico, fecha de nacimiento, teléfono y dirección de domicilio para un pedido de £0.00. El paso de pago detrás de él es donde irían los datos de la tarjeta.

El objetivo final aquí son los datos personales y financieros. La encuesta es el calentamiento, el "regalo gratis" es el cebo, y el formulario de entrega de "pago seguro" es la captura: nombre completo, correo electrónico, fecha de nacimiento, número de teléfono y dirección de domicilio, envueltos como regalo por la víctima, con un paso de pago esperando detrás para los datos de la tarjeta.

Completa esta encuesta, y lo único que recibes es un paquete de inicio para robo de identidad.

Directo a los servidores de correo del mundo

Vale la pena aclarar por qué el kit estaba en el escritorio del cliente en primer lugar. Esto no era persistencia, ni ransomware. El actor no tenía interés en mantener un punto de apoyo silencioso para volver a entrar más tarde. Gammadyne se ejecuta localmente y contacta directamente a los servidores de correo de los destinatarios, así que el mailer, el archivo de proyecto y las seis listas milk tenían que vivir en la máquina que haría el envío. Lo que el actor realmente quería era la IP de salida limpia y sin marcar del host, y su ancho de banda. Cada uno de los 8.9 millones de mensajes saldría desde la dirección IP del cliente, no la del operador, y una vez que esos mensajes comenzaran a aparecer en listas de bloqueo de spam, sería la reputación del cliente la que quedaría marcada y bloqueada. Prepararse en el escritorio le compró al operador una IP desechable desde la cual enviar, no un punto de apoyo al cual regresar.

Esto ahora plantea la pregunta que más le importaba al socio. ¿Se estaba usando la propia infraestructura de correo del cliente para enviar esto? Si un tenant comprometido reenvía unos pocos millones de mensajes de spam, el dominio de ese tenant termina en listas de bloqueo y el correo legítimo deja de entregarse durante semanas. El radio de impacto es toda la comunicación del negocio con clientes y usuarios, mucho más allá de una sola máquina.

Los registros de eventos lo respondieron directamente, y para el socio, la respuesta fue un pequeño alivio: el mailer nunca tocó el tenant de correo del cliente. dracii.mmp lo tenía configurado para entrega directa.

Normalmente, enviar correo implica retransmisión. Tu cliente de correo entrega el mensaje al servidor de salida de tu propio proveedor, un tenant de Microsoft 365 o Google, digamos, y ese servidor hace el resto. Busca los registros MX (Mail Exchange) del dominio del destinatario, las entradas DNS que nombran a los servidores responsables de recibir el correo de un dominio, se conecta a uno de ellos, y entrega el mensaje en tu nombre. El extremo receptor ve que el correo llega desde la IP del proveedor, llevando la reputación de envío del proveedor. La entrega directo a MX elimina al proveedor de esa cadena. El software de envío se convierte en su propio agente de transferencia de correo: para cada destinatario, hace la búsqueda MX por sí mismo y abre una conexión directamente al servidor de correo del destinatario en el puerto TCP 25, sin nada en medio. Así es exactamente como estaba configurado gm.exe: sin host inteligente ni retransmisión, 666 hilos a la vez en lotes de 50. Para un spammer, es la elección obvia. No hay cuenta de proveedor que pueda ser limitada o cerrada, no hay límites de envío que infringir, y, lo más útil, el correo sale directamente desde la propia IP del host comprometido, así que es la dirección de la víctima la que carga con el bloqueo en lugar de algo perteneciente al atacante. Es la misma lógica que dejó a la campaña sin firma DKIM real en ningún lugar: sin retransmisión a la cual autenticarse, la única "firma" en este correo fue el bloque PGP falso pegado en el cuerpo.

La telemetría del host mostró precisamente eso. Una vez que el aislamiento colocó un filtro de denegación predeterminada frente a la máquina, Windows Filtering Platform registró cada conexión que el filtro eliminó (Evento 5157), y en una sola ráfaga de 104 segundos, gm.exe lanzó 29,954 conexiones salientes al puerto 25, distribuidas en 1,641 servidores de correo distintos.

\device\harddiskvolume4\users\[user]\desktop\dam pe uk puterniiicccc\gm.exe

Dos cosas se desprenden de esto. Primero, el riesgo de retransmisión recae en la IP de salida del servidor de terminal, no en el tenant de correo del socio, lo que reduce considerablemente la limpieza; el propio dominio de correo y la reputación del tenant del socio nunca fueron los que estaban enviando. Segundo, una advertencia sobre lo que el registro de bloqueos puede y no puede mostrar. El mailer había estado ejecutándose antes de que cortáramos el acceso del host, 666 hilos moliendo las listas milk, y el evento 5157 solo comienza a registrarse una vez que el aislamiento coloca el filtro de denegación predeterminada frente a la máquina. Desde las 03:47:03, ese filtro eliminó cada conexión que gm.exe abría, 29,954 de ellas en 104 segundos, ninguna logrando salir del host. Lo que no pudo hacer fue recuperar lo que ya había salido en la ventana antes de que entrara en vigor, y en un servidor tan poco auditado, no podemos ponerle un número a eso. Lo que sí podemos decir es que el aislamiento atrapó la campaña a mitad de envío y la cerró donde estaba.

El filtro estaba funcionando en ambas direcciones a la vez. Mientras eliminaba el SMTP saliente de gm.exe, también estaba descartando los intentos entrantes del actor de reconectarse desde 212.93.152[.]37, junto con el martilleo de fondo constante de las mismas fuentes de fuerza bruta que habíamos visto golpear el portal RDWeb durante días, 87.251.64[.]134 y el rango 88.210.63[.]0/24 entre ellas. La puerta se cerró desde ambos lados al mismo tiempo.

Entonces, ¿qué hizo Huntress?

Las señales se acumularon rápidamente. Una detección crítica y expedita a las 03:38:53 UTC: involucrando una estación de trabajo maliciosa vista previamente DESKTOP-[REDACTED], autenticándose por RDP con una credencial de dominio válida. Luego, a las 03:41:46 UTC, una segunda señal del mismo nombre de estación de trabajo llegó al controlador de dominio. El SOC lo clasificó como un incidente de alta severidad y no esperó a ver cómo evolucionaba.

Los analistas de inmediato:

• Aislaron masivamente los 25 endpoints en la organización.
• Marcaron la cuenta comprometida y el servidor de terminal para el socio, de modo que las credenciales robadas pudieran restablecerse en el controlador de dominio.

Aislar toda la red, en lugar de solo el servidor de terminal, se redujo a una cosa: no había autenticación multifactor (MFA) en ningún lugar frente a él. El actor ya tenía una credencial de dominio funcional; los registros del portal mostraban que esa misma credencial había sido validada desde múltiples direcciones, incluyendo un bot de fuerza bruta no relacionado, y había sido reutilizada a través de un portal expuesto a internet durante más de un día. Cualquiera de los otros 24 endpoints podía ser alcanzado con esa misma contraseña, o con una segunda que aún no habíamos visto. En lugar de esperar para confirmar, retiramos cada dispositivo de la red para que ninguna cuenta comprometida pudiera autenticarse mientras elaborábamos un reporte detallado.

Para cuando tuvimos al socio en el teléfono, el mailer estaba bloqueado a mitad de envío, la sesión RDP estaba cortada, cada reconexión desde la dirección rumana estaba siendo descartada, y el controlador de dominio no tenía nada más que tres verificaciones de credenciales que no llevaron a ningún lado. Los analistas del Huntress SOC también proporcionaron un reporte completo de remediaciones inmediatas para que el socio siguiera y pudiera restaurar su entorno en línea lo antes posible.

El sitio que servía esa carga útil también fue una víctima. ipelc.gob[.]bo pertenece a un instituto estatal boliviano genuino, y el actor estaba ejecutando el kit de phishing en él sin conocimiento del instituto. Huntress notificó al CSIRT nacional de Bolivia, el Centro de Gestión de Incidentes Informáticos (CGII), que opera bajo la agencia estatal de TIC AGETIC, que el dominio había sido comprometido y estaba sirviendo un kit con la marca Boots desde /boots_store/. Reportamos lo que teníamos y no tomamos ninguna acción adicional sobre un sistema que no era nuestro para tocar. La remediación les corresponde a ellos.

Conclusión

Elimina la marca Boots y el dominio del gobierno boliviano, y esto es una historia vieja contada con herramientas actuales. Un portal de acceso remoto expuesto a internet, un conjunto válido de credenciales, sin autenticación de segundo factor, y un atacante que inicia sesión y se pone a trabajar. La contraseña ni siquiera se guardó con cuidado: para cuando nuestro actor se reconectaba el 16 de mayo, el portal ya había validado esa misma credencial para un bot de fuerza bruta no relacionado y para otra dirección días antes. Lo que el actor hizo una vez dentro (ejecutar un mailer masivo legítimo contra nueve millones de direcciones) es casi mundano. El ingenio estuvo todo en la preparación: una herramienta que ningún antivirus marcará, enviada directamente a Mail Exchange (MX) para no necesitar el propio servidor de correo de la víctima, apuntando a una carga útil estacionada en un sitio gubernamental secuestrado que ningún motor de reputación bloqueará.

Indicadores de compromiso (IoC)

Indicadores de red

216.152.151[.]168

80.94.95[.]37

87.251.64[.]134

88.210.63[.]0/24

DESKTOP-[REDACTED]

hxxps://ipelc.gob[.]bo/boots_store/

lacafea77[@]outlook[.]com

Hashes de archivos (SHA256)

dc8a31a104df44b76a05c3e6d4fbe85be243cc6db0ff25e298e25cc469715046

gm.exe, Gammadyne Mailer (herramienta comercial legítima de correo masivo, abusada).

                

dracii.mmp, archivo de proyecto de Gammadyne (remitente, señuelos, carga útil, configuración de entrega).

                

milk (1).txt, lista de destinatarios (1,000,000 direcciones).

                

milk (2).txt, lista de destinatarios (1,329,883 direcciones).

                

milk (3).txt, lista de destinatarios (684,976 direcciones).

                

milk (4).txt, lista de destinatarios (3,880,061 direcciones).

                

milk (5).txt, lista de destinatarios (1,000,000 direcciones).

                

milk (6).txt, lista de destinatarios (1,000,000 direcciones).

                

Artefactos del host y de la campaña

boots <hello[@]boots[.]com>