No "Game over" para el Grupo Winnti


El famoso grupo APT continúa jugando en la industria de los videojuegos con otra puerta trasera.

En febrero de 2020, descubrimos una nueva puerta trasera modular, que llamamos PipeMon. Persistiendo como un procesador de impresión, fue utilizado por el Grupo Winnti contra varias compañías de videojuegos con sede en Corea del Sur y Taiwán y desarrolla juegos MMO (Massively Multiplayer Online). Los videojuegos desarrollados por estas compañías están disponibles en plataformas de juegos populares y tienen miles de jugadores simultáneos.

En al menos un caso, los operadores de malware comprometieron el sistema de compilación de la víctima, lo que podría haber llevado a un ataque a la cadena de suministro, permitiendo a los atacantes troyanizar los ejecutables del juego. En otro caso, los servidores del juego se vieron comprometidos, lo que podría haber permitido a los atacantes, por ejemplo, manipular las monedas del juego para obtener ganancias financieras.

El Grupo Winnti, activo desde al menos 2012, es responsable de los ataques de cadena de suministro de alto perfil contra la industria del software, lo que lleva a la distribución de software trojanizado (como CCleaner, ASUS LiveUpdate y múltiples videojuegos) que luego se utiliza para comprometer a más víctimas. Recientemente, los investigadores de ESET también descubrieron un campaña del Grupo Winnti dirigida a varias universidades de Hong Kong con el malware ShadowPad y Winnti.

Sobre el nombre del "Grupo Winnti":

Hemos elegido mantener el nombre "Grupo Winnti", ya que es el nombre que Kaspersky usó por primera vez para identificarlo en 2013. Dado que Winnti también es una familia de malware, siempre escribimos "Grupo Winnti" cuando nos referimos a los malhechores detrás de los ataques. Desde 2013, se ha demostrado que Winnti es solo una de las muchas familias de malware utilizadas por el Grupo Winnti.

Atribución al Grupo Winnti

Múltiples indicadores nos llevaron a atribuir esta campaña al Grupo Winnti. Algunos de los dominios C&C utilizados por PipeMon fueron utilizados por el malware Winnti en campañas anteriores mencionadas en nuestro libro blanco sobre el arsenal del Grupo Winnti. Además, el malware Winnti también se encontró en 2019 en algunas de las compañías que luego se vieron comprometidas con PipeMon.

Además del malware Winnti, durante esta campaña también se usó un binario AceHash (un credencial de credenciales) personalizado que se encontró en otras víctimas del Grupo Winnti y se firmó con un conocido certificado robado utilizado por el grupo (Wemade IO).

El certificado utilizado para firmar el instalador, los módulos y las herramientas adicionales de PipeMon está vinculado a una compañía de videojuegos que se vio comprometida en un ataque a la cadena de suministro a finales de 2018 por el Grupo Winnti y probablemente fue robado en ese momento.

Curiosamente, los módulos PipeMon están instalados en % SYSTEM32% spool prtprocs x64 ; este camino también se usó en el pasado para soltar el segunda etapa del CCleaner troyano.

Además, comprometer el entorno de compilación de un desarrollador de software para comprometer posteriormente la aplicación legítima es un modus operandi conocido del Grupo Winnti.

Compañías dirigidas

Las empresas seleccionadas en esta campaña son desarrolladores de videojuegos, que producen juegos MMO y tienen su sede en Corea del Sur y Taiwán. En al menos un caso, los atacantes pudieron comprometer el servidor de orquestación de compilación de la compañía, lo que les permitió tomar el control de los sistemas de compilación automatizados. Esto podría haber permitido a los atacantes incluir código arbitrario de su elección en los ejecutables de los videojuegos.

ESET contactó a las empresas afectadas y proporcionó la información necesaria para remediar el compromiso.

Análisis técnico

Se encontraron dos variantes diferentes de PipeMon en las empresas objetivo. Solo para la variante más reciente pudimos identificar la primera etapa que es responsable de instalar y mantener PipeMon.

Primera etapa

