Hambriento de datos, la puerta trasera ModPipe llega al software POS utilizado en el sector de la hospitalidad


Los autores de backdoor muestran un conocimiento profundo del software de POS específico, descifrando las contraseñas de la base de datos de los valores del registro de Windows

Los investigadores de ESET han descubierto ModPipe, una puerta trasera modular que brinda a sus operadores acceso a información confidencial almacenada en dispositivos que se ejecutan Serie empresarial de restaurantes ORACLE MICROS (RES) 3700 POS: un paquete de software de gestión utilizado por cientos de miles de bares, restaurantes, hoteles y otros establecimientos hoteleros en todo el mundo.

Lo que distingue a la puerta trasera 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 demuestra que los autores de la puerta trasera tienen un conocimiento profundo del software objetivo 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 fuerte", como el registro de teclas.

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 de 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 confidencial, como números de tarjetas de crédito y fechas de vencimiento, que está protegida por cifrado. Los únicos datos del cliente almacenados de forma clara 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 valiosa viable para su posterior venta o uso indebido, haciendo que el "modelo comercial" completo detrás de la operación no esté claro. Una posible explicación es que existe otro módulo descargable que permite 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 en el proceso de generación de la "frase de contraseña específica del sitio", que se utiliza para derivar la clave de cifrado de datos confidenciales. Este proceso tendría que implementarse en el módulo y, debido al uso de la API de protección de datos de Windows (DPAPI), ejecutarse directamente en la máquina de la víctima. Otro desconocido que queda 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 los sectores de la restauración y la hostelería, los principales clientes de RES 3700 POS.

Arquitectura 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. gotero inicial – contiene binarios de 32 y 64 bits de la siguiente etapa, el cargador persistente, e instala la versión adecuada en la máquina comprometida.
  2. cargador 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 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 atacante. C&C servidor.
  4. módulo de redes – módulo utilizado para la comunicación con C&C.
  5. módulos descargables – componentes que agregan funcionalidad específica a la puerta trasera, 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 de puerta trasera ModPipe

Módulos descargables

Probablemente las partes más intrigantes de ModPipe son sus módulos descargables. Somos conscientes 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 caza, encontramos tres de estos módulos en estado salvaje. 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 usan al menos otros cuatro módulos descargables, cuya funcionalidad sigue siendo completamente desconocida. a nosotros por ahora.

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

Tabla 1. Módulos descargables

ID del módulo Nombre Descripción
0xA0C0 GetMicInfo Roba contraseñas de bases de datos, datos y varias configuraciones
0x2000 ModScan Realiza un escaneo en las direcciones IP especificadas
ProcList Obtiene una lista de los procesos en ejecución y sus módulos cargados
0xA000 desconocido
0xA040 desconocido
0xA740 desconocido
0xA080 desconocido

Módulo descargable: GetMicInfo

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

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

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

El módulo GetMicInfo puede interceptar y descifrar estas contraseñas de base de datos, utilizando un algoritmo diseñado específicamente. 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 ingeniería inversa de la implementación del ORACLE MICROS RES 3700 POS y 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, reportado por primera vez por el periodista de seguridad Brian Krebs.
  • Los operadores de malware podrían haber comprado el código en un 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 de dba, también intentará adquirir la ruta a la biblioteca de la API de 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 usando 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 cadena de conexión:

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

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

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 canalización con ID 0x10000013 (consulte la Tabla 3 para obtener una lista completa de mensajes de canalización y sus ID):

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 varias configuraciones de servicios de tarjetas de crédito.

Figura 3. Código descompilado de 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 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 (Servicio MICROS CAL – Servidor de cargador de aplicaciones cliente)
  • 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 escaneando las direcciones IP seleccionadas. El módulo ModScan 2.20 se inyecta en uno de los procesos especificados por C&C a través de un comando InstallMod (0x72). Según nuestros hallazgos, generalmente se asocia con uno de los siguientes procesos legítimos:

  • MDSHTTPService.exe (Servicio HTTP MICROS MDS)
  • CALSrv.exe (Servicio MICROS CAL – Servidor de cargador de aplicaciones cliente)
  • msdtc.exe
  • jusched.exe
  • spoolsv.exe
  • services.exe

