El RAT que no moría

Respuesta a un incidente multi-malware (Remcos + XWorm) atribuido a Blind Eagle (APT-C-36): detección, threat hunting con PowerShell, contención y erradicación verificada.

Durante meses, una estación de trabajo de un área financiera aparecía marcada como comprometida por el firewall. La escanearon con dos antivirus distintos, en modo offline. "Limpio", decían. Y a los dos días, la alerta de Command & Control volvía.

Cuando me tocó investigarlo a fondo, la causa raíz resultó ser mucho más interesante que un simple virus. Este es el recuento técnico de cómo se detectó, analizó, contuvo y erradicó y de los tres giros que explicaban por que «siempre volvía».

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

⚠️ Aviso

Este documento está anonimizado. No contiene nombres reales de la organización, personas ni dominios corporativos. Los únicos indicadores reales publicados son IOCs del adversario (IPs de C2, dominios y hashes de malware), que constituyen inteligencia de amenazas de valor para la comunidad. Se comparte con fines educativos y de portafolio profesional.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

TL;DR

Una estación de un área financiera presentaba alertas recurrentes de C2 durante meses; los escaneos antivirus no erradicaban la amenaza. La investigación reveló tres causas:

1. Se estaba remediando el equipo equivocado. La IP de la alerta había rotado por DHCP y apuntaba a un equipo sano. Es decir, la alerta en escaneos anteriores se estaba asociando a la IP, no a la MAC.

2. No era una amenaza, sino cuatro familias operando juntas, con componentes fileless e inyección en procesos legítimos.

3. Persistencia redundante diseñada para reinstalarse sola.

Una vez identificado el host correcto, se contuvo a nivel de firewall (cero exfiltración confirmada), se erradicó mediante reinstalación limpia del SO, se endureció el equipo y se verificó la remediación por comportamiento de red. El patrón encaja con Blind Eagle (APT-C-36), actor enfocado en Latinoamérica.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

1. Contexto del entorno

Organización, PYME del sector distribución/financiero (LATAM)

Equipo afectado, Estación Windows 10/11, área de Contabilidad.

Perímetro; Firewall NGFW con detección de hosts comprometidos + colector de logs.

Telemetría, Logs de tráfico, alertas de "Compromised Host", caché DNS, procesos en vivo.

Acceso del analista, Remoto + presencial para la erradicación.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

2. Detección inicial

El módulo de detección del firewall marcó un host interno como Compromised, con beaconing sostenido hacia una IP externa clasificada como C2 / Malicious Websites, denegado por política. El destino resolvía a un dominio de DNS dinámico (DuckDNS) cuyo nombre incluía literalmente la cadena del RAT.

Señales que descartaron un falso positivo desde el inicio:

• Dominios de C2 autodescriptivos sobre DuckDNS (no infraestructura corporativa legítima).

• Beaconing cada 1–2 segundos sostenido en el tiempo, no un evento aislado.

• Puertos no estándar que ningún SaaS legítimo emplea.

• Rotación de infraestructura (múltiples IPs de C2 en distintos países).

Observación: un único indicador de reputación puede ser algo de ruido pero la correlación de varias señales independientes es lo que convierte una alerta en un veredicto sólido.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

3. El reto central: identificar el host correcto

Aquí estuvo la clave del caso. La alerta apuntaba a una IP interna, pero al conectarse a esa dirección se encontró un equipo completamente limpio, con tráfico legítimo y sin persistencia maliciosa. Esto generaba la sensación de "falso positivo".

La discrepancia se resolvió cruzando tres fuentes:

• El hostname reportado por el firewall no coincidía con el de la máquina investigada.

• La tabla DHCP del firewall, buscando por dirección MAC (el identificador que no cambia), reveló que el host comprometido había tomado otra IP y que el equipo investigado era un vecino distinto.

• Una segunda alerta confirmó la IP del C2 saliendo del host correcto.

Lección: ante una alerta de red, el identificador de confianza es la MAC, no la IP (que rota por DHCP) ni el hostname (que puede cambiar tras una reinstalación). Investigar por IP sin validar la MAC llevó a meses de remediación sobre la máquina equivocada — y explica por qué "siempre volvía".

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

4. Threat Hunting en el host correcto

Con acceso al equipo real, se realizó caza de amenazas centrada en comportamiento, no en firmas. Técnicas empleadas (PowerShell nativo, sin herramientas de terceros):

Captura del proceso que beaconea al C2. Como el firewall denegaba la conexión, esta nunca alcanzaba estado ESTABLISHED (moría en 'SynSent' en milisegundos). Una captura única la perdía; se usó un bucle de muestreo:

