synawk

Hace unos días un amigo me entregó una muestra de un malware para analizar; se trataba de WannaMine; una variante del ya conocido e infame malware WannaCry. El vector de infección es desconocido; sin embargo como como ya común en este tipo de variantes del malware, es probable que haya iniciado por algún troyano malicioso o algún script en powershell embebido. Voy a tratar de ser breve ya que se trata de una muestra similar a WannaCry y pues ya hay muchos reportes de esa variante de malware.

Se sabe que hace un drop de ciertos archivos e inicia la ejecución de mssecsvr.exe. Cuando el malware inicia lo primero que hace es hacer una resolución de DNS de un dominio; básicamente para validar su existencia; como lo hacen todas las variantes de WannaCry.

Si el dominio no existe continúa con el flujo; caso contrario si el dominio existe, el malware se detiene. Lo que sigue es una técnica bastante común y se resume en 3 pasos:

1. Verificar si el programa esta recibiendo argumentos; es decir si esta siendo ejecutado como servicio; una forma “económica” de hacerlo es validar la cantidad de argumento como mencioné. Por ejemplo, ejecutar mssecsvr.exe directamente tiene 0 args (sin contar el filename), que es diferente a mssecsvr.exe -s arg
2. Si trae argumento (o es un servicio) continuar con el flujo; por otro lado si no trae argumentos(no es servicio); ir a createServiceAndExit
3. Este paso ya lo puedes inferir; va crea un servicio, lo ejecuta y cierra el proceso actual. De este modo ya tienes una nueva instancia del malware pero como servicio; este flujo se suele usar también cuando se utilizan técnicas de bypass avanzadas.

Puedes revisar el detalle de las funciones en la documentación oficial de microsoft:

https://docs.microsoft.com/en-us/windows/win32/api/winsvc/

El flujo en una primera instancia entra a createServiceAndExit; y cuando ya es servicio sigue hasta serviceFlowWnry. En la siguiente imagen puede verse que cuando crea el servicio lo hace con los argumentos -m security que sirve para validar si efectivamente es un servicio o no.

Cuando crea el servicio lo hace con la siguiente información; y más abajo puedes ver las propiedades del servicio creado por el malware.

Hasta el momento el malware no ha hecho nada nuevo; de hecho nunca hace nada nuevo (jeje); pero hace algo interesante que ya mencioné en otras publicaciones sobre bypass sencillos. Una de las técnicas más usadas y comunes es la de usar GetProcAddress para “desaparecer” el IAT; la técnica es tan antigua que algunos EDR/AV ya las detectan, es por eso que muchas veces no basta con usar el GetProcAddress; si no además ofuscar las entradas; bueno en este caso no lo hace pero sería “recomendable”.

Para que se entienda mejor, aquí te va un ejemplo rápido:

HMODULE lib = LoadLibrary("kernel32.dll");
C_CreateProcess cCreateProcess = (C_CreateProcess)GetProcAddress(lib, "CreateProcessA");

//Entonces revisas la definición de esa función en la documentación 
// para poder hacer el typedef
//https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa

Lo que pasa a continuación es también una técnica bastante común que a día de hoy se sigue utilizando. Voy a explicar brevemente el flujo que sigue.

1. Cuando revisamos las secciones del malware encontramos las típica secciones y además el .rsrc; que es el que almacenas los “resources” que va a usar el pefile. Puedes leer más aquí: https://docs.microsoft.com/en-us/previous-versions/ms809762(v=msdn.10)?redirectedfrom=MSDN

   

2. Si revisamos este malware, se puede ver que dentro de esta sección hay lo que parece ser un pefile; esto lo sé por el magic number de todo pefile (4D 5A)

   

3. Ya con esto sabes que se trama el malware; pues sí; soltarte otro malware para que realice otra operación; se trata de un dropper.

4. Con el uso de funciones que me hagan acceder a este “resource” puedo almacenar este pefile nuevo en una ubicación diferente. Y es precisamente lo que esto pasa.

   

El archivo es creado en C:\windows con el nombre tasksche.exe y luego es iniciado con CreateProcessA; ya anteriormente visto en algunas variantes de WannaCry. Adicionalmente, si el malware encuentra ya un archivo con ese nombre primero lo copia renombrándolo a qeriuwjhrf y posteriormente crea de nuevo el archivo tasksche.exe.

Este archivo generado es el que se encarga de encriptar los datos del ordenador; sin embargo para este caso del WannaMine; no lo hace porque su función principal no es esa. No voy a incluir la encriptación dentro de este análisis ya que me enfocaré en la tarea por la que fue diseñada que es la minería. En internet ya hay mucho material acerca del ransomware.

Hasta aquí termina el primer paso del WannaMine ya que luego que termina de escribir el pefile termina el proceso. Crea un servicio y “droppea” un malware en la carpeta Windows y con esto ya gana la persistencia en el equipo. Aquí me voy a detener un momento para revisar que más hace el archivo generado tasksche.exe a parte de la encriptación.

