Introducción

Las capturas de tráfico constituyen una de las principales fuentes de evidencia durante una investigación forense. Aunque habitualmente se asocian con la reconstrucción de comunicaciones entre equipos, su análisis puede proporcionar mucho más contexto: identificar el vector de infección, recuperar artefactos distribuidos por el atacante e incluso reconstruir el malware utilizado durante el compromiso.

En esta investigación se analizó una captura PCAP correspondiente a un equipo que había sido marcado por generar comunicaciones HTTP sospechosas. A partir de dichas comunicaciones fue posible reconstruir toda la cadena de infección, identificar el servidor desde el que se distribuyó el malware, recuperar el loader empleado durante la primera fase del ataque y reconstruir el payload final oculto bajo la apariencia de un archivo JPEG.

El análisis permitió determinar que el malware hacía uso de técnicas habituales de evasión, como la carga dinámica mediante Reflection, el empleo de LOLBins y la creación de mecanismos de persistencia mediante tareas programadas, permitiendo finalmente atribuir la muestra a la familia AsyncRAT.

Identificando la cadena de infección

El análisis comenzó revisando las comunicaciones HTTP presentes en la captura con el objetivo de determinar qué recursos habían sido descargados por el sistema comprometido.

Tras exportar los objetos HTTP únicamente se localizaron dos archivos transferidos desde la misma infraestructura remota: xlm.txt y mdm.jpg.

Evidencia 1 – Objetos HTTP recuperados

La existencia de únicamente dos descargas simplificó considerablemente la reconstrucción temporal del incidente. La secuencia observada evidenciaba una arquitectura de infección dividida en dos fases: un primer artefacto de pequeño tamaño, presumiblemente encargado de iniciar la infección, seguido de un segundo archivo de mayor tamaño que contenía el payload definitivo.

Para confirmar esta hipótesis se inspeccionó la petición HTTP correspondiente al segundo recurso descargado.

Evidencia 2 – Solicitud HTTP del payload

La respuesta permitió identificar la URL completa utilizada durante la descarga:

http://45.126.209.4:222/mdm.jpg

A simple vista todo indicaba que se trataba de una imagen JPEG legítima. Sin embargo, el análisis del contenido reveló un escenario completamente diferente.

Un archivo JPEG que nunca fue una imagen

Aunque el servidor respondía indicando el tipo MIME image/jpeg, la inspección del cuerpo de la respuesta HTTP puso de manifiesto que el contenido no correspondía a datos gráficos.

Evidencia 3 – Respuesta HTTP del recurso mdm.jpg

En lugar de una imagen, el archivo contenía un extenso script PowerShell encargado de reconstruir el malware durante su ejecución.

Entre el código destacaban dos variables llamadas $hexString_bbb y $hexString_pe, cuyo contenido estaba formado por miles de caracteres hexadecimales.

La presencia de la firma 4D 5A (MZ) al comienzo de ambas cadenas permitía determinar inmediatamente que el supuesto JPEG ocultaba realmente un ejecutable Portable Executable (PE) de Windows.

Este tipo de técnicas resulta habitual en campañas de malware actuales, ya que permite transportar ejecutables utilizando extensiones aparentemente inofensivas, dificultando tanto la inspección manual como determinados mecanismos automáticos de detección.

Analizando el loader PowerShell

Una vez extraído el contenido del script se procedió a eliminar la ofuscación para comprender su funcionamiento.

Evidencia 4 – Código PowerShell deofuscado

El análisis reveló que el loader convertía ambas cadenas hexadecimales en arrays de bytes para reconstruir dinámicamente el ejecutable en memoria.

Posteriormente empleaba Reflection.Assembly.Load(), junto con las funciones GetType(), GetMethod() e Invoke(), evitando escribir el binario sobre disco antes de ejecutarlo.

La utilización de Reflection constituye una técnica ampliamente utilizada por loaders desarrollados en PowerShell para reducir su huella sobre el sistema comprometido y dificultar el análisis basado únicamente en archivos.

Persistencia mediante LOLBins y tareas programadas

El loader no se limitaba a ejecutar el payload. El análisis del código permitió identificar la generación de varios artefactos auxiliares destinados a mantener la persistencia del malware.

Evidencia 5 – Archivos generados por el loader y ejecución mediante LOLBin

Durante su ejecución se crean los archivos:

• Conted.ps1
  
• Conted.bat
  
• Conted.vbs
  

Asimismo, el malware utiliza el binario firmado RegSvcs.exe, ubicado en:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe

El empleo de este ejecutable legítimo constituye una técnica Living off the Land Binary (LOLBin), aprovechando componentes nativos del sistema operativo para ejecutar código malicioso reduciendo la probabilidad de generar alertas.

Como mecanismo adicional de persistencia, el script registra una tarea programada denominada Update Edge, configurada para ejecutarse automáticamente cada dos minutos.

Evidencia 6 – Persistencia mediante Task Scheduler

La nomenclatura utilizada imita procesos legítimos del sistema operativo, una estrategia frecuentemente utilizada para dificultar su identificación durante revisiones manuales.

Enriquecimiento mediante Threat Intelligence

Tras reconstruir el ejecutable oculto en las cadenas hexadecimales se calculó su huella SHA-256 y se consultó en distintas plataformas de inteligencia de amenazas.

Evidencia 7 – Identificación del malware en VirusTotal

La muestra fue identificada como perteneciente a la familia AsyncRAT, presentando una elevada tasa de detección por parte de los motores antivirus. La clasificación resulta coherente con las técnicas observadas durante el análisis del loader, entre ellas la ejecución mediante Reflection, el uso de PowerShell como primera fase de la infección y la utilización de LOLBins para ejecutar el payload.

Posteriormente se analizó la infraestructura empleada para distribuir ambos artefactos.

Evidencia 8 – Información pública de la infraestructura remota

La dirección IP 45.126.209.4 pertenece al proveedor ReliableSite LLC, utilizado como servidor de distribución tanto del loader como del payload final identificado durante la investigación.

Visión general del flujo analizado

Como parte del análisis se revisó la jerarquía de protocolos correspondiente al flujo investigado.

Evidencia 9 – Jerarquía de protocolos del flujo TCP

Las estadísticas muestran que prácticamente la totalidad de los bytes transferidos durante la conversación corresponden a tráfico HTTP, lo que refuerza la hipótesis de una cadena de infección basada en la descarga secuencial de artefactos desde un servidor remoto.

Conclusiones

A partir de una única captura de tráfico fue posible reconstruir la cadena completa de infección, identificar la infraestructura utilizada para distribuir el malware y recuperar los dos artefactos empleados durante el compromiso. El análisis puso de manifiesto el uso de un loader PowerShell encargado de reconstruir un ejecutable Portable Executable oculto tras un aparente archivo JPEG, utilizando posteriormente técnicas de carga dinámica mediante Reflection, LOLBins y tareas programadas para ejecutar y mantener el payload en el sistema comprometido.

La correlación de todas las evidencias permitió atribuir la muestra a la familia AsyncRAT, demostrando cómo el análisis combinado de tráfico de red, ingeniería inversa básica y enriquecimiento mediante Threat Intelligence puede proporcionar una visión completa del incidente incluso cuando la única evidencia disponible es una captura PCAP.