Evilnum: análisis de las herramientas que utiliza este grupo que apunta a las fintech

ESET analizó las operaciones de Evilnum, el grupo APT detrás del malware Evilnum, el cual se ha visto previamente en ataques contra compañías de tecnología financiera. Si bien se ha mencionado que el malware ha estado activo desde al menos 2018 y fue documentado anteriormente, es poco lo que se ha publicado sobre el grupo detrás de este malware y cómo funciona.

En este artículo establecemos algunas conexiones y brindamos un panorama más detallado de las actividades de Evilnum. Sus objetivos siguen siendo compañías fintech, pero su conjunto de herramientas e infraestructura evolucionaron y ahora está compuesto por malware personalizado desarrollado por el propio grupo combinado con herramientas compradas a Golden Chickens, un proveedor de Malware-as-a-Service (MaaS) cuyos infames clientes incluyen a FIN6 y al grupo Cobalt.

Blancos de ataque de Evilnum

Según datos aportados por la telemetría de ESET, los objetivos de Evilnum son compañías de tecnología financiera; por ejemplo, compañías que ofrecen plataformas y herramientas para realizar trading en línea. Si bien la mayoría de los objetivos de este grupo se encuentran en países de la UE y el Reino Unido, también hemos visto ataques en países como Australia y Canadá. Por lo general, las empresas a las que apunta tienen oficinas en varios lugares, lo que probablemente explica la diversidad geográfica de los ataques.

El objetivo principal del grupo Evilnum es espiar a sus objetivos y obtener información financiera tanto de las empresas a las que apunta como de sus clientes. Algunos ejemplos del tipo de información que este grupo roba son:

• Hojas de cálculo y documentos con listas de clientes, inversiones y operaciones de trading.
• Presentaciones internas
• Licencias de software y credenciales para software/plataformas de trading
• Cookies e información de sesión de navegadores
• Credenciales de correo electrónico
• Información de la tarjeta de crédito del cliente y comprobantes de documentos de domicilio/ identidad

Según lo que hemos visto durante nuestra investigación, el grupo también obtuvo acceso a información relacionada con el área de TI, como son las configuraciones de VPN.

Resumen del ataque

Los objetivos de Evilnum son alcanzados mediante correos electrónicos de spearphishing que contienen un enlace a un archivo ZIP alojado en Google Drive. Ese archivo contiene varios archivos LNK (también conocido como acceso directo) que extraen y ejecutan un componente JavaScript malicioso, mientras se muestra un documento utilizado como señuelo. Estos archivos de acceso directo tienen "extensiones dobles" para intentar engañar al usuario y que los abra pensando que son documentos o imágenes benignas (en Windows, las extensiones de archivo para tipos de archivo conocidos están ocultas de forma predeterminada). El contenido de uno de los archivos ZIP se muestra en la Figura 1.

Figura 1. Archivos LNK maliciosos

Una vez que se abre un archivo de acceso directo (no importa cuál, ya que todos hacen lo mismo), busca en los contenidos de su propio archivo líneas con un marcador específico y las escribe en un archivo .js. Luego, este archivo JavaScript malicioso es ejecutado y, además de abrir, escribe un archivo señuelo con el mismo nombre que el acceso directo, pero con la extensión correcta. También elimina el archivo de acceso directo. Los documentos utilizados como señuelo son principalmente fotos de tarjetas de crédito, documentos de identidad o facturas con comprobante de domicilio, ya que muchas instituciones financieras requieren estos documentos de sus clientes cuando se unen. Uno de esos documentos utilizados como señuelo puede observarse en la Figura 2 (difuminado por cuestiones de privacidad).

Figura 2. Foto del dorso de una tarjeta de identificación utilizada como señuelo

Estos documentos utilizados como señuelo parecen genuinos, y asumimos que han sido recopilados por este grupo durante años de operación. En las operaciones actuales del grupo estos documentos son recopilados de forma activa, ya que apunta a representantes de soporte técnico y gerentes de cuentas, quienes reciben regularmente este tipo de documentos de sus clientes. El grupo reutiliza los documentos en diferentes objetivos, a menos que los objetivos sean de diferentes regiones.

