Anti-sanboxing en MSI de malware N40/Mekotio

Actualización 25/06: Agregadas nuevas LaunchConditions encontradas por Germán Fernández en Twitter.

Hoy quisiera compartir un nuevo cambio que se ha generado en esta campaña de troyanos bancarios.

Este malware ha crecido bastante desde que lo vimos por primera vez hace ya más de 3 años, y de hecho fue parte de una de mis charlas en el año 2019 (Artículo de autopromoción).

Esta familia de malware también ha sido revisada en varios artículos por distintas entidades (principalmente ESET), y lamentablemente no nos podemos poner de acuerdo en el nombre, pero sí estamos alineados y hablamos de lo mismo:

Muchos de estos artículos se enfocan en el mismo patrón, llega un correo que urge a la víctima a descargar un archivo .zip que dentro tiene alguna forma de iniciar la infección.

En el pasado era directamente un archivo Javascript o acceso directo. Pero me quiero centrar en otro de los métodos de engaño que tiene este malware un instalador (archivo .msi) el cual la víctima tiene que ejecutar para que en alguna parte del proceso de instalación se produzca la infección.

Hasta ahora todo se mantiene muy similar a lo que ha ocurrido por ya 2 años en el pasado, de hecho usan el mismo tipo de herramientas para que apoye en el proceso de generación de estos archivos .msi. Lo interesante es lo que al parecer la efectividad de este malware está bajando, porque se están poniendo un poco más aplicados con técnicas de “anti-sanboxing”.

Para este análisis usaremos 1 muestra del año pasado y 2 muestras que nos han aparecido en el último mes (Junio 2021)

Estas muestras son muy similares en su intención, pero muestran una ligera evolución frente a la forma que tienen de infectarte.

Primera muestra (2020)

Haciendo un poco de historia esta muestra llegó en un correo como un archivo adjunto que tenía una página HTML que te redirigía a OneDrive a una descarga maliciosa comprimida. Dentro de este archivo venía esta muestra MSI.

Para analizar este archivo .msi tenemos distintas herramientas:

Cada una de estas tiene su utilidad y la forma en que nos puede apoyar dependiendo del caso, intentaré usar todas para que vayamos viendo la información que pueden entregar.

Al revisar el archivo por encima vemos que era un instalador simple, muy liviano (559104 bytes) porque no tenía nada directamente malicioso sino que usaba código Jscript embebido en las “Custom Actions” para poder descargar y ejecutar el malware.