Las diferencias entre los procesos inyectados mal utilizados por GetMicInfo y los que apunta ModScan 2.20 pueden deberse al hecho de que el módulo GetMicInfo se inyecta solo en los procesos que se ejecutan en WOW64.

La lista de direcciones IP destinadas a la exploración y la dirección IP especial de "ping" son especificadas por C&C de una de dos formas. Es:

  1. descargado de C&C junto con el módulo ModScan, o
  2. recibidos durante el tiempo de ejecución, utilizando la canalización con nombre 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 canalización del módulo ModScan 2.20

Nombre del comando Descripción del comando
salida Salida
detener Terminar los hilos de análisis
escanear Comience a escanear las IP especificadas en los datos del comando para recopilar información adicional sobre el entorno
prm Especifique una dirección IP especial de "ping"

Rutina del procedimiento de escaneo

  1. Antes de escanear, el módulo envía un mensaje especial de "ping" que contiene un valor de 32 bits generado por el GetTickCount Función de 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 “ping”.
  2. La respuesta de la dirección IP "ping" debe contener el mismo valor de 32 bits girado a la derecha un bit y con XOR 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 de Hex-Rays de la funcionalidad de ping de ModScan

  1. 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 enviando 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 etiquetas xml de datos (%versión%) de la respuesta del servicio.

Figura 5. Solicitud de servicio HTTP MDS

  • Nombre de la base de datos, extraído enviando 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 cadena 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.
  • Servidor de base de datos datos, como su nombre, versión del protocolo TDS y la versión del servidor TDS. Para obtener esta información, el módulo ModScan envía un código Paquete de inicio de sesión de TDS 4.2 y 5.0 (Figura 6) a la dirección IP especificada en el puerto 2638. La respuesta incluye un Acuse de recibo de inicio de sesión paquete 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á codificado de forma rígida, con el nombre de usuario establecido en el dba incorporado y una contraseña codificada, que es potencialmente la contraseña predeterminada en algunas versiones de RES 3700 POS. Como no hemos encontrado ninguna referencia pública a esta contraseña, no la publicaremos en nuestra entrada de blog.

Figura 6. Paquete de inicio de sesión de 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 identificación asignada. Su objetivo principal es recopilar información sobre los procesos que se ejecutan actualmente, incluidos: nombre, identificador de proceso (PID), PID del proceso principal, número de subprocesos, 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 de la puerta trasera (mediante el mensaje de canalización 0x10000013).

Gotero inicial

El cuentagotas inicial es responsable de instalar la siguiente etapa del malware. Durante nuestra investigación, descubrimos un ejecutable de cuentagotas 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 cuentagotas inicial, se genera una configuración única, utilizando principalmente bytes aleatorios. Esto hace que el hash del cargador caído cambie con cada ejecución, lo que complica la detección y el seguimiento del malware. El componente cuentagotas puede colocar el cargador 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 detalles, consulte la Indicadores de compromiso sección).

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


Figura 7. Código descompilado de Hex-Rays: descifrado y ejecución de la carga útil en el cuentagotas inicial

Un ejemplo de una configuración encriptada y desencriptada con explicaciones es visible en la Figura 8. La configuración que se muestra proviene del cargador instalado por la muestra del cuentagotas con hash SHA-1 9f8530627a8ad38f47102f626dec9f0173b44cd5. Tenga en cuenta que la estructura de la configuración puede variar entre las versiones más antiguas y más nuevas del ejecutable del cargador.

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

Cargador 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 cargador persistente usa diferentes enfoques para las versiones de 32 y 64 bits. Mientras que el cargador de 32 bits es casi idéntico al dropper inicial (la única diferencia son las cargas útiles almacenadas en los recursos), el cargador de 64 bits utiliza un código de "desempaquetado" completamente diferente.

Hemos encontrado siete versiones diferentes de los ejecutables del cargador, 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 cargador está incluido en el Indicadores de compromiso sección.

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

Módulo principal