El componente JavaScript es la primera etapa del ataque y puede distribuir otro malware, como un componente espía en C#, componentes de Golden Chickens o varias herramientas basadas en Python. El nombre Evilnum fue dado al componente en C# por otros investigadores en el pasado, pero también se ha hecho referencia como Evilnum al componente en JS. Hemos llamado al grupo Evilnum dado que ese es el nombre de su malware insignia, mientras que nos referiremos a las restantes piezas de malware como componentes. Una visión general de estos se observa en la Figura 3.

Figura 3. Componentes de Evilnum

Cada uno de los diversos componentes tiene su propio servidor C&C, y cada componente funciona de manera independiente. Los operadores del malware envían comandos manualmente para instalar componentes adicionales y usan scripts y herramientas post-compromiso en caso de considerarlo necesario.

La mayoría de los servidores utilizados por el malware están referenciados por la dirección IP, es decir que los nombres de dominio no han sido utilizados. Las únicas excepciones son los servidores C&C utilizados por los componentes de Golden Chickens; malware comprado a un proveedor que ofrece malware como servicio (MaaS, por sus siglas en inglés), tal como describimos más adelante.

En el caso de los servidores referenciados a través de su dirección IP, podemos ponerlos en dos grupos según el proveedor de hosting. La mayoría de ellos están alojados con FreeHost, un proveedor de Ucrania. El resto está alojado en los Países Bajos, con Dotsi.

Componente en JS: primer compromiso

Este componente se comunica con un servidor de C&C y actúa como un backdoor sin la necesidad de ningún programa adicional. Sin embargo, en la mayoría de los ataques que hemos visto, cuando lo consideraron oportuno los atacantes desplegaron componentes adicionales y utilizaron el malware en JS solo como primera etapa.

La primera vez que se hizo mención a este malware en JavaScript fue en mayo de 2018 en este artículo de pwncode. Desde entonces el malware ha cambiado e ilustramos estos cambios en la Figura 4.

Figura 4. Cronología de cambios realizados en el componente en JS

Las diferencias entre la versión 1.3 y las otras son importantes, ya que se modificó el código del lado del servidor para los C&C y los comandos son diferentes. En esa primera versión no era posible cargar archivos a los C&C, sino solo descargar archivos a la computadora de la víctima. Además, a medida que aparecían nuevas versiones, el malware era ampliado con algunos scripts en Python (consulte la sección Conjunto de herramientas post-compromiso) y herramientas externas como ChromeCookiesView.

A pesar de las diferencias, las funcionalidades principales siguen siendo las mismas en todas las versiones, incluida la recuperación de la dirección del servidor C&C desde las páginas de GitHub, GitLab o Reddit creadas específicamente para ese propósito. La Figura 5 muestra un ejemplo de una página de Reddit analizada por el malware para recuperar una dirección de C&C.

Figura 5. Página de Reddit con el servidor C&C para el componente en JS

Este componente logra la persistencia a través de la clave de registro Run y ​​tiene capacidades de backdoor completas: puede descargar y ejecutar archivos binarios, ejecutar comandos de forma arbitraria o cargar archivos desde la computadora de la víctima al servidor de C&C. No entraremos en detalles sobre los aspectos técnicos de este componente, ya que Prevailion publicó recientemente un buen análisis de la última versión del mismo.

Componente en C#

En marzo de 2019, Palo Alto Networks describió un malware con una funcionalidad muy similar al componente en JS, pero codificado en C#. Esa versión (2.5) obtuvo la dirección de sus C&C dividiendo un número entre 666, y fue por eso que los investigadores de Palo Alto Networks la llamaron Evilnum. Desde entonces, surgieron nuevas versiones del malware en C#, la última de ellas es la versión 4.0 que vimos por primera vez en abril de 2020. El número 666 ya no se usa y las rutas PDB de los ejecutables muestra que los desarrolladores llaman a su malware "Marvel". Sin embargo, continuaremos nombrando al malware Evilnum para evitar crear confusión.