Procesos ejecutándose desde rutas de usuario (un binario legítimo rara vez corre desde AppData/Temp/ProgramData):

Get-CimInstance Win32_Process |

Where-Object { $_.ExecutablePath -match 'AppData|\\Temp\\|ProgramData|\\Roaming\\|\\Public\\' } |

Select Name,ProcessId,ExecutablePath,CommandLine

Get-CimInstance Win32_Process |

Where-Object { $_.ExecutablePath -match 'AppData|\\Temp\\|ProgramData|\\Roaming\\|\\Public\\' } |

Select Name,ProcessId,ExecutablePath,CommandLine

Persistencia: claves Run/RunOnce (incluyendo Wow6432Node), carpetas Startup, tareas programadas que invocan intérpretes de script, y suscripciones de eventos WMI.

Cálculo de hashes de cada artefacto:

Get-FileHash <ruta_del_binario> -Algorithm SHA256

Get-FileHash <ruta_del_binario> -Algorithm SHA256

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

5. Hallazgo: infección multi-malware con inyección en procesos

El bucle de captura reveló que cuatro procesos distintos beaconeaban al mismo C2 en puertos diferentes:

Observación: Que explorer.exe se conectara a un C2 fue la pieza que explicó por qué los antivirus no erradicaban la amenaza ya que el código malicioso vivía en la memoria de un proceso legítimo, no solo en archivos en disco.

Posteriormente, el antivirus oficial confirmó de forma independiente dos componentes adicionales:

• Un gusano que se propaga por USB y unidades de red mediante archivos '.lnk' (familia Jenxcus/Dunihi).

• Un loader PowerShell ofuscado detectado vía AMSI (ejecución en memoria), confirmando el componente fileless.

El gusano explicó el vector de propagación lateral: el equipo no se infectó de forma aislada, sino que la amenaza pudo saltar entre equipos vía medios extraíbles y carpetas compartidas.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

6. Mecanismo de persistencia «por qué siempre volvía»

El registro Run del usuario era una especie de nido, además de las entradas de arranque de los RATs, contenía una docena de entradas con nombres ofuscados, todas ejecutando el mismo script oculto:

Powershell.exe -WindowStyle hidden "& '<…>\Temp\xx2.vbs'"

Powershell.exe -WindowStyle hidden "& '<…>\Temp\xx2.vbs'"

Esto es redundancia deliberada: un watchdog con múltiples anclas. Borrar un componente activaba la reinstalación desde otra. A esto se sumaban droppers disfrazados de documentos (nombres tipo "factura", "escáner") y una tarea programada que lanzaba un ".js" desde una carpeta pública.

Observación: Cuando una amenaza reaparece tras la limpieza, el foco debe pasar del archivo al mecanismo es decir, persistencia redundante, componente fileless, o reinfección desde un vector aún abierto.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

7. Atribución: Blind Eagle (APT-C-36)

El conjunto de TTPs e infraestructura encaja con el perfil público de Blind Eagle / APT-C-36, actor con motivación financiera y de espionaje activo en Latinoamérica:

• Objetivo: organizaciones de la región, con foco en sectores financiero y gubernamental.

• Vector: phishing con adjuntos/enlaces maliciosos, frecuentemente con señuelos temáticos de la autoridad tributaria local.

• Arsenal: RATs commodity (Remcos, AsyncRAT, njRAT) cargados mediante scripts.

• Infraestructura: uso de DNS dinámico (DuckDNS) para el C2.

El vector de entrada original se rastreó a un correo de phishing con un adjunto de script (.jse) recibido meses antes.

«La atribución se presenta como hipótesis basada en la correlación de TTPs, no como afirmación forense definitiva.»

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

8. Contención

• Bloqueo de las IPs de C2 como destino en una política de denegación de emergencia del firewall.

• Bloqueo por comodín del dominio base de DNS dinámico (*.duckdns.org) en los filtros DNS y Web.

• Cuarentena por MAC del host comprometido.

La telemetría confirmó (Sent 0 / Received 0) en los intentos de C2: la contención impidió toda exfiltración.

Defensa en dos capas: el filtro DNS detiene la resolución de nombres, pero el malware también intentaba conexión directa por IP. Bloquear solo el dominio habría dejado pasar el tráfico. Ambas capas son necesarias.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

9. Erradicación

Dada la inyección en proceso de sistema + el componente fileless + la persistencia redundante, la limpieza por antivirus no era una opción confiable. Se aplicó el estándar de la industria: reinstalación limpia del sistema operativo.

• Respaldo selectivo de datos de usuario (solo documentos), escaneado en un equipo limpio antes de restaurar.