El módulo principal es principalmente responsable de administrar la comunicación 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 generado aleatoriamente formateado usando la siguiente cadena de formato:

% 08X-% 04X-% 04X-% 04X-% 08X% 04X

A continuación, comprueba periódicamente la canalización en busca de nuevos mensajes utilizando el PeekNamedPipe Función 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 canalización reconocidos, consulte la Tabla 3.

Tabla 3. Lista de tipos de comando / mensaje de canalización

Código de mensaje Descripción
0x10000012 inyectar y ejecutar el módulo recibido en el proceso especificado
0x10000013 datos para el servidor C&C (registros de ejecución, datos robados,…)
0x10000014 escriba los datos de configuración solicitados en el identificador de archivo recibido en este mensaje (lo más probable es que identifique la tubería con nombre creada por algún otro módulo) (configuración principal, configuración de red, nombre del cargador, PID del módulo principal, …)
0x10000020 Comandos C&C (no cifrados): consulte la Tabla 4 para obtener la lista completa de comandos disponibles
0x10000022 establecer el estado del módulo (o código de error)
0x10000023 establecer intervalos de tiempo de comunicación C&C
0x10000024 cerrar lista recibida de identificadores
0x10000025 obtener el control del proceso con el PID especificado, duplicarlo para algún otro proceso especificado y enviarlo a través del identificador de canalización con nombre recibido
0x10000072 Comandos C&C (cifrados): consulte la Tabla 4 para obtener la lista completa de comandos disponibles

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

Figura 10. Estructura de los mensajes de canalización con nombre del módulo principal

Para comunicarse 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 a lo largo de nuestra investigación está disponible en el Indicadores de compromiso sección.

Los mensajes enviados a 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 una cubierta de apariencia limpia para el tráfico malicioso. Las URL utilizan el siguiente formato www.% dominio% (.) com /?% rand%, dónde %dominio% es elegido 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 está encriptada usando 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 se calcula 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 pedido 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 mayor prioridad se inyectan primero, de acuerdo con 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, recibió una respuesta del C&C y 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 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 se detectan comunicándose a través de la red.

Módulo de redes

Este módulo ModPipe es responsable de enviar solicitudes a C&C y analizar la carga útil recibida en las respuestas de C&C. Los métodos HTTP POST o GET con encabezados que se muestran en la Figura 12 y la Figura 13 se pueden usar para cargar datos en C&C y descargar cargas útiles adicionales y comandos C&C.

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

Figura 13. Encabezado del mensaje HTTP GET

Las respuestas del servidor C&C deben tener al menos 33 bytes de longitud para que el módulo de red pueda analizarlas y la carga útil maliciosa se ubica después de una secuencia de 13 espacios seguidos de una etiqueta de apertura de comentario HTML. En la Figura 14 se muestra un ejemplo de una respuesta del servidor que incluye esta secuencia.

Figura 14. Ejemplo de respuesta del servidor C&C, incluida la carga útil cifrada

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

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

Código de comando Descripción del comando
0x01 Salida
0x05 Actualizar lista de direcciones C&C
0x0A Inyectar y ejecutar el módulo recibido en el proceso especificado
0x0B Inyectar y ejecutar el módulo recibido en el proceso especificado (el nombre del módulo se incluye en el comando)
0x0C Opcionalmente, escriba el módulo en el almacenamiento cifrado, luego inyecte y ejecute el módulo recibido en el proceso especificado; agréguelo a la lista de módulos instalados
0x0D Envíe el comando a la tubería nombrada que pertenece al módulo con el ID especificado y ponga en cola la respuesta para la carga en el C&C
0x0E Desinstale el módulo con el ID especificado (elimínelo de la lista en memoria y del almacenamiento encriptado)
0x0F Guarde la configuración de red en el almacenamiento cifrado

Conclusión

ModPipe muestra bastantes características interesantes. Probablemente el hallazgo más intrigante es el algoritmo oculto en uno de los módulos de la puerta trasera, 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 confidencial, aunque los datos más confidenciales almacenados en dispositivos que ejecutan RES 3700 POS deben estar protegidos por cifrado.