La última versión viene empaquetada en un archivo MSI (Windows Installer) y se ejecuta independientemente del componente en JS. Además, tiene diferentes C&C que el componente en JS. Sin embargo, en todos los casos que hemos visto, el componente en C# se descargó y ejecutó después de que el malware en JavaScript obtuviera acceso inicial. La estructura de este componente se observa en la Figura 6.

Figura 6. Partes del componente en C#

Cuando se ejecuta el archivo MSI, tres componentes maliciosos, junto con algunos archivos de la biblioteca del Framework .NET, se escriben en el disco en %LOCALAPPDATA%\Microsoft\Mediia. El copiador de archivos es el primero en ejecutarse y su único propósito es mover los archivos a otra ubicación en %LOCALAPPDATA% (consulte la sección Indicadores de Compromiso para conocer los nombres de las carpetas). Luego, el loader se ejecuta, carga y descifra el contenido del archivo System.Memmory.dll, que es el verdadero payload malicioso (Agente DLL) para el componente en C#. El cifrado AES se usa para la DLL y para la ofuscación de las strings en el payload. La misma clave y vector de inicialización se utilizan para cifrar las strings en todas las diferentes versiones.

La dirección IP del servidor C&C está hardcodeada y en texto plano. Se envía una solicitud GET para /Validate/valsrv y si el cuerpo de la respuesta contiene el texto youwillnotfindthisanywhare, entonces el servidor es aceptado. De lo contrario, se analiza una página de GitLab para obtener la dirección IP de un segundo servidor.

Las siguientes capacidades están presentes en la versión 4.0:

• Toma capturas de pantalla si el mouse ha sido movido en un período de tiempo y las envía, codificadas en base64, al C&C. La imagen es almacenada en un archivo llamado SC4.P7D
• Ejecuta comandos
• Ejecuta otros binarios a través de cmd.exe
• Envía información, como el nombre de la computadora, nombre de usuario y antivirus instalado
• Persiste en un sistema comprometido creando claves de registro

Comandos

The commands that can be sent to the malware are:

• killme: detiene el malware y elimina la persistencia
• mouse: mueve el mouse. Con esta acción se tomará una captura de pantalla.
• cookies: envía cookies de Chrome a los C&C
• passwords: envía contraseñas guardadas de Chrome. Creemos que se centran en Chrome no por la cuota de mercado que tiene el navegador, sino por la facilidad de procesar las cookies y recuperar contraseñas almacenadas
• Otros comandos que se ejecutarán directamente con cmd.exe

La versión 2.5 fue la primera versión documentada del componente en C# (visto por primera vez por ESET en diciembre de 2018). Luego vimos la v2.7.1 (noviembre de 2019), la v3 (diciembre de 2019) y la v4.0 (abril de 2020). Las diferencias más importantes entre la última versión del malware y las anteriores son:

• El payload principal es una DLL de 32 bits. Antes era un archivo EXE de 64 bits.
• La comunicación HTTPS en la última versión
• Ya no está el comando de "reverse”, el cual había sido utilizado en versiones anteriores para abrir una shell inversa. Esto ahora se hace con otros scripts

Los componentes en JS y en C# están conectados entre sí: el último toma capturas de pantalla mientras que el primero no, pero tiene un código que busca archivos de captura de pantalla y los envía a su servidor C&C. El componente en C# también elimina todos los archivos con la extensión .lnk en la carpeta %LOCALAPPDATA%\Temp, limpiando los rastros del componente JS que hayan quedado del compromiso inicial. Por lo tanto, incluso si el componente en C# presenta funcionalidades limitadas (no puede descargar ni cargar archivos), proporciona redundancia con un servidor C&C diferente y persistencia adicional en caso de que el componente en JS sea detectado o eliminado de la computadora de la víctima.

Componentes de Golden Chickens: familia TerraLoader