Pero vamos un poco más lento, si revisamos este archivo con msiinfo tenemos que fue creado con el programa Advanced Installer 16.2 (https://www.advancedinstaller.com/):

Además, podemos ver que los campos de Subject y Author tienen cadenas aleatorias y el Template tiene el código del lenguaje utilizado, en este caso el 3082 que es “Español Internacional” (listado de lenguajes).

Si queremos revisar cómo se generaba la infección y dónde estaba ese código Jscript necesitamos revisar los “Custom Actions” de este instalador. Para ello tenemos 2 opciones: usar Orca o Dark.exe. Usando Orca tenemos la siguiente vista:

Aquí podemos ver que utiliza las acciones que vienen por defecto con “Advanced Installer”, por ejemplo, se apoya mucho en la librería “aicustact.dll” que ayuda con varias tareas de la instalación.

Si queremos ver la parte infecciosa del instalador tenemos que ver la Custom Action llamada “VonMXM856FIYzmC”. Esta tarea tiene Type 101, el cual significa que es un código Jscript (+37) el que se ejecuta síncronamente y se ignora el valor de retorno (+64) (más información aquí).

Para otra vista del código les coloco un extracto de lo que se sacó con la segunda herramienta (Dark.exe)

Con este código el actor delincuente quería descargar de un sitio que controlaba un archivo comprimido con la infección “real”.

Para las muestras del 2021 cambia un poco el proceso.

Últimas muestras (2021)

Ambas muestras llegan a la víctima gracias a un correo con un link de descarga de una factura. Este link depende del momento, para la primera muestra llegaba a un sitio comprometido y la segunda es un link de mediafire.

Luego de la descarga, ambos archivos tienen una carpeta comprimida de nombre “ver” o “Ver” con el contenido dentro.

Si revisamos los archivos MSI al igual como lo hicimos con el de la primera muestra, vemos que ahora tienen un archivo .msi pesado (al rededor de 15 Mb), porque mantienen el binario malicioso embebido directamente en el instalador. Asumimos que con esto pueden evitar la acción de los sistemas reactivos que bloquean la descarga de la segunda etapa (stage 2) de las muestras con Jscript.

Otra cosa llamativa es que la segunda muestra tiene un archivo llamado simplemente con el nombre “-” (b3b6ee98aca14cf5bc9f3bc7897bc23934bf85fc4bc25b7506fe4cd9a767047a). Ese archivo es parte de “ApiSet Stub DLL”, es un archivo firmado por Microsoft de la biblioteca CRT universal (según comentado aquí), aún no sé para qué quieren usar ese archivo, pero me pareció interesante.

Si revisamos ahora la información general de cada archivo .msi con msiinfo:

Tenemos que este archivo se generó con la misma aplicación “Advanced Installer” pero una versión más nueva (17.7 build 8a137570), y que ambos tienen autores aleatorios pero un “Subject” idéntico. También podemos ver que volvieron al lenguaje “por defecto” porque el id es 1033, que corresponde al Inglés de USA.

Para ver las acciones que se realizan con el instalador vamos a necesitar nuestras otras herramientas, por ejemplo, con Orca tenemos una visión interesante de los pasos (Custom Actions) que realiza en la instalación:

En este caso, vemos que en ambos MSI existe una acción de “Type” 193, lo cual significa una ejecución de una DLL embebida en los streams (+1) de manera asíncrona (+192) (ver más detalles aquí). Para saber cuál será el punto de entrada basta ver la columna “Target”.

Es una forma ingeniosa de generar la ejecución automática del binario malicioso, pero lo interesante no es eso, sino que entre ambas muestras existe otra diferencia, la inclusión de una acción extra llamada “AI_DetectSoftware” que se apoya en otra de las librerías de “Advanced Installer” llamada SoftwareDetector.dll.

Sin haber usado este generador de instaladores anteriormente me llama la atención la nueva “Custom Action”, entonces nos toca buscar más diferencias para entender qué significa esto.

Integrando el anti-sandboxing

Si probamos las muestras antiguas de estos MSI podemos ver que no existe ningún tipo de validación, se puede instalar en cualquier sistema que sea Windows suficientemente nuevo. De hecho, si vemos los LaunchCondition de la muestra del 2020 tenemos:

O sea, sólo valida que no sea un Windows “muy viejo”, pero no coloca ninguna otra condición para instalar.

Si vemos las LaunchCondition definidas para el los instaladores de este año (2021) tenemos algunas similares, pero al comparar ambas muestras nos sorprendimos:

¡Aparecieron varias condiciones extra!

De hecho si ejecutamos el último instalador directamente en una máquina virtual tenemos lo siguiente:

Este es un error que no ocurría antes, de hecho cuando los delincuentes querían terminar con la ejecución usaban un error mucho más explicado, para que el usuario no sospeche. En este caso es bastante sospechoso que solo diga “Error!” con el título de la ventana que diga “Fichero”.

Si revisamos un poco más detenidamente las diferencias de LaunchConditions de la última muestra, tenemos que han agregado 4 condiciones interesantes:

LaunchConditionTexto del Mensaje
(NOT AI_DETECTED_VIRTUAL_MACHINE)Error!
%COMPUTERNAME ~<> “WIN-VUA6POUV5UP”Error!1
%COMPUTERNAME ~<> “JOHN-PC”Error!2
TESTED = TRUEError!4

Podemos asumir entonces que los delincuentes están haciendo revisiones para detectar si es que se está usando en una máquina real o no (anti-vm) porque el error anterior aparece directamente en la configuración del MSI. Es el mismo texto de error que aparece en la LaunchCondition “(NOT AI_DETECTED_VIRTUAL_MACHINE)”.

Las otras condiciones asumimos que son por nombres de PC: el primero no lo conocemos, pero el segundo es conocido como nombre de PC de sandbox genérico, entonces están pensando en implementar algunas técnicas anti-sandboxing también.

El “TESTED = TRUE” no lo pudimos reproducir, por lo que cualquier dato al respecto nos ayudaría a entender este comportamiento, asumimos que es otra de las técnicas de anti-sandboxing, pero no estamos seguros.

De igual forma, la conclusión es interesante: ¡Están probando nuevas funcionalidades! ¡Tienen anti-sandbox incorporado!

Muestra 24/06

Esta muestra (cfa9c1d8b0ea8b947b89c01c9cbb87a70161a528337e5af00e855a70d350f22e) sigue en la misma línea que las anteriores, y tal como lo muestra en un tweet Germán Fernández tiene nuevos chequeos de anti-vm y anti-sandbox:

LaunchConditionTexto del Mensaje
%COMPUTERNAME ~<> “WIN-VUA6POUV5UP”Error!
%COMPUTERNAME ~<> “JOHN-PC”Error!
%COMPUTERNAME ~<> “DESKTOP-D019GDM”Error!
%COMPUTERNAME ~<> “DESKTOP-EWPM3MB” Error!
%COMPUTERNAME ~<> “DESKTOP-OZAXQLD” Error!
%COMPUTERNAME ~<> “DESKTOP-V5RTEY1” Error!
%COMPUTERNAME ~<> “KIMCLA”  Error!
(NOT AI_DETECTED_VIRTUAL_MACHINE)   Error!
AI_DETECTED_INTERNET_CONNECTIONError!
TESTED = TRUEError!

Al igual que la muestra del 22/06, estos chequeos los hacen para revisar si se está instalando en equipos particulares, a través de una revisión del nombre del equipo, pero lo otro interesantes es que también requieren tener conexión a internet con la LaunchCondition “AI_DETECTED_INTERNET_CONNECTION”

Cada vez están sofisticando más las técnicas anti-sandbox, por ahora son detectables “a simple vista”, pero no falta mucho para que den el salto a otro tipo de técnicas.

Conclusiones

Existe una campaña activa “muy interesante” que nos afecta hace varios años acá en América Latina, y este malware sigue evolucionando al día de hoy. Aún cuando la detección de sandboxing es bastante primitiva en este momento, marca una tendencia de evolución que no se puede ignorar.

Los atacantes siguen avanzando con nuevas técnicas, tanto a nivel de los correos de spam como de los payloads que envían. Por lo mismo, tenemos que desarrollar investigaciones nuevas para mejorar la detección de estos nuevos patrones y prevenir lo más temprano posible estas infecciones.

Les adjunto una regla Yara para detectar preventivamente este tipo de instaladores, ojalá les sirva:

rule detect_strange_msi {
meta:
author = "Ricardo Monreal (@joydragon)"
description = "Yara de prueba para detectar patrones extraños de campaña de N40/Mekotio en Chile. Actualizada 2021-11-03"
strings:
// Hex que diga "Fichero", "TGR" o "Arquivo … cargando" como parte del "Subject"
$bytes_1 = { 03 00 00 00 0a 00 00 00 1e 00 00 00 ?? 00 00 00 46 69 63 68 65 72 6f 00 1e }
$bytes_2 = { 03 00 00 00 0a 00 00 00 1e 00 00 00 ?? 00 00 00 54 47 52 00 1e }
$bytes_3 = { 03 00 00 00 0a 00 00 00 1e 00 00 00 ?? 00 00 00 41 72 71 75 69 76 6f 20 2e 2e 2e 20 63 61 72 67 61 6e 64 6f 00 00 00 00 1e }
// Alguno de los lenguajes utilizados
$langs_1 = "ProductLanguage1033"
$langs_2 = "ProductLanguage3082"
// Regex para que sea archivo MSI (magic bytes)
$magic = { D0 CF 11 E0 A1 B1 1A E1 00 00 00 }
// String de la version de Advanced Installer
$string = "Advanced Installer 17.7 build 8a137570"
condition:
1 of ($bytes_*) and 1 of ($langs_*) and $magic at 0 and $string
}
view raw detect_strange_msi.yara hosted with ❤ by GitHub

Mientras antes podamos prevenir estas infecciones, mejor. Si tienen más información de estas campañas cualquier aporte es bienvenido, no duden en contactarnos.

Muchas gracias por leer hasta acá.

2 respuestas a “Anti-sanboxing en MSI de malware N40/Mekotio”

Add yours

  1. Mirando a la rápida (vi uno de esos, con un mail aparentando ser de la TGR por contribuciones impagas), vi esxe archivo “-“, y si es una .dll, es que debe de ser alguna versión vulnerable con posible escalamiento y cosas así, para ejecutar algo más ‘tóxico’: fileless o persistencia avanzada por WMI.
    Gracias por este detalle 🙂

    Me gusta

    Responder
  2. Pingback: Nuevo estilo de infección de Mekotio en Chile – FINSIN

Deje un comentario

Crea una web o blog en WordPress.com

Subir ↑