Análisis campaña Emotet

El post de hoy viene de la mano del CSIRT-CV, el Centro de Seguridad TIC de la Comunitat Valenciana. Nacido en junio del año 2007, como una apuesta de la Generalitat Valenciana por la seguridad en la red, fue una iniciativa pionera al ser el primer centro de estas características que se creó en España para un ámbito autonómico.

A pesar de tratarse de un malware que se comenzó a identificar en 2014, Emotet todavía sigue siendo una de las amenazas más activas hasta la fecha, evolucionado desde las versiones iniciales, en las que se centraba en el robo de credenciales bancarias, hasta la actualidad, dónde se ha ampliado el arsenal de técnicas entre las que se encuentran sniffing de tráfico de red, explotación de vulnerabilidades para conseguir movimiento lateral, etc.

Indicar que EMOTET fue interrumpido la última semana de Enero de 2021 mediante una acción global entre autoridades de los Países Bajos, Alemania, Estados Unidos, Reino Unido, Francia, Lituania, Canadá y Ucrania, con una actividad internacional coordinada por Europol y Eurojust. Esta acción permitió que los investigadores tomaran el control de su infraestructura.

Durante estos 6 años hemos visto cómo nuevas campañas de Emotet aparecían durante unas semanas, y una vez las muestras y los ficheros maliciosos utilizados ya eran bloqueados por las principales casas de Antivirus se detenían unos días hasta las siguiente oleada.

En CSIRT-CV hemos recibido varias de estas campañas, las cuales hemos tratado de analizar y remediar en nuestros sistemas. Vamos a detallar algunos aspectos importantes de este malware, que aunque desactivado, puede enseñarnos muchas cosas de las amenazas que vengan en el futuro.

La principal forma de distribución de Emotet es mediante correos electrónicos con adjuntos maliciosos de tipo ofimático (excel, documentos word, etc). Durante el mes de septiembre se detectó la misma muestra en varios buzones de Generalitat, con el siguiente fichero word adjunto:

Mensaje de Word para habilitar contenido

El fichero adjunto con nombre “archivo_2020.doc” contenía unas macros instaladas que se intentaban ejecutar una vez abierto el documento:

Macros ofuscadas del documento

Como vemos, el script está ofuscado, de forma que complica en gran medida analizar qué acciones realiza a simple vista. Sin embargo, podemos habilitar la ejecución de macros en Word y analizar qué operaciones lleva a cabo en el equipo que infecta.

Si analizamos los procesos que se ejecutan una vez se permiten ejecutar las macros del documento, se observa que se hace uso de WMI para ejecutar un script en Powershell codificado en base64 con el parámetro -e:

Captura de process monitor

Aunque este script está también ofuscado, el nivel de ofuscación es mucho más reducido, pudiendo obtener el código inicial manualmente sin mucho esfuerzo:

Powershell ejecutado decodificado

Vemos cómo se intenta descargar varios ficheros ejecutables de las URL de la línea 19, y tratará de ejecutar los ficheros con tamaño mayor de 32254 bytes.

En el momento del análisis sólo 4 de las 7 URL respondían con un binario ejecutable:

md5Nombre del ejecutable
6ec0a030d55de2fe1b75126f0f65e5c08i449cW.exe
adcf7a7aa104d608331ce2f72c733b47iNZFe.exe
d02dd7873d4bbe7465e747b17bb3505cnvU.exe
806ba160ea7d2126123cbfd5bfabdbb7u47D2mVFE5.exe

A pesar de tener diferentes hashes, el tamaño, secciones y imports son iguales, lo que hace pensar que se trata de un único binario, con modificaciones mínimas para evitar ser bloqueado rápidamente una vez se detecta la primera muestra.

Por esta razón, vamos a analizar sólo uno de ellos, ya que la lógica es la misma para todos ellos.

Fichero malicioso creado en el sistema
Directorio de la persistencia

De lo primero que nos damos cuenta al ejecutar el binario es que se borra de la carpeta temporal en la que se descarga desde el Powershell, se almacena en %APPDATA% en una carpeta con un nombre aleatorio, y el ejecutable es renombrado con otro nombre generado aleatoriamente (pero legible, no es random).

También se observa que después de unos segundos de ejecución se comienzan a realizar peticiones POST contra diferentes direcciones IP con contenido cifrado.

Peticiones del programa malicioso

En este punto nos interesa conocer qué información va en el contenido cifrado de las peticiones POST y cuál es el listado de direcciones a las que el programa se conecta.

Si hacemos un análisis estático no encontraremos API importadas de red con las que realizar las peticiones que hemos capturado. Podemos ejecutar el programa analizando las llamadas a API que realiza, para obtener algo más de información.

Captura de llamadas al sistema
Captura de llamadas al sistema

Unas de las primeras llamadas que vemos que se realizan a las API de Windows es VirtualAllocEx (la cual no aparece en el listado de imports del ejecutable). Esta es utilizada por malware principalmente para reservar memoria y cargar en esta sección módulos que en un principio estaban cifrados en el ejecutable, que se han descifrado y se intentan cargar para su ejecución.

En la siguiente imagen vemos llamadas a funciones cómo InternetConnectW o HttpOpenRequestW desde un offset (0x1d2299 y 0x1d2204) diferente al del programa inicial (0x42xxxx). Esta sección ha sido cargada posiblemente usando la función VirtualAllocEx mencionada, y se ha marcado esa sección de memoria cómo ejecutable (RX), como vemos en la siguiente imagen:

