Reconstruyendo una intrusión en un servidor IIS mediante correlación de tráfico de red, memoria RAM y análisis de malware
Introducción
En una investigación forense, pocas veces una única fuente de evidencia es suficiente para comprender completamente un incidente de seguridad. Los atacantes dejan rastros distribuidos entre diferentes capas del sistema: las comunicaciones de red reflejan el acceso inicial y el movimiento del atacante; la memoria RAM conserva procesos, conexiones y artefactos efímeros imposibles de recuperar posteriormente; y el análisis del malware permite identificar tanto las capacidades del código malicioso como la infraestructura utilizada para controlar el sistema comprometido.
La correlación entre estas fuentes de información constituye uno de los pilares fundamentales del Digital Forensics & Incident Response (DFIR), ya que permite reconstruir cronológicamente las acciones realizadas durante una intrusión y comprender la relación existente entre cada uno de los artefactos encontrados.
En este artículo analizaremos un compromiso sobre un servidor Microsoft Internet Information Services (IIS) utilizando tres evidencias principales:
- Una captura completa del tráfico de red (PCAP).
- Un volcado de memoria RAM obtenido durante el incidente.
- El binario malicioso recuperado del sistema comprometido.
El objetivo de la investigación consiste en reconstruir la cadena completa de ataque, identificar el origen del compromiso, comprender el mecanismo utilizado para obtener acceso remoto al servidor y determinar el malware finalmente desplegado por el atacante.
A diferencia de un análisis aislado de cada evidencia, este estudio demuestra cómo la correlación entre tráfico de red, memoria volátil e inteligencia sobre amenazas permite obtener una visión mucho más completa del incidente.
Escenario de la investigación
La investigación comienza tras la detección, por parte del Centro de Operaciones de Seguridad (SOC), de varias conexiones salientes anómalas originadas desde un servidor Microsoft IIS expuesto a Internet.
Aunque inicialmente únicamente se dispone de una alerta relacionada con comunicaciones sospechosas hacia una dirección IP externa, la adquisición de evidencias permite ampliar considerablemente el alcance de la investigación.
Durante el proceso forense se pretende responder a varias cuestiones fundamentales:
- ¿Cuál fue el origen del ataque?
- ¿Cómo consiguió el atacante acceder al servidor?
- ¿Qué acciones realizó una vez comprometido el sistema?
- ¿Existió algún mecanismo de persistencia?
- ¿Qué malware terminó ejecutándose?
- ¿Qué infraestructura de mando y control utilizó?
Para responder a estas preguntas se emplearon diferentes herramientas de análisis, entre ellas Wireshark para el estudio del tráfico de red, Volatility 3 para el análisis del volcado de memoria y VirusTotal como apoyo en la clasificación e identificación del malware recuperado.
Reconstruyendo el acceso inicial mediante el análisis del tráfico de red
La captura de tráfico constituye el primer artefacto analizado durante la investigación, ya que permite observar el comportamiento del atacante antes incluso de conseguir acceso al sistema comprometido.
Mientras que otras evidencias muestran únicamente el estado final del servidor, el PCAP ofrece una visión cronológica de las comunicaciones realizadas durante el ataque, permitiendo reconstruir las fases iniciales del compromiso.
Evidencia 1 – Identificación del origen del reconocimiento
El primer paso consiste en analizar las conversaciones presentes en la captura mediante la funcionalidad Statistics → Conversations de Wireshark.
A simple vista destaca una conversación muy por encima del resto. La dirección 10.0.2.4 mantiene una comunicación constante con el servidor 10.0.2.15, acumulando más de seis mil paquetes intercambiados entre ambos sistemas.
Este volumen de tráfico resulta significativamente superior al resto de conversaciones presentes en la captura, lo que constituye un claro indicador de una fase intensiva de reconocimiento previa a la explotación.
La distribución temporal de los paquetes, unida al elevado número de solicitudes consecutivas, permite concluir que la dirección 10.0.2.4 corresponde al origen de la actividad maliciosa.
Sistema atacante
10.0.2.4
Servidor comprometido
10.0.2.15
Este comportamiento resulta habitual durante las primeras fases de una intrusión. Antes de explotar un servicio vulnerable, los atacantes suelen identificar qué protocolos se encuentran disponibles, qué recursos ofrece el servidor y qué vectores de acceso pueden resultar útiles durante la siguiente etapa del ataque.
La captura muestra precisamente ese patrón: un reconocimiento sistemático dirigido exclusivamente contra el servidor IIS.
Evidencia 2 – Enumeración de recursos compartidos mediante SMB
Una vez identificado el origen del reconocimiento, el siguiente paso consiste en aislar el tráfico SMB para determinar qué acciones concretas realizó el atacante.
Para ello se aplica el siguiente filtro en Wireshark:
ip.src == 10.0.2.4 && ip.dst == 10.0.2.15 && (smb || smb2)
El resultado revela varias peticiones SMB2 Tree Connect Request dirigidas contra dos recursos compartidos del servidor:
\\10.0.2.15\IPC$
\\10.0.2.15\Documents
Desde una perspectiva forense, estas peticiones constituyen una evidencia muy relevante.
El recurso IPC$ es utilizado habitualmente por Windows para operaciones administrativas remotas y establecimiento de sesiones SMB, mientras que el acceso al recurso Documents indica que el atacante intenta localizar directorios sobre los que posteriormente pueda interactuar.
Este comportamiento encaja con una fase de enumeración de servicios y recursos compartidos, donde el objetivo consiste en identificar ubicaciones válidas para escribir contenido o desplegar herramientas adicionales.
La actividad observada puede asociarse con la técnica MITRE ATT&CK T1046 – Network Service Discovery, utilizada por numerosos actores de amenaza para descubrir servicios accesibles antes de continuar con la explotación del sistema.
Aunque en este momento todavía no existe evidencia de ejecución de código, el comportamiento observado anticipa claramente la siguiente fase del ataque.
Evidencia 3 – Implantación de una Web Shell sobre Microsoft IIS
Tras la enumeración de los recursos compartidos, el tráfico SMB muestra un cambio significativo en el comportamiento del atacante.
Mientras que las primeras comunicaciones estaban orientadas exclusivamente al reconocimiento del sistema, las siguientes operaciones corresponden ya a escrituras de archivos sobre el servidor comprometido.
Entre todas ellas destaca una operación SMB2 Write Request cuyo destino corresponde al archivo:
shell.aspx
El propio paquete SMB indica un tamaño aproximado de:
1.015.024 bytes
La extensión .aspx convierte este hallazgo en una de las evidencias más relevantes de toda la investigación.
Microsoft IIS interpreta automáticamente este tipo de archivos como aplicaciones ASP.NET ejecutables. Por tanto, la copia remota de un archivo ASPX no supone únicamente la transferencia de un fichero, sino la implantación potencial de una Web Shell capaz de ejecutar comandos directamente sobre el servidor.
Desde una perspectiva DFIR, este momento marca el punto exacto en el que el atacante consigue establecer un mecanismo de acceso persistente al entorno comprometido.
Hasta este instante únicamente existían evidencias de reconocimiento y enumeración; a partir de la escritura de shell.aspx, el escenario cambia completamente, ya que el atacante dispone de un punto de entrada capaz de ejecutar instrucciones arbitrarias en el servidor web.
La cronología observada en el PCAP respalda esta hipótesis: inmediatamente después de la transferencia del archivo comienzan a aparecer nuevas comunicaciones que ya no responden a un proceso de reconocimiento, sino al establecimiento de una sesión interactiva con el sistema comprometido.
Evidencia 4 – Establecimiento del canal de acceso remoto
Tras identificar la transferencia de la Web Shell al servidor IIS, el siguiente paso consistió en determinar si el atacante había conseguido establecer una sesión remota sobre el sistema comprometido. Para ello se analizaron las conexiones TCP iniciadas por el propio servidor mediante el siguiente filtro en Wireshark:
ip.src == 10.0.2.15 && ip.dst == 10.0.2.4 && tcp
El resultado muestra un cambio significativo respecto a las fases iniciales del ataque. Mientras que durante el reconocimiento era la dirección 10.0.2.4 quien iniciaba todas las comunicaciones contra el servidor IIS, ahora es el propio servidor comprometido quien establece nuevas conexiones TCP hacia el equipo atacante.
El análisis del tráfico revela que dichas conexiones tienen como destino el puerto:
4443/TCP
Aunque este puerto no corresponde al estándar utilizado por HTTPS, su numeración resulta lo suficientemente próxima al puerto 443/TCP como para pasar relativamente desapercibida en determinados entornos donde únicamente se monitorizan los servicios más habituales. Este tipo de puertos son empleados con frecuencia por herramientas de administración remota y distintas familias de malware para establecer canales de comunicación sin llamar la atención.
El seguimiento del flujo TCP evidencia un intercambio bidireccional de datos compatible con una sesión interactiva, lo que permite concluir que la Web Shell implantada previamente fue utilizada para establecer una Reverse Shell entre el servidor comprometido y la infraestructura controlada por el atacante.
La secuencia temporal observada en la captura resulta especialmente relevante desde el punto de vista forense. Inicialmente se aprecia la enumeración de recursos compartidos mediante SMB, seguida de la transferencia del archivo shell.aspx mediante una operación SMB2 Write Request. Apenas unos segundos después, el propio servidor inicia una conexión saliente hacia la misma dirección IP desde la que había recibido el fichero.
La proximidad temporal entre ambos eventos constituye una fuerte evidencia de que la Web Shell fue ejecutada inmediatamente después de su implantación, proporcionando al atacante acceso remoto al servidor.
Hasta este momento de la investigación es posible reconstruir con un elevado grado de confianza las primeras fases del compromiso:
- El atacante identifica el servidor IIS mediante un proceso de reconocimiento.
- Enumera los recursos compartidos disponibles a través de SMB.
- Transfiere una Web Shell ASPX al servidor comprometido.
- Ejecuta la Web Shell y establece una Reverse Shell sobre el puerto TCP/4443.
Aunque el análisis del tráfico de red ha permitido reconstruir con precisión el acceso inicial al servidor, todavía permanecen abiertas varias cuestiones fundamentales. Resulta necesario determinar qué acciones realizó el atacante una vez obtuvo acceso interactivo al sistema, qué procesos fueron ejecutados durante la intrusión y si llegó a implantar algún mecanismo que le permitiera mantener el acceso tras un reinicio del servidor.
Para responder a estas cuestiones se procedió al análisis del volcado de memoria RAM obtenido durante el incidente.
Evidencia 5 – Identificación del sistema comprometido
El análisis del volcado de memoria constituye el siguiente paso de la investigación, ya que permite observar el estado interno del sistema en el momento de la adquisición. A diferencia del tráfico de red, que únicamente refleja las comunicaciones intercambiadas entre equipos, la memoria conserva procesos en ejecución, conexiones activas, módulos cargados y otros artefactos volátiles que resultan esenciales para comprender el alcance real del compromiso.
Como punto de partida se ejecutó el plugin windows.info de Volatility 3, cuyo objetivo es recuperar información general sobre el sistema operativo presente en la imagen de memoria.
python3 vol.py -f memdump.mem windows.info
La salida del plugin permite identificar diversos parámetros del sistema, entre ellos la versión del sistema operativo, la arquitectura, la capa de traducción de memoria y, especialmente, la dirección base del kernel.
Kernel Base
0xf80079213000
La dirección base del kernel representa la ubicación de memoria donde Windows carga el núcleo del sistema operativo durante el proceso de arranque. Este valor actúa como punto de referencia para resolver direcciones virtuales y localizar correctamente estructuras internas del sistema, por lo que resulta imprescindible para que el resto de plugins de Volatility puedan interpretar correctamente los objetos presentes en memoria.
Aunque este dato no constituye por sí mismo una evidencia de actividad maliciosa, confirma que el perfil del sistema ha sido identificado correctamente y proporciona la base necesaria para continuar con el análisis de procesos, relaciones padre-hijo y mecanismos de persistencia implantados durante la intrusión.
Evidencia 6 – Descubriendo el proceso responsable del compromiso
Una vez validado el entorno de memoria, el siguiente paso consistió en enumerar los procesos activos mediante el plugin windows.pslist.
python3 vol.py -f memdump.mem windows.pslist
La lista de procesos muestra el funcionamiento habitual de un servidor Windows, donde destacan procesos del sistema como services.exe, svchost.exe, lsass.exe o explorer.exe.
Sin embargo, entre ellos aparece una relación especialmente llamativa.
El proceso encargado de ejecutar aplicaciones web en Microsoft IIS:
w3wp.exe
con PID:
4332
es el responsable de iniciar un ejecutable completamente ajeno al funcionamiento habitual del servidor:
updatenow.exe
Este hallazgo resulta especialmente significativo.
Durante el análisis del PCAP se observó cómo el atacante transfería una Web Shell al servidor IIS y establecía posteriormente una Reverse Shell. Ahora, gracias al análisis de memoria, es posible comprobar que dicha ejecución terminó materializándose en la creación de un nuevo proceso desde el propio servicio web.
La correlación entre ambas evidencias permite afirmar que el compromiso ya no se limita a la ejecución puntual de una Web Shell, sino que evolucionó hacia la implantación de un ejecutable persistente dentro del sistema.
Evidencia 7 – Reconstruyendo la cadena de ejecución
Con el objetivo de identificar la ubicación exacta del ejecutable se utilizó el plugin windows.cmdline, encargado de recuperar las líneas de comandos utilizadas para iniciar cada proceso.
python3 vol.py -f memdump.mem windows.cmdline
El resultado revela la ubicación completa del binario:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\updatenow.exe
Este hallazgo modifica completamente la interpretación del incidente.
El directorio Startup constituye una de las ubicaciones clásicas utilizadas por Windows para ejecutar automáticamente programas durante el inicio de sesión del usuario.
En otras palabras, el atacante no se limitó a ejecutar un malware de forma puntual, sino que lo copió deliberadamente a una ubicación destinada a garantizar su ejecución automática tras futuros reinicios del sistema.
Este comportamiento coincide con la técnica:
MITRE ATT&CK
T1547
Boot or Logon Autostart Execution
La utilización de este mecanismo evidencia que el objetivo del atacante no era únicamente obtener acceso temporal al servidor, sino mantener una presencia prolongada dentro del entorno comprometido.
Además, el hecho de que el ejecutable sea iniciado desde w3wp.exe establece una relación directa con la explotación observada previamente mediante la Web Shell.
La secuencia de acontecimientos comienza a adquirir una estructura perfectamente definida.
Correlación entre el tráfico de red y la memoria RAM
Llegados a este punto, ambas fuentes de evidencia comienzan a complementarse entre sí.
El PCAP mostraba únicamente cómo el servidor establecía una Reverse Shell tras la copia del archivo shell.aspx.
Sin embargo, la memoria permite observar qué ocurre después de obtener ese acceso.
La correlación entre ambas evidencias permite reconstruir la siguiente secuencia:
- El atacante enumera recursos SMB.
- Copia shell.aspx al servidor IIS.
- Ejecuta la Web Shell.
- El proceso w3wp.exe inicia un nuevo ejecutable.
- Dicho ejecutable corresponde a updatenow.exe.
- El binario se almacena en la carpeta Startup para garantizar su ejecución automática.
Este tipo de correlación resulta especialmente útil durante investigaciones reales, ya que ninguna de las dos fuentes de evidencia habría permitido reconstruir por sí sola toda la cadena de compromiso.
Identificando el malware desplegado
Tras identificar el ejecutable responsable del compromiso, el siguiente paso consistió en determinar su naturaleza.
El binario recuperado fue sometido inicialmente a un análisis estático mediante Virtus Total.
El análisis revela que el ejecutable se encuentra protegido mediante:
UPX
UPX constituye uno de los empaquetadores más utilizados tanto por software legítimo como por malware.
Su objetivo consiste en comprimir el ejecutable para reducir su tamaño, aunque en amenazas reales suele emplearse como primera capa de ofuscación para dificultar el análisis estático.
Aunque el uso de UPX no implica necesariamente comportamiento malicioso, sí constituye un indicador habitual en numerosas familias de malware.
Evidencia 8 – Clasificación mediante Threat Intelligence
Una vez obtenido el hash del archivo, éste fue consultado en VirusTotal con el objetivo de identificar campañas conocidas asociadas al binario.
El resultado muestra que el ejecutable es identificado como malicioso por 56 de 70 motores antivirus, lo que elimina prácticamente cualquier duda acerca de su naturaleza.
Durante el análisis también se observa que diferentes fabricantes clasifican la muestra como una variante de AgentTesla, una conocida familia de malware especializada en el robo de credenciales y el acceso remoto a sistemas Windows.
Entre las capacidades identificadas destacan:
- Robo de credenciales almacenadas.
- Captura de pulsaciones de teclado.
- Exfiltración de información.
- Comunicación con infraestructura de mando y control.
- Técnicas de evasión mediante Anti-Debug y Anti-VM.
- Consultas WMI para obtener información del sistema.
El análisis de relaciones de VirusTotal también permitió identificar el dominio utilizado por el malware para establecer comunicaciones con su infraestructura de mando y control:
cp8nl.hyperhost.ua
Este dominio representa uno de los últimos eslabones de la investigación, ya que permite relacionar el ejecutable con una infraestructura conocida y enriquecer el incidente mediante información de Threat Intelligence.
Correlación de evidencias
Una vez finalizado el análisis de todos los artefactos, resulta posible reconstruir cronológicamente la totalidad del compromiso.
| Fase | Evidencia obtenida |
|---|---|
| Reconocimiento | Identificación del servidor IIS desde 10.0.2.4 |
| Enumeración | Acceso a IPC$ y Documents mediante SMB |
| Compromiso inicial | Escritura remota de shell.aspx |
| Ejecución | Activación de la Web Shell |
| Acceso remoto | Reverse Shell mediante TCP/4443 |
| Memoria | w3wp.exe ejecuta updatenow.exe |
| Persistencia | Copia del binario en Startup |
| Malware | Identificación como AgentTesla |
| C2 | Comunicación con cp8nl.hyperhost.ua |
Cadena de ataque reconstruida
Reconocimiento del servidor IIS
│
▼
Enumeración SMB
│
▼
Acceso a IPC$ y Documents
│
▼
Transferencia de shell.aspx
│
▼
Ejecución de la Web Shell
│
▼
Reverse Shell TCP/4443
│
▼
w3wp.exe
│
▼
updatenow.exe
│
▼
Startup Folder
│
▼
Persistencia
│
▼
AgentTesla
│
▼
cp8nl.hyperhost.ua
Conclusiones
Este caso pone de manifiesto la importancia de abordar las investigaciones forenses desde una perspectiva multidisciplinar. Mientras que el análisis del tráfico de red permitió reconstruir el acceso inicial al servidor y la implantación de una Web Shell, el estudio del volcado de memoria reveló la ejecución del malware y el mecanismo utilizado para conservar el acceso al sistema. Finalmente, el análisis del binario y su enriquecimiento mediante fuentes de Threat Intelligence permitieron atribuir la muestra a la familia AgentTesla e identificar parte de su infraestructura de mando y control.
La correlación entre las distintas evidencias permitió reconstruir de forma íntegra la secuencia del ataque: desde el reconocimiento inicial del servidor IIS, pasando por la enumeración de recursos compartidos y el despliegue de la Web Shell, hasta la apertura de una Reverse Shell, la ejecución del malware desde w3wp.exe, su persistencia mediante la carpeta Startup y la posterior comunicación con el dominio de mando y control.
Este tipo de investigaciones demuestra que el verdadero valor del análisis forense no reside únicamente en examinar cada artefacto de manera individual, sino en establecer relaciones entre ellos para convertir evidencias aisladas en una reconstrucción completa y coherente del incidente. Es precisamente esa capacidad de correlación la que permite comprender el alcance real de un compromiso y proporcionar información accionable para su contención y prevención futura.
