Cacería de Malware en Memoria
Escenario
La ferretería “Sierra S.A” ha sido víctima de un delito electrónico, los ciberdelincuentes han
intentado realizar una transacción no autorizada. El equipo de TI de la víctima, te ha contactado
para que realices la investigación. Ellos te han proporcionado un volcado de memoria del equipo
sospechoso como único insumo sujeto a analizar.
Tus objetivos
1. Identificar la amenaza en el sistema comprometido.
2. Identificar canales de comunicación hostiles (C2).
3. Identificar la manera en que el malware se ejecuta y persiste en el
sistema (en caso de persistir).
4. De ser posible, identificar el detonador de la infección en el sistema.
Requerimientos
➢ Máquina Virtual Kali Linux
• Volatility Framework (Viene preinstalada) Volatility
• Foremost (Viene preinstalada) Foremost
• Bulk_extractor (Viene preinstalada) Bulk
• Whois (Viene preinstalada)
• Geoiplookup (Requiere instalación)
• Editor de texto.
➢ Conexión a Internet.
➢ Un equipo con al menos 8 GB de memoria RAM y 4 núcleos.
Introducción
La memoria RAM contiene información crítica sobre el estado de ejecución del sistema
(mientras el sistema está activo) por lo que es posible reconstruir el estado del sistema frente a
objetos tan importantes como aplicaciones, archivos, archivos a los cuales accedían las
aplicaciones, conexiones de red, entre otros no menos importantes.
Siempre será bueno definir un plan de acción frente a la consecución de los objetivos de una
investigación. Para ello, lo primero que debemos hacer es definir el propósito de la misma. Esto
se puede conseguir a partir de la siguiente pregunta: ¿Qué es lo que quiero obtener?
Para responder dicha pregunta, es necesario definir la finalidad de la investigación. Un análisis
de memoria puede servirnos para realizar operaciones tan variadas como: investigaciones
forenses, respuesta a incidentes de seguridad, cacería de amenazas, entre otras.
Voy a partir del supuesto de que el aprendiz conoce diferentes técnicas de adquisición de
memoria. Por lo cual, saltaré esa etapa del proceso e iré al grano.
Andrés Olaya - @_4Sec_
Como en toda investigación forense, es de suma importancia preservar la evidencia. Por lo que,
es de suma importancia trabajar siempre, a partir de una tercera copia de la evidencia que
vamos a procesar. Hechas las copias, el primer paso será individualizar la evidencia:
md5: 7577c4d3d104ecf10bb1f1fa22296d7a infected.elf
Ha llegado el momento de trabajar con Volatility. Volatility es un framework de trabajo forense
avanzado para análisis de memoria volátil, esta escrito en Python, es multiplataforma y gratuito
Volatility .
Lo primero que se debe hacer es identificar el perfil del sistema al que pertenece el volcado que
vamos a analizar. Hay 2 formas de obtener el perfil del sistema, a través de 2 plugins,
ambos nos ofrecen datos distintos pero complementarios:
Imageinfo: Nos sugiere el perfil, nos brinda información sobre las capas, el tipo de PAE (activo
o no), el valor base de la tabla de directorio (DTB) utilizado para la traducción de direcciones, el
kdbg, el número de procesadores, el tipo de imagen (service pack), los KPCR de cada núcleo,
la región KUSER_SHARED_DATA que es una estructura de datos que contiene mucha
información del sistema de Windows, fecha de creación del volcado.
Ahora sabemos que:
✔ El sistema operativo al que pertenece el volcado hace parte de la familia
Windows7/Win2008 R2.
✔ El volcado fue realizado el 28-09-2020 a las 19:42:50 UTC -5
✔ El equipo tiene 2 núcleos.
✔ No utiliza PAE.
✔ Service Pack 1
✔ Base de la tabla de directorio - Directory Base Table DTB 0x187000 (No debe incluir la “L”)
(Sirve para llevar a cabo la traducción de direcciones virtuales a físicas)
• Kdbgscan: Busca y analiza las características del bloque de datos del depurador del kernel.
Nos ofrece información muy importante como los procesos en ejecución y los módulos del
kernel cargados. También brinda información sobre la versión, lo cual, nos permite determinar
Andrés Olaya - @_4Sec_
de qué sistema Windows proviene un volcado de memoria, qué Service Pack se instaló y el
modelo de memoria (32 bits frente a 64 bits).
Andrés Olaya - @_4Sec_
Ahora sabemos que:
✔ Habían 64 procesos en ejecución al momento de crear el volcado.
✔ Habían 144 módulos de kernel cargados.
✔ Perfil del volcado Win7SP1x64_24000
✔ Offset kdbg 0x2bfe120
Andrés Olaya - @_4Sec_
Con la información obtenida hasta este momento podremos construir la primera consulta. La
cual, consistirá en enumerar los 64 procesos:
A simple vista, todo luce normal.
Andrés Olaya - @_4Sec_
Para comenzar a construir la escena del delito, procedemos a validar las conexiones de red que
se encontraban activas al momento de hacer el volcado:
Tenemos 2 canales de comunicación establecidos TCPv4:
✔ 186.145.214.199:3040
✔ 8.18.25.72:443
Sin embargo, aún desconocemos la procedencia de dichos canales. Es el momento de
georeferenciar las direcciones IP:
Andrés Olaya - @_4Sec_
Andrés Olaya - @_4Sec_
8.18.25.72:
Andrés Olaya - @_4Sec_
Andrés Olaya - @_4Sec_
La dirección IP 8.18.25.72 pertenece al fabricante de la protección antimalware “McAfee”. Los
procesos que comienzan por mfe y mc, generalmente pertenecen a McAfee; sin embargo, es
debido a la experiencia que se puede diferenciar un proceso malicioso de uno legal. Es por
esto, que es recomendable realizar entrenamientos en los que se desplieguen las diferentes
soluciones antimalware y EDR del mercado, para familiarizarnos con escenarios reales.
Andrés Olaya - @_4Sec_
Andrés Olaya - @_4Sec_
Tenemos la dirección IP 8.18.25.72 relacionada con la protección antimalware “McAfee”.
En este orden de ideas, la dirección IP 186.145.214.199 es la pista que debemos seguir. Vamos
a comenzar por hacer un poco de inteligencia:
IP= 186.145.214.199 CO, Colombia (Valledupar) - TELMEX - CLARO (ISP)
Andrés Olaya - @_4Sec_
Hecho esto, debemos relacionar el canal de comunicación establecido entre la máquina
sospechosa y la dirección IP 186.145.214.199:3040 .
Para ubicar el proceso en el cual se encuentra establecido el canal de comunicación, podemos
utilizar la herramienta YARA. Para ello vamos utilizar como regla la dirección IP
186.145.214.199 de la siguiente manera:
No siempre se obtienen resultados positivos, aquí es donde debemos ser recursivos y no
estancarnos en la investigación ¡Hay que seguir buscando!
En este punto sería oportuno buscar y analizar los Mutex (es una forma muy poderosa de
analizar sistemas durante la respuesta a incidentes). Esto se puede explicar debido a que
cuando dos o más hilos necesitan acceder a un recurso compartido al mismo tiempo, el sistema
necesita un mecanismo de sincronización para asegurar que sólo un hilo a la vez utilice el
recurso. Mutex es una sincronización que otorga acceso exclusivo al recurso compartido a un
solo hilo. Si un hilo adquiere un mutex, el segundo hilo que quiere adquirir ese mutex se
suspende hasta que el primer hilo libere el mutex
Los mutex pueden ser de dos tipos:
☐ Mutex locales, que no tienen nombre.
☐ Mutex de sistema con nombre. Un mutex local sólo existe dentro de su proceso y sus
nombres son visibles en todo el sistema operativo y pueden utilizarse para sincronizar las
actividades de los procesos. Al registrar un archivo con un objeto mutex, los diferentes procesos
saben cuándo esperar para acceder al archivo hasta que otros procesos hayan terminado.
Debemos tener en cuenta que los programas maliciosos también lo hacen (a veces),
generalmente los utilizan para asegurarse de que sólo se pueda ejecutar una única copia de sí
mismo en un momento determinado. Lo bueno de esto (para nosotros como analistas) es que
se aplica a malware altamente sofisticado a nivel de kernel, así como también a malware no
sofisticado a nivel de usuario. Aún mejor, mientras que el malware puede hacer todo lo posible
por ocultar cualquier rastro de sí mismo en un sistema, generalmente necesita dejar sus objetos
mutex totalmente expuestos para el correcto funcionamiento del malware.
Para buscar los objetos de tipo Mutex, se pueden indicar los procesos en los cuales deseamos
realizar la búsqueda (búsqueda específica), pero también lo podemos hacer de manera
generalizada a través de una búsqueda generalizada, la búsqueda se hará en todos los
procesos; como no tengo un indicio fuerte, lo mejor es utilizar esta última (puede tomar un poco
más de tiempo):
Andrés Olaya - @_4Sec_
Definitivamente, Client.exe NO es un Mutex normal, se puede contrastar con los Mutex de los
PID 4972, 4992 y 5512.
Ahora tenemos el PID 5856 como principal sospechoso. En este momento es conveniente
analizar los handles del PID 5856. Lo que vamos a hacer es parametrizar la consulta de modo
que, podamos analizar los resultados de manera más clara en un archivo html. Esto lo hacemos
a través de los parámetros –output=html para dar formato y –output-file=nombre.ext para
señalizar el archivo de salida:
Andrés Olaya - @_4Sec_
Andrés Olaya - @_4Sec_
Andrés Olaya - @_4Sec_
Andrés Olaya - @_4Sec_
Andrés Olaya - @_4Sec_
Ahora tenemos una relación directa entre el PID 5856 y:
✔ El proceso dialer.exe.
✔ Una llave de registro USER\SOFTWARE\CLIENT.EXE
Andrés Olaya - @_4Sec_
Seguimos sin encontrar una relación con la dirección IP 186.145.214.199, por lo que es el
momento de validar de nuevo los procesos:
PID 2112 dialer.exe (finalizó el 28 de septiembre de 2020 a las 19:28:02).
PID 5856 MSBuild.exe (en ejecución al momento de hacer el volcado).
Es el momento de extraer todas las paginas residentes en la memoria del PID 5856
MSBuild.exe:
Andrés Olaya - @_4Sec_
Una vez que tenemos el volcado, lo primero es los strings para realizar las primeras consultas
en los resultados, para ello debemos ejecutar el comando strings con los parámetros -td -el para
que extraiga los strings ASCII y unicode, y lo finalizamos con > para que dirija el resultado a un
fichero de texto:
Hecho esto, llevamos el archivo de texto a un editor de texto y buscamos la dirección IP
186.145.214.199:
Ahora no sólo tenemos una relación entre el PID 5856 y la dirección IP 186.145.214.199, sino
que también tenemos un dominio willyrex2020.publicvm.com
Las cosas que se pueden encontrar en la extracción de cadenas son sorprendentes. Debemos
prestarle mucha atención a esta etapa.
Andrés Olaya - @_4Sec_
En este punto sabemos que es necesario obtener pruebas más contundentes, para ello voy a
utilizar bulk_extractor, con la finalidad de escarbar el contenido de las paginas asociadas al
PID 5856:
Buscamos el fichero .pcap para realizar una valoración que nos permita obtener cualquier
información que permita evidenciar un canal de comunicación entre el PID 5656 y IP
186.145.214.199:
Como se puede apreciar, el PID 5856 llevo a cabo una resolución DNS para la IP
186:145:214:199; como también tráfico TCP entre ambos nodos:
Andrés Olaya - @_4Sec_
Ahora sabemos a ciencia cierta que:
✔ Existió un canal de comunicación entre la máquina sospechosa y la dirección IP
186.145.214.199 por el puerto 3040, establecido desde el proceso MSBuild.exe identificado
con el PID 5856.
✔ A través del PID 5856 se llevo a cabo una consulta de DNS, la cual obtuvo el dominio
willyrex2020.publicvm.com
Es momento de hacer inteligencia, vamos a consultar fuentes abiertas con la finalidad de hacer
un reconocimiento sobre el IOC willyrex2020.publicvm.com:
Andrés Olaya - @_4Sec_
¿Qué tenemos hasta ahora?
• Sabemos a ciencia cierta que la IP 186.145.214.199 y el dominio willyrex2020.publicvm.com
están asociados a puntos hostiles de comando y control (C2).
• Tenemos un IOC importante “Circular y Notificacion UGPP Aviso Virtual” podría ser el
detonador.
Debo mencionar la importancia de ir enumerando progresiva y ordenadamente los IOC's que
vamos encontrando para construir consultas más precisas.
Andrés Olaya - @_4Sec_
Es el momento de analizar los objetos asociados al PID 5856, recordemos que esta relacionado
con dialer.exe:
Para tener más probabilidades de éxito en la construcción del escenario, voy a reducir la
consulta a objetos de tipo “File”:
Sería conveniente extraer el objeto, lo que podríamos hacer sería buscar el objeto en todo el
volcado, esto lo podemos hacer de la siguiente manera:
Ahora debemos volcar el objeto:
Andrés Olaya - @_4Sec_
Procedemos a identificar e individualizar los ficheros extraídos del volcado:
md5: a040ef95090aa623a298443b203621a3 file.None.0xfffffa80047da5c0.dat
md5: 19464d752af4a9279024191baf746034 file.None.0xfffffa800497e010.img
Es el momento de consultar los motores de detección más conocidos del mercado, así es VT
(Virustotal), basta con realizar la consulta por medio del hash de cada archivo:
Andrés Olaya - @_4Sec_
Para el segundo hash el ratio es de 9 de 62, nada mal:
Andrés Olaya - @_4Sec_
Es el momento de buscar artefactos de persistencia, los cuales podrían estar en cualquier
lugar…
Los adversarios a menudo crean archivos de trabajo utilizando at.exe para ejecutar malware de
manera automatizada, por lo que buscar ficheros .job puede ser una buena idea. No sobra decir
decir que en Windows, los archivos .job especifican la configuración de una tarea programada.
Procedemos con la búsqueda:
El resultado de la consulta es más que alentador, corrobora que existe una tarea programada
para dialer.exe, la cual se llama “dialer.job”
Extraemos el objeto del volcado:
Andrés Olaya - @_4Sec_
Con ayuda del script jobparser.py de Jamie Levy, que lo pueden descargar de aquí: jobparser.py
Voy a extraer la información de configuración de la tarea:
Hasta el momento sólo hemos encontrado un artefacto de persistencia; sin embargo, es muy
probable que no sea el único, lo que haremos ahora será buscar objetos de tipo “archivo” que
estén vinculados con la cadena "startup":
Se trata de un artefacto del tipo lnk (acceso directo) que se encuentra en el la ruta
C:\Users\Ferreteria1\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\
dilaer.lnk . Lo cual le permite iniciar automáticamente cada vez que se inicia el sistema.
Es el momento de buscar el artefacto detonador, para ello nos remontaremos a:
El nombre nos puede servir para construir nuestras consultas “Circular y Notificacion UGPP
Virtual”. No necesariamente tiene que tener el mismo nombre ¡Ojo!
Andrés Olaya - @_4Sec_
Después de un par de consultas infructuosas, optamos por cambiar de rumbo y centrar la
mirada en el volcado del PID 5856:
Ahora sabemos que en el escritorio del Usuario Ferreteria1, se encontraba el detonador:
C:\Users\Ferreteria1\Desktop\Circular informacion sensible (protegida) UGPP.pdf\Circular
informacion sensible (protegida) UGPP.pdf
A partir de los hallazgos obtenidos durante el análisis llevado a cabo hasta este momento,
podemos afirmar que las evidencias demuestran técnicamente que:
1. El equipo estaba comprometido por un malware de administración remota.
2. Al momento de realizar el volcado por parte del equipo de IT, había un canal de
comunicación establecido entre el C2 y el equipo víctima.
3. El proceso por medio del cual el malware estaba interactuando con el sistema víctima era
el identificado con el PID 5856 (MSBuild.exe).
4. La dirección IP del canal de comunicación de comando y control (C2) era 186.145.214.199
por el puerto 3040, asociada al dominio willyrex2020.publicvm.com
5. Los delincuentes tuvieron acceso al equipo víctima hasta el momento en que el equipo de
IT procedió a realizar el volcado de memoria a las 19:27:54 UTC -5.
6. Los mecanismo que el malware utilizaba para persistir en el sistema son:
✔ La ejecución de una tarea programada llamada “dialer.job”, la cual ejecutaba el archivo
malicioso dialer.exe, que se encontraba en el Contenedor de datos de aplicaciones
AppData, en la carpeta de sincronización de usuario Roaming, dentro de una carpeta
que suplantaba un lector de archivos pdf “Foxit Reader”. La ruta exacta: C:\Users\
Ferreteria1\AppData\Roaming\Foxit Software\Foxit Reader\dialer.exe
✔ Artefacto del tipo lnk (acceso directo) que se encuentra en el la ruta C:\Users\
Ferreteria1\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\
dialer.lnk . Lo cual le permite iniciar automáticamente cada vez que se inicia el sistema.
7. El artefacto detonador se encontraba en el escritorio del usuario Ferreteria1, “Circular
informacion sensible (protegida) UGPP.pdf”
Andrés Olaya - @_4Sec_
Andrés Olaya - @_4Sec_