En un pequeño número de casos, el grupo Evilnum también ha utilizado algunas herramientas que fueron compradas a un proveedor de Malware as a Service (Malware como Servicio). Este término se usa para describir a los creadores de malware que ofrecen no solo sus binarios maliciosos, sino también cualquier infraestructura necesaria (como los servidores de C&C) e incluso soporte técnico a los cibercriminales que tienen como clientes.

En este caso, el proveedor de MaaS se conoce como Golden Chickens y tiene otros clientes (además de este grupo) como FIN6 y el grupo Cobalt. Versiones anteriores de todos los componentes que describimos en las siguientes secciones fueron vistos anteriormente, como en un ataque contra negocios de eCommerce que Visa atribuyó a FIN6 en febrero de 2019. Creemos que FIN6, el grupo Cobalt y el grupo Evilnum no son lo mismo, a pesar de tener en común las herramientas que utilizan. Lo que ocurre es que comparten el mismo proveedor de MaaS.

Las herramientas de Golden Chickens vienen como componentes ActiveX (archivos OCX) y todas ellas contienen el código TerraLoader, que funciona como un loader que tienen en común los distintos payloads disponibles que Golden Chickens ofrece a los clientes. Evilnum utiliza estas herramientas de la siguiente manera:

• Los atacantes envían manualmente un comando al componente en JS o en C# para droppear y ejecutar un archivo por lotes desde uno de sus servidores.
• Ese archivo por lotes escribe un archivo INF malicioso y lo suministra como un parámetro para la utilidad de Microsoft cmstp.exe, que ejecuta un scriptlet remoto especificado en el archivo INF. Esta técnica ha sido documentada en la base de conocimiento MITRE ATT&CK como CMSTP. Un ejemplo de cómo se utiliza esta técnica se puede encontrar aquí. Esta técnica ha sido utilizada en el pasado por Cobalt, grupo que también responde a una motivación financiera.
• El scriptlet remoto contiene código en JS ofuscado que droppea un archivo OCX y lo ejecuta a través de regsvr32.exe.

El código TerraLoader realiza varias verificaciones de integridad antes de droppear el payload. Estas verificaciones implementan técnicas anti-debugging e intentan identificar anomalías para evitar la ejecución en entornos controlados o sandbox. Algunas de estas técnicas van desde la detección de parámetros incorrectos, nombres de archivo y extensiones, hasta la detección de hardware breakpoints o la identificación de módulos específicos cargados en el proceso en cuestión. Si todas estas comprobaciones pasan, se descifra y ejecuta el verdadero payload.

Hemos visto a Evilnum desplegar en sus ataques los siguientes payloads de Golden Chickens:

• More_eggs
• Un payload de Meterpreter que llamaremos TerraPreter
• TerraStealer
• TerraTV

Investigadores de Positive Technologies analizaron recientemente algunas herramientas utilizadas por el grupo Cobalt, incluida la versión 6.6 de More_eggs, que es una de las versiones utilizadas por el grupo Evilnum. Tienen un muy buen análisis de TerraLoader, por lo que sugerimos revisar su informe (sección 4).

More_eggs

More_eggs es un backdoor en JavaScript que se comunica con un servidor de C&C y acepta comandos. Ha sido utilizado en el pasado por otros grupos dirigidos a compañías financieras. Evilnum lo usa junto con los backdoors de creación propia para proporcionar redundancia y persistencia adicional en las redes de sus víctimas

Hemos visto a Evilnum usar componentes ActiveX de 32 bits con código TerraLoader que ejecuta las versiones 6.5, 6.6 y 6.6b de More_eggs – las últimas versiones disponibles. Lo hacen droppeando msxsl.exe (una utilidad de transformación de línea de comandos que es un ejecutable legítimo de Microsoft) y haciendo que ejecute el código en JavaScript, muy similar a lo que IRIS describió en este artículo.

El código JavaScript eliminado se genera sobre la marcha por el componente ActiveX, y hay algunas consideraciones durante el análisis:

