Esta publicación de blog fue escrita por Hasherezade y Jérôme Segura

Emotet ha sido el malware más buscado durante varios años. La gran botnet es responsable de enviar millones de correos electrónicos no deseados con archivos adjuntos maliciosos. El troyano bancario que una vez se convirtió en cargador fue responsable de costosos compromisos debido a su relación con bandas de ransomware.

El 27 de enero, Europol anunció una operación global para acabar con la botnet detrás de lo que llamó el malware más peligroso al obtener el control de su infraestructura y eliminarlo desde adentro.

Poco después, los controladores Emotet comenzaron a entregar una carga útil especial que tenía un código para eliminar el malware de las computadoras infectadas. Esto aún no se había aclarado formalmente y algunos detalles al respecto no estaban del todo claros. En este blog revisaremos esta actualización y cómo debe funcionar.

Descubrimiento

Poco después de la eliminación de Emotet, un investigador observó una nueva carga útil enviada a las máquinas infectadas con un código para eliminar el malware en una fecha específica.

Ese bot actualizado contenía una rutina de limpieza responsable de desinstalar Emotet después de la fecha límite del 25 de abril de 2021 . El informe original mencionaba el 25 de marzo, pero como los meses se cuentan desde 0 y no desde 1, el tercer mes es en realidad abril.

Esta actualización especial fue confirmada posteriormente en un comunicado de prensa del Departamento de Justicia de EE. UU. En su declaración jurada .

El 26 de enero de 2021 o alrededor de esa fecha, aprovechando su acceso a los servidores de Nivel 2 y Nivel 3, los agentes de un socio de cumplimiento de la ley extranjero de confianza, con quien el FBI está colaborando, reemplazaron el malware Emotet en servidores ubicados físicamente en su jurisdicción con un archivo creado por cumplimiento de la ley

BleepingComputer menciona que el socio extranjero encargado de hacer cumplir la ley es la Policía Criminal Federal de Alemania (Bundeskriminalamt o BKA).

Además de la rutina de limpieza, que describimos en la siguiente sección, este «archivo de aplicación de la ley» contiene una ruta de ejecución alternativa que se sigue si la misma muestra se ejecuta antes de la fecha indicada.

El desinstalador

La carga útil es una DLL de 32 bits. Tiene un nombre que se explica por sí mismo (EmotetLoader.dll) y 3 exportaciones que conducen a la misma función.

Si miramos dentro de esta función exportada, podemos ver 3 subrutinas:

El primero se encarga de la limpieza antes mencionada. En el interior, podemos encontrar el control de fecha:

Si la fecha límite ya pasó, la rutina de desinstalación se llama inmediatamente. De lo contrario, el hilo se ejecuta repetidamente haciendo la misma verificación de tiempo y, finalmente, llamando al código de eliminación si la fecha ha pasado.

La hora actual se compara con la fecha límite en un bucle. El ciclo sale solo si se supera la fecha límite y luego continúa con la rutina de desinstalación.

La rutina de desinstalación en sí es muy simple. Elimina el servicio asociado con Emotet, elimina la clave de ejecución, intenta (pero falla) mover el archivo a% temp% y luego sale del proceso.

Dentro de la función: «uninstall_emotet»

Como sabemos al observar el Emotet regular, logra la persistencia de dos formas alternativas.

Ejecutar clave

Microsoft \ CurrentVersion \ Run

Este tipo de instalación no requiere elevación. En tal caso, la DLL de Emotet se copia en %APPDATA%\[random dir name]\[random DLL name].[random extention].

Servicio del sistema

HKLM \ System \ CurrentControlSet \ Service \ <nombre aleatorio de emotet>

Si la muestra se ejecutó con privilegios de administrador, se instala como un servicio del sistema. Se copia la DLL original en C:\Windows\SysWow64\[random dir name]\[random DLL name].[random extention].

Por esta razón, la función de limpieza debe tener en cuenta ambos escenarios.

Notamos que los desarrolladores cometieron un error en el código que se supone debe mover el archivo de aplicación de la ley al directorio% temp%:

GetTempFileNameW (Buffer, L "UPD", 0, TempFileName) 

El «0» debería haber sido un «1» porque según la documentación , si uUnique no es cero, debe crear el archivo usted mismo. Solo se crea un nombre de archivo, porque GetTempFileName no puede garantizar que el nombre de archivo sea único .

La intención era generar una ruta temporal, pero debido a que se usó un valor incorrecto en el parámetro uUnique, no solo se generó la ruta, sino que también se creó el archivo. Eso llevó a una mayor colisión de nombres y, como resultado, el archivo no se movió.

Sin embargo, esto no cambia el hecho de que el malware ha sido neutralizado y es inofensivo, ya que no se ejecutará ya que se eliminaron sus mecanismos de persistencia.