• Nunca se respaldaron ejecutables, scripts, ni el contenido de AppData/ProgramData/carpetas de inicio.

• Reinstalación con imagen limpia desde el fabricante y borrado de la unidad del sistema.

• Verificación de particiones de datos secundarias (que una reinstalación estándar no sobrescribe).

Observación: Un respaldo de un equipo comprometido es, hasta que se demuestre lo contrario, un vector de reinfección.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

10. Endurecimiento (hardening)

Sobre el sistema reinstalado, antes de devolverlo a producción:

• Un solo antivirus oficial como motor activo (se retiró un AV de terceros preinstalado que mantenía al motor nativo en modo pasivo, lo que deshabilitaba las reglas ASR).

• Reglas de Reducción de Superficie de Ataque (ASR) en bloqueo: ejecutable desde correo, scripts que lanzan binarios, Office creando procesos hijo, robo de LSASS y persistencia vía WMI.

• Windows Script Host deshabilitado, neutralizando el vector .js/.jse/.vbs que originó el incidente.

Observación: Las reglas ASR solo se aplican si el AV nativo es el motor activo. Es por ello que tomé la decisión de desactivar McAfee y reactivar Microsoft Defender, verificar el modo de ejecución (Normal vs Passive) es parte del hardening.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

11. Verificación de la remediación

No se confió en un escaneo de antivirus para declarar el equipo limpio (precisamente lo que antes daba falsos negativos en otros intentos de mis colegas). Se verificó por comportamiento:

• Bucle de captura de 60 s contra ambas IPs de C2 → sin un solo intento de conexión.

• Ausencia confirmada de los binarios y de las claves de persistencia.

• Caché DNS sin resoluciones a la infraestructura del adversario.

• Particiones de datos secundarias sin droppers.

Todos los indicadores que antes daban positivo pasaron a negativo verificado.

Observación: Verificar la erradicación por comportamiento de red supera la confianza ciega en el antivirus, sobre todo cuando el AV ya falló en detectar la amenaza activa.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

12. Indicadores de Compromiso (IOCs)

Infraestructura de red (C2)

IPv4: 172.111.162.252

IPv4: 177.67.105.14

Dominio: remcos8099.duckdns.org

Dominio: 2620remcos.duckdns.org

Dominio: negro07d8090.duckdns.org

Dominio: envio8092.duckdns.org

Puertos C2: 2620, 8090, 8091, 8092, 8099

Artefactos en host (SHA-256)

remcos.exe D312880A3B96319A2BC7EC6940C6303254573293F984DAF1C5D809AD8B3FB306

XWormClient.exe E8970CB0EBEDA91C65D2910B530763196AA742CC2C7FAB985E02AE59471498B2

xx2.vbs (watchdog) AE39B9E55BF6AD87F5712A6076E9EFB4A00FD0C4029F6F3B7445DC2B92B94F19

Rutas de persistencia observadas

• C:\ProgramData\Remcos\remcos.exe

• %AppData%\Roaming\XWormClient.exe

• %AppData%\Local\Temp\xx2.vbs

• C:\Users\Public\Downloads*.js

• Carpeta Startup del usuario

Detecciones por nombre (AV)

• Worm:Win32/Jenxcus!lnk

• Trojan:PowerShell/Boxter.HDA!MTB

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

13. Mapeo MITRE ATT&CK

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

14. Lecciones aprendidas (alineadas a NIST SP 800–61)

1.Valida la identidad del host por MAC, no por IP. El error más costoso fue investigar la máquina equivocada por confiar en la IP.

2.Una reaparición tras la limpieza apunta al mecanismo, no al archivo.

3.Para un host con RAT + inyección, reinstalar es la única erradicación confiable.

4. Contener en el perímetro de inmediato. El bloqueo de C2 garantizó cero exfiltración mientras se investigaba.

5. Verifica la erradicación por comportamiento de red. El antivirus que ya falló no es juez del cierre.

6. El endurecimiento debe escalar a todos los dispositivos, no solo al equipo afectado.

7. Rotación de credenciales obligatoria cuando hay keylogging confirmado.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Cierre

Este caso me dejó una convicción que aplico desde entonces: en respuesta a incidentes, la humildad de cuestionar tus propias suposiciones vale más que cualquier herramienta. Meses de remediación fallida no se debieron a un malware invencible, sino a una suposición del equipo no validada: que la IP de la alerta era el equipo incorrecto.

Si trabajas en Blue Team, DFIR o administración de sistemas, espero que este recuento te ahorre alguna de esas madrugadas.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Escrito como caso de estudio de respuesta a incidentes. Anonimizado y publicado con fines educativos y profesionales.