• El código en JS inicial que ejecuta exe tiene hardcodeada una ruta absoluta, por lo que la ejecución desde otra ubicación o con otro usuario fallará.
• El payload final de More_eggs es cifrado con una clave que tiene el nombre del host e información de la familia del procesador adjunta al final. Un ejemplo de clave es:

cvyLMmtGSKmPMfzJjGyg552DESKTOP-FQAT01XIntel64 Family 6 Model 94 Stepping 3, GenuineIntel

Las funcionalidades principales son las mismas que se describen en el artículo mencionado anteriormente, aunque hay un nuevo comando, more_time, que no se menciona allí. Este comando es similar al comando documentado via_c, el cual ejecuta su parámetro con cmd.exe /v /c <parameter>. La diferencia es que adicionalmente envía la información de vuelta al C&C (via_c solo envía si el comando tuvo éxito o no).

TerraPreter

El grupo Evilnum también usa ejecutables de 64 bits que descifran y ejecutan una instancia de Meterpreter en la memoria. El uso de Meterpreter les brinda flexibilidad y la capacidad de ejecutar varios payloads de forma sigilosa y extensible.

La estructura de estos componentes y las verificaciones de integridad implementadas fueron identificadas como código TerraLoader. Es por eso que nos referimos a estos componentes como TerraPreter. El código descompilado de la principal rutina maliciosa se muestra en la Figura 7.

Figura 7. Código descompilado para los componentes Loader de Meterpreter

La rutina etiquetada como Dummy llama a una serie de APIs que no hacen nada. La función RC4 de inicialización aplica fuerza bruta a la clave a usar a partir de tomar una string base y agregarle un número que se incrementa en cada iteración. Luego descifra un búfer de 16 bytes con la clave candidata usando RC4. Si el búfer descifrado coincide con una string hardcodeada, entonces esa clave candidata será la clave RC4 elegida para su uso posterior.

Después de descifrar el búfer embebido con el payload, el malware finalmente establecerá una llamada de respuesta a la función API GrayStringW , apuntando al búfer descifrado. Después de pasar por muchas capas de decodificación, metsrv.dll de Meterpreter es cargada en la memoria. A partir de este momento, lo que vemos es un comportamiento regular de Meterpreter que no se ha modificado. Sin embargo, continuaremos describiendo cómo se realizan las comunicaciones.

TerraPreter se comunica con un servidor de C&C usando HTTPS y recupera una serie de comandos. Los C&C que hemos visto contactados son cdn.lvsys[.]com y faxing-mon[.]best. El primero fue redirigido a d2nz6secq3489l.cloudfront[.]net. Cada vez que un C&C recibe una solicitud, envía diferentes datos binarios XOReados con una clave aleatoria de 4 bytes. El malware lee la clave que se utilizará para el descifrado de los primeros 4 bytes de un encabezado de 32 bytes que prefija los datos cifrados. La figura 8 muestra un ejemplo.

Figura 8. Datos enviados por los C&C

El primer comando enviado por el C&C es core_patch_url, que cambia la última parte de la URL para solicitudes posteriores. Luego, core_negotiate_tlv_encryption es enviado por el C&C, junto con su clave pública. A partir de este momento, los mensajes se cifrarán antes de ser XOReados.

TerraStealer y TerraTV

TerraStealer también se conoce como SONE o Stealer One. Para robar cookies y credenciales escanea muchos navegadores, aplicaciones de correo electrónico, FTP y de transferencia de archivos. Uno de los binarios que analizamos tenía el registro activado. Parte de uno de esos registros se muestra en la Figura 9.

Figura 9. Registro de TerraStealer

Otro componente utilizado por este grupo es una variante de TerraTV. Ejecuta una aplicación legítima de TeamViewer pero oculta sus elementos de interfaz de usuario, de modo que los operadores del malware pueden conectarse a la computadora comprometida sin ser detectados.

Cuando se ejecuta, TerraTV droppea varios componentes firmados de TeamViewer en C:\Users\Public\Public Documents\57494E2D3850535046373333503532\. Los archivos droppeados se muestran en la Figura 10.