La primera etapa de PipeMon consiste en un ejecutable RARSFX protegido con contraseña integrado en el .rsrc sección de su lanzador. El lanzador escribe el RARSFX a setup0.exe en un directorio nombrado con una cadena ASCII de ocho caracteres generada aleatoriamente ubicada en el directorio devuelto por GetTempPath. Una vez escrito en el disco, el RARSFX se ejecuta con Proceso de creación proporcionando la contraseña de descifrado en un argumento, de la siguiente manera:

setup0.exe -p * | T / PMR {| T2 ^ LWJ *

Tenga en cuenta que la contraseña es diferente con cada muestra.

El contenido del RARSFX se extrae luego en % TMP% RarSFX0 y consta de los siguientes archivos:

  • CrLnc.dat – Carga útil cifrada
  • Duser.dll – Utilizado para derivación UAC
  • osksupport.dll – Utilizado para derivación UAC
  • PrintDialog.dll – Utilizado para la inicialización del procesador de impresión malicioso
  • PrintDialog.exe – Ejecutable legítimo de Windows utilizado para cargar PrintDialog.dll
  • setup.dll – DLL de instalación
  • setup.exe – Ejecutable principal

Tenga en cuenta que en el caso de una colisión de nombre de carpeta, el número al final de RarSFX0 la cadena se incrementa hasta que se evita una colisión. Además, no todos estos archivos están necesariamente presentes en el archivo, dependiendo del instalador.

Una vez extraído setup.exe Se ejecuta sin argumentos. Su único propósito es cargar setup.dll utilizando LoadLibraryA. Una vez cargado, setup.dll comprueba si un argumento en el formato –X: n (dónde norte es un entero) fue proporcionado; el modo de operación será diferente dependiendo de la presencia de norte. Los argumentos admitidos y su comportamiento correspondiente se muestran en la Tabla 1. setup.exe RARSFX lo ejecuta sin argumentos y comprueba si se está ejecutando con privilegios elevados. De lo contrario, intentará obtener tales privilegios utilizando suplantación de token si la versión de Windows está por debajo de Windows 7, compilación 7601; de lo contrario intentará diferente Técnicas de derivación UAC, permitiendo la instalación del cargador de carga útil en uno de:

  • C: Windows System32 spool prtprocs x64 DEment.dll
  • C: Windows System32 spool prtprocs x64 EntAppsvc.dll
  • C: Windows System32 spool prtprocs x64 Interactive.dll

Dependiendo de la variante. Tenga en cuenta que no pudimos recuperar muestras relacionadas con Interactive.dll.

Tabla 1. setup.exe argumentos soportados y su comportamiento correspondiente.

Valor de argumento de línea de comando Comportamiento
-x: 0 Cargue el cargador de carga útil.
-x: 1 Intenta habilitar SeLoadDriverPrivilege para el proceso actual Si tiene éxito, intente instalar el cargador de carga útil; de lo contrario, reinicie setup.exe con el –X: 2 argumento utilizando la suplantación de procesos padre.
-x: 2 Intenta habilitar SeLoadDriverPrivilege para el proceso actual Si tiene éxito, intente instalar el cargador de carga útil.

Este cargador se almacena encriptado dentro de setup.dll, que lo descifrará antes de escribirlo en la ubicación mencionada anteriormente.

Persistencia utilizando procesadores de impresión de Windows

La ubicación donde se descarta la DLL maliciosa no se eligió al azar. Este es el camino donde Procesadores de impresión de Windows están ubicados y setup.dll registra el cargador DLL malicioso como un procesador de impresión alternativo estableciendo uno de los siguientes valores de registro:

HKLM SYSTEM ControlSet001 Control Print Environments Windows x64 Print Processors PrintFiiterPipelineSvc Driver = “DEment.dll”

o

HKLM SYSTEM CurrentControlSet Control Print Environments Windows x64 Print Processors lltdsvc1 Driver = “EntAppsvc.dll”

Dependiendo de la variante. Tenga en cuenta el error tipográfico en PrintFiiterPipelineSvc (que no tiene ningún impacto en la instalación del procesador de impresión ya que se puede usar cualquier nombre).

Después de haber registrado el procesador de impresión, PipeMon reinicia el servicio de cola de impresión (spoolsv.exe) Como resultado, el proceso de impresión maliciosa se carga cuando se inicia el servicio de cola. Tenga en cuenta que el servicio Print Spooler se inicia en cada inicio de PC, lo que garantiza la persistencia en todos los reinicios del sistema.

Esta técnica es realmente similar a la Técnica de persistencia del monitor de impresión (siendo utilizado por DePriMon, por ejemplo) y, hasta donde sabemos, no ha sido documentado previamente.

Además, la carga útil cifrada, CrLnc.dat, extraído del RARSFX se escribe en el registro en la siguiente ubicación, según el instalador:

  • HKLM SOFTWARE Microsoft Print Components DC20FD7E-4B1B-4B88-8172-61F0BED7D9E8
  • HKLM SOFTWARE Microsoft Print Components A66F35-4164-45FF-9CB4-69ACAA10E52D

Esta carga útil de registro cifrada es cargada, descifrada y ejecutada por la biblioteca del procesador de impresión previamente registrada. Toda la estadificación y persistencia de PipeMon se muestra en la Figura 1.

Figura 1. Estadificación y persistencia de PipeMon

PipeMon

Llamamos a este nuevo implante PipeMon porque usa múltiples tuberías con nombre para la comunicación entre módulos y, según su ruta PDB, el nombre del proyecto de Visual Studio utilizado por su desarrollador es "Monitor".

Como se mencionó anteriormente, se encontraron dos variantes diferentes de PipeMon. Teniendo en cuenta la primera variante, no pudimos recuperar el instalador; por lo tanto, no sabemos con certeza la técnica de persistencia que se utilizó. Pero teniendo en cuenta que esta primera variante de PipeMon también se encuentra en el directorio del procesador de impresión, es probable que se haya utilizado el mismo mecanismo de persistencia.

Variante original

PipeMon es una puerta trasera modular donde cada módulo es un archivo DLL único que exporta una función llamada IntelLoader y se carga usando un carga reflectante técnica. Cada módulo exhibe diferentes funcionalidades que se muestran en la Tabla 2.

El cargador, responsable de cargar los módulos principales (ManagerMain y GuardClient) es Win32CmdDll.dll y se encuentra en el directorio Procesadores de impresión. Los módulos se almacenan encriptados en el disco en la misma ubicación con nombres de aspecto inofensivo como:

  • banner.bmp
  • certificado.cert
  • License.hwp
  • JSONDIU7c9djE
  • D8JNCKS0DJE
  • B0SDFUWEkNCj.logN

Tenga en cuenta que .hwp es la extensión utilizada por el procesador de textos Hangul de Hangul Office, que es muy popular en Corea del Sur.

Los módulos están encriptados RC4 y la clave de descifrado Com! 123Qasdz está codificado en cada módulo. Win32CmDll.dll descifra e inyecta los módulos ManagerMain y GuardClient. El módulo ManagerMain es responsable de descifrar e inyectar el módulo de comunicación, mientras que el módulo GuardClient se asegurará de que el módulo de comunicación se esté ejecutando y lo volverá a cargar si es necesario. En la Figura 2 se muestra una descripción general de cómo funciona PipeMon.

Win32CmDll.dll primero intenta inyectar los módulos ManagerMain y GuardClient en un proceso con uno de los siguientes nombres: lsass.exe, wininit.exe o lsm.exe. Si eso falla, intenta inyectar en uno de los procesos de servicios de Windows registrados, excluyendo los procesos nombrados spoolsv.exe, ekrn.exe (ESET), avp.exe (Kaspersky) o dllhost.exe. Como última opción, si todo lo demás falla, intenta utilizar los procesos. taskhost.exe, taskhostw.exe o explorer.exe.

Los candidatos de proceso para la inyección del módulo de comunicación deben estar en la tabla de conexión TCP con 0.0.0.0 como la dirección local, o una conexión ESTABLECIDA y que posee un token de SERVICIO LOCAL. Es probable que estas condiciones se usen para ocultar el módulo de comunicación en un proceso que ya se está comunicando a través de la red para que el tráfico del módulo de comunicación parezca discreto y posiblemente también incluido en la lista blanca en el firewall. Si ningún proceso cumple con los requisitos anteriores, el Gerente Principal módulo intenta inyectar el módulo de comunicación en explorer.exe. Procesos que pertenecen a las aplicaciones de la Tienda Windows y procesos denominados egui.exe (ESET) y avpui.exe (Kaspersky) se ignoran de la selección.

Tabla 2. Descripciones del módulo PipeMon y sus respectivas rutas PDB

Nombre del módulo Descripción PDB Path
Win32CmdDll Descifra y carga los módulos ManagerMain y GuardClient. S: Monitor Monitor_RAW Launcher x64 Release Win32CmdDll.pdb
S: Monitor Monitor_RAW libs x64 Release Win32CmdDll.pdb
GuardClient Comprueba periódicamente si el módulo de comunicación se está ejecutando y lo carga si no. S: Monitor Monitor_RAW Client x64 Release GuardClient.pdb
Gerente Principal Carga el módulo de comunicación cuando se ejecuta. Contiene el dominio C&C encriptado que se pasa al módulo de comunicación a través de un canal con nombre.
Puede ejecutar varios comandos en función de los datos recibidos del módulo de comunicación (en su mayoría, recopilación de información del sistema, inyección de cargas útiles).
S: Monitor Monitor_RAW Client x64 Release ManagerMain.pdb
Comunicación Responsable de gestionar la comunicación entre el servidor C&C y los módulos individuales a través de canalizaciones con nombre. S: Monitor Monitor_RAW Client x64 Release Communication.pdb
F: PCC trunk CommunicationClient x64 Release Communication.pdb

Los módulos adicionales se pueden cargar a pedido utilizando comandos dedicados (ver más abajo), pero desafortunadamente, no pudimos descubrir ninguno de ellos. Los nombres de estos módulos son una conjetura educada basada en las canalizaciones con nombre utilizadas para comunicarse con ellos:

  • Pantalla
  • Ruta
  • CMD
  • InCmd
  • Expediente

Comunicación entre módulos

La comunicación entre módulos se realiza a través de canales con nombre, utilizando dos canales con nombre por canal de comunicación entre cada módulo individual, uno para enviar y otro para recibir. La Tabla 3 enumera los canales de comunicación y sus correspondientes canalizaciones con nombre.

Tabla 3. Canal de comunicación PipeMon y sus respectivas canalizaciones con nombre

Canal de comunicación Tubo con nombre
Comunicación, pantalla \. pipe ScreenPipeRead% CNC_DEFINED%
\. pipe ScreenPipeWrite% CNC_DEFINED%
Comunicación, ruta \. pipe RoutePipeWriite% B64_TIMESTAMP%
Comunicación, Gerente Principal \. pipe MainPipeWrite% B64_TIMESTAMP%
\. pipe MainPipeRead% B64_TIMESTAMP%
GuardClient, ManagerMain \. pipe MainHeatPipeRead% B64_TIMESTAMP%
Comunicación, InCmd \. pipe InCmdPipeWrite% B64_TIMESTAMP%
\. pipe InCmdPipeRead% B64_TIMESTAMP%
Comunicación, archivo \. pipe FilePipeRead% B64_TIMESTAMP%
\. pipe FilePipeWrite% B64_TIMESTAMP%
GuardClient, Comunicación \. pipe ComHeatPipeRead% B64_TIMESTAMP%
Comunicación, CMD \. pipe CMDPipeRead
\. pipe CMDPipeWrite

los % CNC_DEFINED% la cadena se recibe del servidor C&C y % B64_TIMESTAMP% Las variables son marcas de tiempo codificadas en base64, como las que se muestran en la Tabla 4.

Tabla 4. Marcas de tiempo de ejemplo utilizadas con tuberías con nombre

% BASE64_TIMESTAMP% Marca de tiempo decodificada
MjAxOTAyMjgxMDE1Mzc = 20190228101537
MjAxOTA1MjEyMzU2MjQ = 20190521235624
MjAxOTExMjExMjE2MjY = 20191121121626

Figura 2. Esquema de PipeMon IPC (variante original de PipeMon)

Comunicación C&C

El módulo de comunicación es responsable de administrar las comunicaciones entre el servidor de C&C y los otros módulos a través de tuberías con nombre, similar a la puerta trasera PortReuse documentada en nuestro libro blanco sobre el arsenal de Winnti.

Su dirección C&C está codificada en el módulo ManagerMain y está encriptada usando RC4 con la clave codificada Com! 123Qasdz. Se envía al módulo de comunicación a través de una tubería con nombre.

Se crea un canal de comunicación separado para cada módulo instalado. El protocolo de comunicación utilizado es TLS sobre TCP. La comunicación se maneja con el Biblioteca HP-Socket. Todos los mensajes están encriptados con RC4 usando la clave codificada. Si el tamaño del mensaje a transferir es mayor o igual a 4KB, primero se comprime usando la implementación Deflate de zlib.


Figura 3. Mensaje de C&C y formatos de baliza

Para iniciar la comunicación con el servidor de C&C, primero se envía un mensaje de baliza que contiene la siguiente información:

  • versión del sistema operativo
  • direcciones físicas de adaptadores de red conectados concatenados con% B64_TIMESTAMP%
  • dirección IP local de la víctima
  • versión de puerta trasera / ID de campaña; hemos observado los siguientes valores
    • "1.1.1.4 latido"
    • "1.1.1.4Bata"
    • "1.1.1.5"
  • Nombre de la computadora de la víctima

La información sobre la máquina de la víctima es recopilada por el módulo ManagerMain y enviada al módulo de comunicación a través de la tubería con nombre. La versión de puerta trasera está codificada en el módulo de comunicación en texto sin formato.

El formato del mensaje de baliza se muestra en la Figura 3 y los comandos compatibles se muestran en la Tabla 5.

Tabla 5. Lista de comandos

Tipo de comando Argumento de comando Descripción
0x02 0x03 Instale el módulo de archivo
0x03 0x03 Instale el módulo CMD
0x03 0x0B Instale el módulo InCmd
0x04 0x02 Comando de cola para el módulo de ruta
0x04 0x03 Instale el módulo de ruta
0x05 * * Enviar información RDP de la víctima al servidor de C&C
0x06 0x05 Enviar información de SO, CPU, PC y zona horaria al servidor C&C
0x06 0x06 Enviar información de red al servidor de C&C
0x06 0x07 Enviar información de la unidad de disco al servidor C&C
0x07 * * Enviar información de procesos en ejecución al servidor de C&C
0x09 * * Inyección DLL
0x0C 0x15 Enviar nombres de tuberías y eventos "InCmd" al servidor de C&C
0x0C 0x16 Enviar el nombre de la tubería "Ruta" al servidor de C&C
0x0C 0x17 Enviar nombres de tuberías "Archivo" al servidor de C&C

* El argumento proporcionado para este tipo de comando se ignora

Variante actualizada

Como se mencionó anteriormente, los atacantes también usan una versión actualizada de PipeMon para la cual pudimos recuperar la primera etapa descrita anteriormente. Mientras exhibía una arquitectura muy similar a la variante original, su código probablemente fue reescrito desde cero.

El código RC4 utilizado para descifrar los módulos y las cadenas fue reemplazado por un simple XOR con 0x75E8EEAF ya que la clave y todas las cadenas codificadas fueron eliminadas. Las canalizaciones con nombre utilizadas para la comunicación entre módulos ahora se nombran utilizando valores aleatorios en lugar de nombres explícitos y se ajustan al formato \. pipe % rand%, dónde % rand% es una cadena de 31 caracteres generada al azar que contiene solo caracteres alfabéticos de mayúsculas y minúsculas.

Aquí, solo el cargador principal (es decir, la DLL maliciosa instalada como procesador de impresión) se almacena como un archivo en el disco; el instalador almacena los módulos en el registro (desde el CrLnc.dat archivo) y se describen en la Tabla 6.

Tabla 6. Módulos actualizados

Nombre del módulo Descripción
CoreLnc.dll Cargado por el procesador de impresión malicioso. Responsable solo de cargar el Core.dll módulo incrustado en su .datos sección.
Core.dll Carga el Net.dll módulo incrustado en su .datos sección. Maneja los comandos del servidor C&C y las comunicaciones entre módulos individuales y el servidor C&C a través de canalizaciones con nombre.
Net.dll Nuevo módulo de comunicación. Maneja las redes.

La inyección del módulo ya no se realiza utilizando la técnica de carga reflectante con una función de exportación; en su lugar se usa el shellcode del cargador personalizado y se inyecta junto con el módulo que se va a cargar.

El formato del mensaje C&C también se modificó y se muestra en la Figura 4.


Figura 4. Formato de mensaje C&C anterior (arriba) y actualizado (abajo)

Curiosamente, la configuración de la puerta trasera está encriptada e incrustada en la DLL del cargador. La configuración contiene:

  • Nombre del valor del registro.
  • Identificador de campaña
  • Direcciones IP o nombres de dominio de C&C
  • Marca de tiempo (en TIEMPO DE ARCHIVO formato) correspondiente a la fecha a partir de la cual comenzar a utilizar un segundo dominio de C&C marcado con "#" en la configuración.

En la Figura 5 se muestra un ejemplo de un volcado de configuración integrado en la DLL del cargador. Las configuraciones extraídas de varias DLL del cargador se muestran en la Tabla 7.

Figura 5. Ejemplo de configuración descifrada (con pocos bytes cero eliminados debido al tamaño de la imagen)

Tabla 7. Configuración extraída de varios cargadores

Cargador SHA-1 ID de campaña Nombre de registro de carga útil IP y dominios de C&C Marca de tiempo de activación de dominio alternativa
6c97039605f93ccf1afccbab8174d26a43f91b20 KOR2 DC20FD7E-4B1B-4B88-8172-61F0BED7D9E8 154.223.215.116
ssl2.dyn-tracker.com
# client.gnisoft.com
0x01d637a797cf0000 (Lunes 1 de junio de 2020 12:00:00 a.m.)
97da4f938166007ce365c29e1d685a1b850c5bb0 KOR DC20FD7E-4B1B-4B88-8172-61F0BED7D9E8 203.86.239.113 ssl2.dyn-tracker.com # client.gnisoft.com 0x01d637a797cf0000 (Lunes 1 de junio de 2020 12:00:00 a.m.)
7ca43f3612db0891b2c4c8ccab1543f581d0d10c kor1 DC20FD7E-4B1B-4B88-8172-61F0BED7D9E8 203.86.239.113
www2.dyn.tracker.com (tenga en cuenta el error tipográfico aquí: dyn.tracker en lugar de dyn-tracker) # nmn.nhndesk.com
0x01d61f4b7500c000 (Viernes 1 de mayo de 2020 12:00:00 a.m.)
b02ad3e8b1cf0b78ad9239374d535a0ac57bf27e tw1 A66F35-4164-45FF-9CB4-69ACAA10E52D ssl.lcrest.com

Certificado de firma de código robado

Los módulos e instaladores de PipeMon están firmados con el mismo certificado de firma de código válido que probablemente fue robado durante una campaña anterior del Grupo Winnti. El propietario del certificado lo revocó tan pronto como se le notificó el problema.

Figura 6. Certificado de firma de código utilizado para firmar PipeMon primera etapa y módulos antes (arriba) y después (abajo) de revocación.

Encontramos en una plataforma de intercambio de muestras otras herramientas firmadas con este certificado, como HTRan, un gorila de conexión, el WinEggDrop escáner de puertos, Netcat y Mimikatz que también podrían haber sido utilizados por los atacantes.

Además, una compilación AceHash personalizada firmada con un certificado robado Wemade IO ya mencionado en nuestro libro blanco anterior y generalmente utilizado por el Grupo Winnti se encontró en algunas máquinas comprometidas con PipeMon.

Conclusión

Una vez más, el Grupo Winnti se ha dirigido a los desarrolladores de videojuegos en Asia con una nueva puerta trasera modular firmada con un certificado de firma de código probablemente robado durante una campaña anterior y que comparte algunas similitudes con la puerta trasera PortReuse. Este nuevo implante muestra que el Grupo Winnti todavía está desarrollando activamente nuevas herramientas utilizando múltiples proyectos de código abierto; no confían únicamente en sus puertas traseras insignia, ShadowPad y el malware Winnti.

Continuaremos monitoreando nuevas actividades del Grupo Winnti y publicaremos información relevante en nuestro blog. Para cualquier consulta, contáctenos en amenazaintel@eset.com. Los IoC también están disponibles en nuestro repositorio GitHub.

Indicadores de compromiso

Nombres de detección de ESET

Win64 / PipeMon.A
Win64 / PipeMon.B
Win64 / PipeMon.C
Win64 / PipeMon.D
Win64 / PipeMon.E

Nombres de archivo

100.exe
103.exe
Slack.exe
setup.exe
% SYSTEM32% spool prtprocs x64 DEment.dll
% SYSTEM32% spool prtprocs x64 EntAppsvc.dll
% SYSTEM32% spool prtprocs x64 Interactive.dll
% SYSTEM32% spool prtprocs x64 banner.bmp
% SYSTEM32% spool prtprocs x64 certificate.cert
% SYSTEM32% spool prtprocs x64 banner.bmp
% SYSTEM32% spool prtprocs x64 License.hwp
% SYSTEM32% spool prtprocs x64 D8JNCKS0DJE
% SYSTEM32% spool prtprocs x64 B0SDFUWEkNCj.log
% SYSTEM32% spool prtprocs x64 K9ds0fhNCisdjf
% SYSTEM32% spool prtprocs x64 JSONDIU7c9djE
% SYSTEM32% spool prtprocs x64 NTFSSSE.log
AceHash64.exe
mz64x.exe

Tubos con nombre

\. pipe ScreenPipeRead% CNC_DEFINED%
\. pipe ScreenPipeWrite% CNC_DEFINED%
\. pipe RoutePipeWriite% B64_TIMESTAMP%
\. pipe MainPipeWrite% B64_TIMESTAMP%
\. pipe MainPipeRead% B64_TIMESTAMP%
\. pipe MainHeatPipeRead% B64_TIMESTAMP%
\. pipe InCmdPipeWrite% B64_TIMESTAMP%
\. pipe InCmdPipeRead% B64_TIMESTAMP%
\. pipe FilePipeRead% B64_TIMESTAMP%
\. pipe FilePipeWrite% B64_TIMESTAMP%
\. pipe ComHeatPipeRead% B64_TIMESTAMP%
\. pipe CMDPipeRead
\. pipe CMDPipeWrite

Registro

HKLM SYSTEM ControlSet001 Control Print Environments Windows x64 Print Processors PrintFiiterPipelineSvc Driver = “DEment.dll”

HKLM SYSTEM CurrentControlSet Control Print Environments Windows x64 Print Processors lltdsvc1 Driver = “EntAppsvc.dll”

HKLM SOFTWARE Microsoft Print Components DC20FD7E-4B1B-4B88-8172-61F0BED7D9E8
HKLM SOFTWARE Microsoft Print Components A66F35-4164-45FF-9CB4-69ACAA10E52D

Muestras

Primera etapa

4B90E2E2D1DEA7889DC15059E11E11353FA621A6
C7A9DCD4F9B2F26F50E8DD7F96352AEC7C4123FE
3508EB2857E279E0165DE5AD7BBF811422959158
729D526E75462AA8D33A1493B5A77CB28DD654BC
5663AF9295F171FDD41A6D819094A5196920AA4B

PipeMon

23789B2C9F831E385B22942DBC22F085D62B48C7
53C5AE2655808365F1030E1E06982A7A6141E47F
E422CC1D7B2958A59F44EE6D1B4E10B524893E9D
5BB96743FEB1C3375A6E2660B8397C68BEF4AAC2
78F4ACD69DC8F9477CAB9C732C91A92374ADCACD
B56D8F826FA8E073E6AD1B99B433EAF7501F129E
534CD47EB38FEE7093D24BAC66C2CF8DF24C7D03

Binarios cifrados de PipeMon

168101B9B3B512583B3CE6531CFCE6E5FB581409
C887B35EA883F8622F7C48EC9D0427AFE833BF46
44D0A2A43ECC8619DE8DB99C1465DB4E3C8FF995
E17972F1A3C667EEBB155A228278AA3B5F89F560
C03BE8BB8D03BE24A6C5CF2ED14EDFCEFA8E8429
2B0481C61F367A99987B7EC0ADE4B6995425151C

Herramientas adicionales

WinEggDrop

AF9C220D177B0B54A790C6CC135824E7C829B681

Mimikatz

4A240EDEF042AE3CE47E8E42C2395DB43190909D
FD4567BB77F40E62FD11BEBF32F4C9AC00A58D53

Netcat

751A9CBFFEC28B22105CDCAF073A371DE255F176

HTran

48230228B69D764F71A7BF8C08C85436B503109E

AceHash

D24BBB898A4A301870CAB85F836090B0FC968163

Huellas digitales del certificado de firma de código SHA-1

745EAC99E03232763F98FB6099F575DFC7BDFAA3
2830DE648BF0A521320036B96CE0D82BEF05994C

Dominios C&C

n8.ahnlabinc (.) com
owa.ahnlabinc (.) com
ssl2.ahnlabinc (.) com
www2.dyn.tracker (.) com
ssl2.dyn-tracker (.) com
client.gnisoft (.) com
nmn.nhndesk (.) com

Direcciones IP de C&C

154.223.215 (.) 116
203.86.239 (.) 113

Táctica CARNÉ DE IDENTIDAD Nombre Descripción
Persistencia T1013 Monitor de puerto PipeMon utiliza una técnica de persistencia similar a Port Monitor basada en procesadores de impresión.
Escalada de privilegios T1134 Manipulación de tokens de acceso El instalador de PipeMon intenta obtener privilegios administrativos mediante la suplantación de token.
T1088 Omitir control de cuenta de usuario El instalador de PipeMon utiliza técnicas de derivación de UAC para instalar la carga útil.
T1502 Spoofing PID para padres El instalador de PipeMon utiliza la suplantación de PID principal para elevar los privilegios.
Evasión de defensa T1116 Firma de código PipeMon, su instalador y herramientas adicionales están firmados con certificados de firma de código robados.
T1027 Ofuscar archivos o información Los módulos PipeMon se almacenan encriptados en el disco.
T1112 Modificar registro El instalador de PipeMon modifica el registro para instalar PipeMon como un procesador de impresión.
T1055 Inyección de proceso PipeMon inyecta sus módulos en varios procesos mediante carga reflectante.
Descubrimiento T1057 Descubrimiento de procesos PipeMon itera sobre los procesos en ejecución para encontrar un objetivo de inyección adecuado.
T1063 Descubrimiento de software de seguridad PipeMon verifica la presencia del software ESET y Kaspersky.
Colección T1113 La captura de pantalla Es probable que uno de los módulos PipeMon sea un capturador de pantalla.
Comando y control T1043 Puertos de uso común PipeMon se comunica a través del puerto 443.
T1095 Comando personalizado y protocolo de control El módulo de comunicación PipeMon utiliza un protocolo personalizado basado en TLS sobre TCP.
T1032 Protocolo criptográfico estándar La comunicación PipeMon está encriptada RC4.
T1008 Canales de reserva La versión actualizada de PipeMon usa un canal de reserva una vez que se alcanza una fecha en particular.



y





Enlace a la noticia original