Si revisamos el nuevo archivo creado vemos, que al empezar usa la misma técnica que su “padre”; valida la cantidad de argumentos, crea un directorio donde alojar el malware y finalmente crear un servicio. Al terminar el proceso actual; el malware dropeado se ejecuta con CreateProcessA la copia de este malware pero esta vez como servicio. Me voy a saltar esta parte porque funciona casi igual que la ya mencionada líneas arriba.

Supongamos que el malware ya esta como servicio para saltar esta parte; y pasa la condición de los argumentos. Lo primero que hace es crear un registro en 2 ubicaciones y posteriormente desempaqueta algo.

Para la creación de registros utiliza 2 ubicaciones y de la forma tradicional. Lo almacena en HKEY_CURRENT_USER\Software\WanaCrypt0r y HKEY_LOCAL_MACHINE\Software\WanaCrypt0r con el valor wd

Para el desempaquetado si hace algo adicional a como lo hizo en la primera vez; le pasa una clave. Muy probablemente el recurso este ofuscado y necesita la clave para leerlo.

Si revisamos los resources del malware vemos que se trata de algo que parece un zip. Esto se sabe gracias a las cabeceras que tiene.

Aquí pasó algo curioso; el payload que previamente droppeo no logró abrir este resource; revisando el código que lo extrae me di cuenta de un “error” o algún fix para que no encripte los archivos. La razón por la que no llega a encriptar es la siguiente validación:

Si te fijas bien la validación espera una secuencia como esta: 50 4B 05 06 sin embargo el resource tiene una secuencia de 50 4B 03 04. Entonces como no coinciden ambas secuencias no pasa la validación. (Puedes revisar aquí https://www.garykessler.net/library/file_sigs.html estos magic numbers). El proceso se detiene ahí dado que los eran necesarios para la encriptación; quizá es un fix para enviar encriptar los archivos o quizá fue un error, la verdad no lo sé. Si lo extraemos manualmente tenemos algo como esto:

Hasta ahora todo ha sido visto ya anteriormente en muchas publicaciones de WannaCry. Ahora, uno de los archivos adicionales que dropea el malware de la infección es el dllhost.exe, el cual es el que se encarga de la minería.

Lo primero que se puede notar en el malware es que es se trata de Xmrig, un software para realizar minería; es una versión modificada del código original de la versión 5.1.0 https://github.com/xmrig/xmrig/releases/tag/v5.1.0

Una de las cosas mas importantes que hace a diferencia del software original, es definir por defecto los argumentos para apuntar a la web rim.miniast.com. No hay mucho mas que decir de este archivo dado que incluso está documentado https://xmrig.com/docs/miner. Este es el string que genera como argumento:

Funciones adicionales

No lo mencioné dentro del análisis; pero como en toda variante de WannaCry, este malware explota la vulnerabilidad EternalBlue desde el archivo mssecsvr.exe. A través de fuerza bruta consulta por todas las IP obtenidas a través de mi interface por el puerto 445

Hay un archivo extra que esta incluido dentro del drop inicial que no incluí ya que hay bastantes análisis de este en internet, spoolsv.exe. Entre otras cosas, su trabajo es generar persistencia de un servicio DLL; haciendo que cada vez que reinicies la PC, te vuelvas a “infectar”. Estas DLL salen de un desempaquetado de un Type Library; no lo considero relevante para el enfoque de este análisis. Lo que si me parece genial es la forma de persistencia que usa el malware. Luego haré una publicación sobre persistencia donde incluiré este mecanismo.

Conclusiones

He omitido muchas funcionalidades del malware; porque solo quería enfocarme en las técnicas que me parecen mas relevantes y que se pueden aprender algo de estas. Haciendo un recuento:

1. No lo puse arriba; pero el malware usa una lógica bastante común que es copiarse a el mismo en una ubicación del ordenador. Este punto es importante ya que puedes seguir el flujo desde una carpeta “aislada” como TEMP o AppData.
2. Crear servicios. Si estas acostumbrado a usar tools será más complicado para ti tomar esto en cuenta (o si la tool lo permite). La creación y validación del servicio debe estar automatizada; además de contar con una lógica de validación de privilegios.
3. El uso de argumentos como modificador de flujo ha sido usado en malwares desde hace años; sigue siendo una opción “económica”.
4. Usa LoadLibrary y GetProcAddress como en este caso; quizá ofuscando las entradas para evitar leer los strings estaría genial.
5. Puedes usar otras secciones; como .rsrc o .data para luego extraerlo. Evitar usar nombre extraños o largos; suelen ser reconocidos en el análisis estático.
6. Si vas a ofuscar algo, evalúa si es realmente necesario. La entropía puede aumentar la probabilidad de detección.

Si quieres aprender a hacer un malware de 0 tu mejor opción es empezar a analizar malware; te dará una perspectiva mayor sobre las técnicas que se usan y el porqué de su uso. Existen muchas más técnicas y formas de programar un malware; como elevar privilegios, como hacer un dropper o un downloader; y espero que en el transcurso de estos análisis tenga la oportunidad de explicar todas estas.