Introducción
En este proyecto se realizó un análisis de tráfico de red extraído de https://malware-traffic-analysis.net/2020/09/30/index.html.
Objetivos
El trabajo se centró en reconstruir la cadena de ataque, identificar servidores C2, obtener indicadores de compromiso y distinguir también el tráfico legítimo del malicioso.
Escenario del incidente
El archivo de análisis proviene de malware-traffic-analysis.net y fue extraído de un caso real que sucedió el 30 de septiembre de 2020.
En la captura se puede observar tráfico de una máquina Windows durante una infección.
La intención del proyecto es reconstruir el incidente utilizando solo el tráfico de red.
No existe acceso al equipo comprometido ni registros de sistema. Toda la investigación se basa en el .pcap.
Inspeccionando el tráfico local (protocolo NetBIOS y DNS), se obtuvieron los datos del host:
- IPv4 interna: 10.9.30.101
- Dirección MAC: 00:08:08:1C:47:AE
- Hostname: DESKTOP-USER1PC
- Entorno de red: WORKGROUP (sin dominio)
- Gateway: 10.9.30.1
Herramientas utilizadas
La herramienta principal utilizada fue Wireshark. La captura mostró un total de 6708 paquetes.
Se utilizó también VirusTotal como complemento del análisis para verificaciones durante la investigación.
Metodología
Como primer paso se observaron las estadísticas de la captura. El objetivo de esto es tener un panorama completo acerca de lo que tenemos entre manos y además ofrece indicios para saber dónde enfocar el principio de la investigación.
Luego se comenzó a analizar los primeros paquetes HTTP para entender cómo era el flujo de datos y qué sucedía entre la comunicación.
Análisis de tráfico
En los primeros paquetes se puede observar la consulta DNS para conocer la IP de
brightnetworktv[.]com. Tras recibir su respectiva IP se abre la petición HTTP GET hacia el host.La primera actividad relevante sucede en el paquete 6 donde observamos una petición GET del cliente hacia un servidor aparentemente de WordPress pero apuntando a una dirección sospechosa: /wp-content/Pages/ia3jAonYBM3f3SCDQ/
Al hacer un seguimiento HTTP se puede ver con mejor detalle lo que sucede. El cliente utiliza Windows NT 10.0 y hace la petición a través de un navegador Edge a un dominio llamado
brightnetworktv[.]com que apunta a 3.23.235.182.La respuesta del servidor es un 200 OK y envía por attachment un archivo llamado
FILE-2020_09_30-493847.doc.
Lo que se realizó a continuación fue la extracción de ese documento a través de la cadena de paquetes TCP y se obtuvo el archivo Word.
Al obtener la huella digital se utilizó VirusTotal para verificar el archivo en cuestión.
https://www.virustotal.com/gui/file/d170d4853313c3d42e35cf2c19593158ef3d0bb0070faad32f65ddefabed67fcObservamos entonces que la reputación obtenida por VirusTotal asocia al archivo extraído de la captura (archivo Word) con Emotet.
Comunicaciones posteriores
El enfoque fue puesto en peticiones HTTP GET por lo tanto utilizamos
http.request.method == "GET" para filtrar los paquetes.
La mayoría de los paquetes son consultas legítimas a servidores de Microsoft pero podemos observar además el paquete 341 diferente al que ya vimos que también está dirigido hacia una página de WordPress pero con IP destino diferente a la anterior:
45.159.115.191.
Observamos algo interesante. El cliente realiza una petición hacia un recurso en HTTP y el servidor responde con 301 haciendo referencia a que debe buscar con HTTPS esa misma ruta. Esto es sospechoso: la petición es hacia una ruta poco común.
Cuando recibe la redirección, el host abre una conexión TCP en 443 (observemos el paquete 344). Luego inicia el handshake donde el campo SNI confirma la conexión hacia pershel[.]com.
Una vez realizado, posteriormente observamos que a partir del paquete 357 inicia una transmisión cifrada de datos.
Para tener el flujo completo HTTP vamos a buscar con
http.request en la captura para filtrar tanto los GET como los POST.
Servidores C2
Vemos múltiples HTTP POST 682-2356 hacia distintas IPs con URIs aleatorias. Esto es el cliente enviando datos hacia destinos desconocidos. Las direcciones no tienen estructuras coherentes como páginas convencionales.
Entonces dado esto último podemos decir que el patrón muestra consistencia en una comunicación con el cliente infectado hacia servidores C2.
Si nos fijamos en la cronología de la investigación tiene sentido: descarga de archivo malicioso - segundos después aparece comunicación extraña en paquete 341 - luego termina enviando POST repetitivos hacia diferentes servidores.
Mas abajo observamos nuevamente los GET a los servidores de Microsoft que ya vimos anteriormente y luego siguen un par de HTTP POST adicionales.
Con lo observado en esta parte podemos destacar varios cosas clave:
- Al filtrar consultas DNS del archivo, se aprecia que no hay conexiones previas para las direcciones IP 80.87.201.221, 62.210.90.75, 202.22.141.45. Este es un comportamiento de servidores C2 con una lista dentro del malware ya establecida.
- Todos los servidores C2 respondieron a las peticiones POST con HTTP/1.1 200 OK. Esto quiere decir que hubo comunicación entre cliente-servidor y por ende, recibió la víctima respuestas del atacante.
- Se detectó también una consulta DNS a ident[.]me para obtener IP pública del host comprometido (173.66.4[.]97) y consultas a listas de reputación de servidores de correo (zen.spamhaus[.]org y cbl.abuseat[.]org).
IOCs
-
Dominios
Dominio Descripción brightnetworktv.com Dominio por donde se descargó el documento Word. pershel.com Dominio que fue observado en comunicaciones posteriores a la infección. -
Direcciones IP
IP Observación 3.23.235.182 Servidor asociado a la descarga inicial del documento. 45.159.115.191 Servidor correspondiente a pershel.com.80.87.201.221 Destino de múltiples solicitudes HTTP POST. 62.210.90.75 Destino de múltiples solicitudes HTTP POST. 202.22.141.45 Destino de solicitudes HTT POST (C2 contactado). -
Archivos
Nombre SHA-256 FILE-2020_09_30-493847.doc d170d4853313c3d42e35cf2c19593158ef3d0bb0070faad32f65ddefabed67fc -
User-Agent
Ruta User-Agent GET /wp-content/Pages/ia3jAonYBM3f3SCDQ/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36 Edg/85.0 POST /9E4lXP65j9LF9Y7R/ HTTP/1.1 Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Mapeo MITRE ATT&CK
| Táctica | Técnica | ID | Observación |
|---|---|---|---|
| Initial Access | Drive-by Compromise | T1189 | Descarga del documento Word inicial desde un servidor comprometido usando navegador Edge. |
| Execution | User Execution: Malicious File | T1204.002 | La actividad posterior al paquete 6 es consistente con la ejecución de macros por parte del usaurio. De todas formas esto se infiere. No existen registros del endpoint donde podamos evaluar esta técnica. |
| Command and Control | Ingress Tool Transfer | T1105 | Segunda etapa del malware desde pershel.com usando canal HTTPS/TLS. |
| Discovery | System Network Configuration Discovery | T1016 | Consulta DNS a ident.me para obtener IP pública del host y verificar en listas Spamhaus/Abuseat. |
| Command and Control | Application Layer Protocol: Web Protocols | T1071.001 | Tráfico hacia C2 mediante peticiones HTTP POST con URls aleatorias y con respuestas 200 OK. |