La arquitectura, los módulos y sus capacidades de ModPipe también indican que sus escritores tienen un amplio conocimiento del software de POS de RES 3700 específico. La competencia de los operadores podría provenir de múltiples escenarios, incluido el robo y la ingeniería inversa del producto de software patentado, el uso indebido de sus partes filtradas o la compra de código en un mercado clandestino.

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

  • Utilice la última versión del software.
  • Úselo 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 de 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 de C&C

  • subzeroday.zapto (.) org
  • shj145ertyb.ddns (.) net / gettime.html
  • ouidji12345.ddns (.) net / gettime.html

Muestras de cuentagotas

  • 9F8530627A8AD38F47102F626DEC9F0173B44CD5
  • FEE9C08B494C80DBF73A6F70FACD20ED0429330D

Muestras de cargador

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

Rutas de archivo

  • % CSIDL_APPDATA% Microsoft Windows % rand_guid% explorer.exe
  • % WINDIR% system32 % nombre_aleatorio% .exe

% rand_guid%: cadena con formato GUID pseudoaleatorio
% random_name% – de 4 a 7 letras pseudoaleatorias (a-z) con la primera en mayúscula, p. ej. "Cvoeqo.exe"

Técnicas MITRE ATT & CK

Nota: esta tabla fue construida usando versión 7 del marco MITRE ATT & CK.

Táctica CARNÉ DE IDENTIDAD Nombre Descripción
Ejecución T1059.003 Intérprete de comandos y secuencias de comandos: Shell de comandos de Windows Los atacantes fueron vistos usando Windows Command Shell para ejecutar el dropper inicial.
Persistencia T1547.001 Ejecución de inicio automático de inicio o inicio de sesión: claves de ejecución del registro / carpeta de inicio ModPipe puede utilizar la clave Registry Run para la persistencia.
T1543.003 Crear o modificar el proceso del sistema: servicio de Windows ModPipe puede crear un nuevo servicio de persistencia.
Escalada de privilegios T1134.001 Manipulación de tokens de acceso: suplantación de tokens / robo Los atacantes fueron vistos usando parcialmente modificados PrintSpoofer herramienta para soltar y posteriormente ejecutar el cargador con privilegios de SISTEMA.
Evasión de defensa T1055.002 Inyección de proceso: inyección ejecutable portátil ModPipe puede inyectar sus módulos en varios procesos.
T1205 Señalización de tráfico El módulo ModScan de ModPipe envía valores aleatorios de 32 bits a los puertos TCP 50123 y 2638 de la dirección IP especificada y requiere una respuesta específica para continuar ejecutando su funcionalidad de escaneo.
Acceso a credenciales T1552.002 Credenciales no seguras: credenciales en el registro El módulo GetMicInfo de ModPipe recupera contraseñas de bases de datos cifradas para el software POS ORACLE MICROS RES 3700 del Registro de Windows y utiliza un algoritmo personalizado para descifrarlas antes de cargarlas en C&C.
Descubrimiento T1057 Descubrimiento de procesos El módulo ProcList de ModPipe puede obtener información sobre los procesos que se ejecutan en un sistema.
T1012 Registro de consultas El módulo GetMicInfo de ModPipe consulta al Registro la versión POS de ORACLE MICROS RES 3700, las contraseñas de la base de datos y otros datos de configuración.
T1033 Descubrimiento de propietario / usuario del sistema ModPipe recopila el nombre de usuario y el nombre de la computadora de las máquinas víctimas y los informa al C&C en el mensaje inicial.
Comando y control T1071.001 Protocolo de capa de aplicación: protocolos web ModPipe usa HTTP para comando y control.
T1573.001 Canal cifrado: criptografía simétrica ModPipe cifra la comunicación con C&C usando AES en modo CBC.
Exfiltración T1041 Exfiltración sobre canal C2 ModPipe extrae datos a través de su canal C&C.
T1029 Transferencia programada El intervalo predeterminado que usa ModPipe para cargar datos en C&C está establecido en 30 minutos.





Enlace a la noticia original