Si la rutina de eliminación antes mencionada se llamó inmediatamente, las otras dos funciones de la exportación inicial no se están ejecutando (el proceso termina al final de la rutina, llamando ExitProcess). Pero esto ocurre solo si la muestra se ha realizado después del 25 de abril.

La ruta de ejecución alternativa

Ahora echemos un vistazo a lo que sucede en el escenario alternativo cuando no se llama inmediatamente a la rutina de desinstalación.

Una vez que se ejecuta el hilo en espera, la ejecución llega a otras dos funciones. El primero enumera los procesos en ejecución y busca el proceso padre del actual.

Luego verifica el nombre del proceso si es «explorer.exe» o «services.exe», seguido de los parámetros de lectura que se le dan al padre.

Ejecutando la siguiente etapa

La siguiente rutina descifra y carga una carga útil de segunda etapa desde el búfer codificado.

El búfer codificado se descifra con el bucle anterior y luego se ejecuta

Redirección del flujo al búfer descifrado (a través de » call edi«):

Se revela el siguiente PE: X.dll :

Después de descifrar la carga útil, la ejecución se redirige al comienzo del búfer revelado que comienza con un salto:

Este salto conduce a una rutina de cargador reflectante. Después de asignar la DLL a un formato virtual, en el área recién asignada en la memoria, el cargador redirige la ejecución allí.

Primero, DllMainse llama al de X.dll (se usa solo para la inicialización). Luego, la ejecución se redirige a una de las funciones exportadas, en el caso actualmente analizado Control_RunDll.

La ejecución continúa con el segundo dll (X.dll). Las funciones dentro de este módulo están ofuscadas.

La carga útil que se llama ahora es muy similar a la carga útil normal de Emotet. Analógico DLL, y también nombrado X.dll tales como: esta uno se pudo encontrar en muestras Emotet anteriores (sin la rutina de limpieza), por ejemplo en esta muestra .

La carga útil de la segunda etapa: X.dll

La carga útil de la segunda etapa X.dll es una DLL de Emotet típica, cargada en caso de que la fecha límite codificada no haya pasado todavía.

Esta DLL está muy ofuscada y todas las API utilizadas se cargan dinámicamente. Además, sus parámetros no son legibles: se calculan dinámicamente antes de su uso, a veces con la ayuda de una larga cadena de operaciones que involucran muchas variables:

Este tipo de ofuscación es típico de las cargas útiles de Emotet y está diseñado para confundir a los investigadores. Sin embargo, gracias al rastreo pudimos reconstruir qué API se llaman con qué compensaciones.

La carga útil tiene dos rutas alternativas de ejecución. Primero verifica si ya estaba instalado. De lo contrario, sigue la primera ruta de ejecución y procede a instalarse. Genera un nombre de instalación aleatorio y se mueve a sí mismo bajo este nombre a un directorio específico, al mismo tiempo que agrega persistencia. Luego, vuelve a ejecutarse desde la nueva ubicación.

Si la carga útil detecta que se ejecutó desde la ruta de destino, toma una ruta de ejecución alternativa . Se conecta al C2 y se comunica con él.

La muestra actual envía una solicitud a uno de los servidores sumideros. Contenido:

L "DNT: 0 \ r \ nReferer: 80.158.3.161/i8funy5rv04bwu1a/\r\nContent-Type: multipart / form-data; límite = ------------------- -GgmgQLhRJIOZRUuEhSKo \ r \ n "

La siguiente imagen muestra el tráfico web de un sistema infectado a través de un documento malicioso que descarga el archivo de actualización especial y vuelve al servidor de comando y control propiedad de la policía:

Motivos detrás del desinstalador

La versión con el desinstalador ahora se envía a través de canales destinados a distribuir el Emotet original. Aunque actualmente la rutina de eliminación aún no se llamará, la infraestructura detrás de Emotet ya está controlada por la policía, por lo que los bots no pueden realizar su acción maliciosa.

Para las víctimas con una infección Emotet existente, la nueva versión vendrá como una actualización, reemplazando a la anterior. Así será como conocerá sus rutas de instalación y podrá limpiarse una vez transcurrido el plazo.

Insertar código a través de una botnet, incluso con buenas intenciones, siempre ha sido un tema espinoso, principalmente debido a las ramificaciones legales que implican tales acciones. La declaración jurada del Departamento de Justicia señala cómo los «agentes de la ley extranjeros, no agentes del FBI, reemplazaron el malware Emotet, que se almacena en un servidor ubicado en el extranjero, con el archivo creado por la policía».

El retraso prolongado para que se active la rutina de limpieza puede explicarse por la necesidad de dar tiempo a los administradores del sistema para realizar análisis forenses y verificar otras infecciones.