Figura 10. Archivos de TeamViewer droppeados por TerraTV

ACTIVEDS.dll no está firmada y es donde reside el código malicioso. Hay una DLL de Windows con ese mismo nombre en la carpeta del sistema, pero como la DLL maliciosa está en el mismo directorio que el ejecutable de TeamViewer, se encuentra primero y, por lo tanto, se carga en lugar de la DLL de Windows. Esto se conoce como DLL search order hijacking. Esta ACTIVEDS.dll hookea varias llamadas a la API en el ejecutable de TeamViewer para ocultar el icono de la aplicación de la barra de tareas y capturar las credenciales de inicio de sesión. La parte del código donde se establecen los hooks se muestra en la Figura 11.

Figura 11. Hooks establecidos para TeamViewer

La llamada API de Windows DefWindowProcW (llamada varias veces por el ejecutable de TeamViewer para procesar los mensajes dirigidos a su ventana principal) es hookeada con una rutina que escribe el ID y la contraseña de TeamViewer en el archivo %APPDATA%\log_CZ72kGqTdU.txt. Con estas credenciales, y TeamViewer ejecutándose sin un icono en la barra de tareas o ventana, los operadores del malware pueden controlar de forma remota la computadora, a través de su GUI, en cualquier momento.

Conjunto de herramientas post-compromiso

A los componentes maliciosos mencionados anteriormente se suman con frecuencia varias herramientas adicionales que forman parte del arsenal del grupo Evilnum. En la mayoría de los compromisos que hemos visto, los atacantes utilizaron herramientas disponibles de forma pública, pero también desarrollaron algunos scripts personalizados. Por lo general, mantienen sus herramientas en sus servidores en archivos protegidos con contraseña y los descomprimen en el equipo de la víctima según sea necesario.

Herramientas basadas en Python

• Reverse shell over Script SSL: Un script muy corto que toma el servidor y el puerto como argumentos de línea de comando.
• Proxy SSL que utiliza PythonProxy, junction, plink y stunnel. También se puede conectar a un servidor FTP o usar pysoxy. Hemos visto la secuencia de comandos que se utiliza con la configuración "proxy" y 185.62.189[.]210 como el servidor.
• LaZagne para recuperar contraseñas almacenadas
• IronPython junto con bibliotecas para tomar capturas de pantalla, registros de teclado y grabar audio de DirectSound

Otras herramientas disponibles públicamente

• Scripts de PowerShell: por ejemplo, Bypass-UAC
• Varias utilidades de NirSoft; por ejemplo, Mail PassView, utilizada para recuperar contraseñas de clientes de correo electrónico, y ProduKey, para obtener licencias de Microsoft Office y Windows

Conclusión

El grupo Evilnum ha estado operando durante al menos dos años y estaba activo al momento de escribir este artículo. Cuenta con una infraestructura para sus operaciones compuesta por varios servidores diferentes: uno para las comunicaciones con el componente en JS, otro para el componente en C#, otro para almacenar sus herramientas y datos extraídos, el servidor proxy, etc. Este grupo apunta a empresas Fintech que ofrecen plataformas de trading y de inversión para sus clientes. Los objetivos son muy específicos y no numerosos. Esto, y el uso por parte del grupo de herramientas legítimas en su cadena de ataque, han mantenido sus actividades en gran medida bajo el radar. Gracias a los datos de nuestra telemetría pudimos unir los puntos y descubrir cómo funciona el grupo, descubriendo algunos puntos en común con otros grupos APT conocidos. Creemos que este y otros grupos comparten el mismo proveedor de MaaS,

Puede encontrar una lista completa de los Indicadores de compromiso (IoC) y muestras en nuestro repositorio de GitHub.

Para cualquier consulta o para el envío de muestras relacionadas con el tema, contáctenos en threatintel@eset.com.

Un agradecimiento especial a Ignacio Sanmillan por su ayuda con el análisis de los componentes de Golden Chickens.

Técnicas de MITRE ATT&CK