Espacios de memoria en el proceso malicioso

Esto significa que en esa dirección se ha cargado nuevo código ejecutable y se ha pasado el hilo de ejecución a esa parte de memoria. Al extraer esa sección comprobamos que se trata de un ejecutable cargado durante la ejecución del programa principal, aunque con modificaciones en las cabeceras del PE para complicar el análisis del programa.

Sección de código ejecutable

Mientras el programa ejecuta la nueva sección cargada en memoria, se comienzan a realizar peticiones POST repetitivas con contenido cifrado hacia varios servidores. Puede ser interesante analizar el programa para investigar qué información está extrayendo del equipo para enviar al servidor de control y comando (C&C desde este punto).

Justo después del VirtualAllocEx, la primera llamada a API que se realiza es a CreateToolHelp32Snapshot, lo que puede significar que se obtiene alguna información de los procesos que se están ejecutando en el equipo.

Detenemos la ejecución del programa en la llamada a CreateToolHelp32Snapshot para ver cómo se extrae la información de los procesos:

Extracción de listado de procesos en x32dbg

En la captura vemos cómo se hacen llamadas a funciones para recorrer los procesos que están en el equipo, uno a uno. Mientras se recorren estos procesos, el programa almacena sus nombres y a continuación comienza a realizar llamadas a la DLL rsaenh.dll, un módulo de windows que ofrece servicios criptográficos.

Si analizamos las llamadas a esta DLL vemos que se utiliza para cifrar la información que se envía en la petición POST. Entre la información que se cifra se encuentra el listado de procesos del equipo, nombre del equipo, etc.

Llamada a rutina de cifrado

Esta funcionalidad ya se ha visto en anteriores versiones de Emotet, donde la lógica de la aplicación responsable de detectar si se encuentra en un entorno controlado o en un equipo “real” se realiza en un servidor remoto, de forma que se dificulta el trabajo del analista al no poder ejecutar el programa completo o conseguir los siguientes módulos de la amenaza.

Llegados a este punto de la ejecución, nos quedaría obtener el listado de servidores C&C con los que el programa intentará contactar. Esta información la podemos extraer de la sección cargada dinámicamente en un formato que Emotet lleva utilizando en varias campañas:

Espacio de memoria con direcciones de Command and Control

Indicadores de compromiso

Fichero malicioso original:

e4f06c03f11cef25f506ea965337dc80af40d1ef95e8a4ab960d0e2810465ff5archivo_2020.doc

Ficheros dropeados maliciosos:

6ec0a030d55de2fe1b75126f0f65e5c08i449cW.exe
adcf7a7aa104d608331ce2f72c733b47iNZFe.exe
d02dd7873d4bbe7465e747b17bb3505cnvU.exe
806ba160ea7d2126123cbfd5bfabdbb7u47D2mVFE5.exe

Direcciones IP contactadas:

50.121.220.50:80114.109.179.60:8045.161.242.102:8050.28.51.143:8080
51.75.33.122:8058.171.153.81:8077.238.212.227:8024.135.1.177:80
54.37.42.48:8080174.100.27.229:80177.72.13.80:80177.73.0.98:443
91.121.54.71:8080104.131.103.37:808065.36.62.20:80188.2.217.94:80
45.16.226.117:44368.183.190.199:8080190.2.31.172:80170.81.48.2:80
68.69.155.181:80181.30.61.163:443212.71.237.140:8080186.103.141.250:443
213.60.96.117:80184.66.18.83:8064.201.88.132:80188.135.15.49:80
77.55.211.77:808087.106.46.107:808091.219.169.180:80185.94.252.27:443
152.169.22.67:8082.76.111.249:443212.174.55.22:44372.47.248.48:7080
110.142.219.51:80192.241.146.84:808095.9.180.128:80177.74.228.34:80
2.47.112.152:8073.213.208.163:8072.135.200.124:80216.10.40.16:80
206.15.68.237:443104.131.41.185:8080178.250.54.208:8080103.106.236.83:8080
217.13.106.14:8080181.129.96.162:8080187.162.248.237:80217.199.160.224:7080
191.99.160.58:8082.196.15.205:8080178.79.163.131:8080190.190.148.27:8080
189.131.57.131:80186.70.127.199:809077.90.136.129:808012.162.84.2:8080
213.197.182.158:808068.183.170.114:808070.32.84.74:808085.109.159.61:443
94.176.234.118:443111.67.12.221:808098.13.75.196:8085.105.140.135:443
61.92.159.208:8080172.104.169.32:8080190.6.193.152:8080204.225.249.100:7080
190.128.173.10:80219.92.13.25:80192.241.143.52:808067.247.242.247:80
219.92.8.17:808045.33.77.42:808083.169.21.32:7080191.182.6.118:80
190.115.18.139:8080185.94.252.12:80138.97.60.141:7080189.2.177.210:443
190.147.137.153:44346.28.111.142:7080137.74.106.111:7080178.148.55.236:8080
5.196.35.138:708051.255.165.160:8080209.236.123.42:808072.167.223.217:8080
190.163.31.26:8045.173.88.33:80199.203.62.165:8071.197.211.156:80
70.32.115.157:8080190.24.243.186:8051.159.23.217:443190.195.129.227:8090