Bajo SADBRIDGE con GOSAR: QUASAR obtiene una reescritura de Golang

Introducción

Elastic Security Labs observó recientemente un nuevo conjunto de intrusiones dirigidas a regiones de habla china, rastreadas como REF3864. Estas campañas organizadas se dirigen a las víctimas hacer pasar por software legítimo, como navegadores sitio web o servicios de mensajería en redes sociales. El grupo de amenazas detrás de estas campañas muestra un grado moderado de versatilidad al distribuir malware en múltiples plataformas como Linux, Windows y Android. Durante esta investigación, nuestro equipo descubrió una cadena de infección única de Windows con un cargador personalizado que llamamos SADBRIDGE. Este cargador implementa una reimplementación de QUASAR basada en Golang, a la que nos referimos como GOSAR. Esta es la primera vez que nuestro equipo observa una reescritura de QUASAR en el lenguaje de programación Golang.

Conclusiones clave

• Campañas en curso dirigidas a hablantes de chino con instaladores maliciosos que se hacen pasar por software legítimo como Telegram y el navegador sitio web Opera.
• Las cadenas de infección emplean inyección y carga lateral de DLL mediante un cargador personalizado (SADBRIDGE)
• SADBRIDGE implementa una variante recién descubierta de la puerta trasera QUASAR escrita en Golang (GOSAR)
• GOSAR es una puerta trasera multifuncional en desarrollo activo con funciones incompletas e iteraciones de funciones mejoradas observadas a lo largo del tiempo.
• Elastic Security proporciona capacidades integrales de prevención y detección contra esta cadena de ataques.

Descripción general de la campaña REF3864

En noviembre, el equipo de Elastic Security Labs observó una cadena de infección única al detonar varias muestras diferentes cargadas en VirusTotal. Estas diferentes muestras fueron alojadas a través de páginas de destino que se hacían pasar por software legítimo, como Telegram o el navegador Opera GX.

Durante esta investigación, descubrimos múltiples cadenas de infección que involucraban técnicas similares:

• Instaladores MSI troyanizados con bajas detecciones
• Enmascaramiento mediante software legítimo incluido con DLL maliciosas
• Cargador SADBRIDGE personalizado implementado
• Etapa final GOSAR cargado

Creemos que estas campañas pasaron desapercibidas debido a múltiples niveles de abstracción. Normalmente, la primera fase implica abrir un archivo comprimido (ZIP) que incluye un instalador MSI. Se emplea software legítimo como la aplicación de depuración de Windows x64dbg.exe en segundo plano para cargar una DLL maliciosa y parcheada (x64bridge.dll). Esta DLL inicia un nuevo programa legítimo (MonitoringHost.exe) donde carga de forma lateral otra DLL maliciosa (HealthServiceRuntime.dll), realizando en última instancia la inyección y cargando el implante GOSAR en la memoria a través de la inyección.

Los investigadores de malware extrajeron configuraciones de SADBRIDGE que revelan fechas de campaña designadas por el adversario e indican que se llevaron a cabo operaciones con TTP similares desde al menos diciembre de 2023. La infraestructura de comando y control (C2) de GOSAR a menudo se disfraza de servicios o software confiables para parecer benigna y ajustar a las expectativas de las víctimas respecto de los instaladores de software. A lo largo de la cadena de ejecución, hay un enfoque centrado en enumerar productos AV chinos como 360tray.exe, junto con nombres de reglas de firewall y descripciones en chino. Debido a estas personalizaciones, creemos que esta amenaza está dirigida a los hablantes del idioma chino. Además, el uso extensivo de registros en idioma chino indica que los atacantes también hablan ese idioma.

QUASAR se empleó anteriormente en espionaje patrocinado por estados, hacktivismo no estatal y ataques criminales con motivaciones financieras desde 2017 (Qualys, Evolution of Quasar RAT), incluido APT10 vinculado a China. Una reescritura en Golang podría aprovechar el conocimiento institucional adquirido durante este periodo, permitiendo capacidades adicionales sin tener que volver a capacitar extensamente a los TTP que anteriormente eran efectivos.

GOSAR amplía QUASAR con capacidades adicionales de recopilación de información, compatibilidad con múltiples sistemas operativos y evasión mejorada contra productos antivirus y clasificadores de malware. Sin embargo, los sitios web de señuelos genéricos y la falta de información adicional sobre la orientación o las acciones en función del objetivo nos dejan con evidencia insuficiente para identificar las motivaciones de los atacantes.

Introducción a SADBRIDGE

El cargador de malware SADBRIDGE está empaquetado como un ejecutable MSI para su distribución y emplea carga lateral de DLL con varias técnicas de inyección para ejecutar cargas útiles maliciosas. SADBRIDGE abusa de aplicaciones legítimas como x64dbg.exe y MonitoringHost.exe para cargar DLL maliciosas como x64bridge.dll y HealthServiceRuntime.dll, lo que conduce a etapas y códigos de shell posteriores.

La persistencia se logra mediante la creación de servicios y modificaciones de registros. La escalada de privilegios al Administrador se produce de forma silenciosa mediante una técnica de omisión de UAC que abusa de la interfaz COM ICMLuaUtil . Además, SADBRIDGE incorpora una función para evitar la escalada de privilegios a través del Programador de tareas de Windows para ejecutar su carga principal con privilegios de nivel de SISTEMA.

La configuración de SADBRIDGE se cifra mediante una simple resta de 0x1 en cada byte de la cadena de configuración. A todas las etapas cifradas se les agrega una extensión .log y se descifran durante el tiempo de ejecución empleando XOR y el algoritmo de descompresión LZNT1.

SADBRIDGE emplea PoolParty, colas APC y técnicas de manipulación de tokens para la inyección de procesos. Para evitar el análisis de sandbox, emplea llamadas API Sleep largas. Otra técnica de evasión de defensa implica aplicar parches a la API para deshabilitar los mecanismos de seguridad de Windows, como la Interfaz de escaneo antimalware (AMSI) y el Seguimiento de eventos para Windows (ETW).

El siguiente análisis profundo está estructurado para explorar la cadena de ejecución, proporcionando un recorrido paso a paso de las capacidades y funcionalidades de archivos y etapas importantes, según la configuración de la muestra analizada. El análisis tiene como objetivo resaltar la interacción entre cada componente y sus funciones para alcanzar la carga útil final.

Análisis del código SADBRIDGE

Análisis MSI

Los archivos iniciales se empaquetan en un MSI mediante Advanced Installer, los principales archivos de interés son x64dbg.exe y x64bridge.dll.

Al usar herramientas MSI (lessmsi), podemos ver que el punto de entrada LaunchApp en aicustact.dll está configurado para ejecutar la ruta de archivo especificada en la propiedad AI_APP_FILE .

Si navegamos a esta propiedad AI_APP_FILE , podemos ver que el archivo vinculado a esta configuración es x64dbg.exe. Esto representa el archivo que se ejecutará una vez completada la instalación, el legítimo NetFxRepairTool.exe nunca se ejecuta.

Carga lateral de x64bridge.dll

Cuando se ejecuta x64dbg.exe , llama a la exportación BridgeInit desde x64bridge.dll. BridgeInit es un contenedor para la función BridgeStart .

De manera similar a las técnicas observadas con BLISTER, SADBRIDGE repara la exportación de una DLL legítima.

Durante la rutina de inicialización del malware, SADBRIDGE comienza generando un hash empleando el nombre de host y una semilla mágica 0x4E67C6A7. Este hash se emplea como nombre de directorio para almacenar el archivo de configuración cifrado. La configuración cifrada se escribe en C:\Users\Public\Documents\<hostname_hash>\edbtmp.log. Este archivo contiene los atributos FILE_ATTRIBUTE_SYSTEM, FILE_ATTRIBUTE_READONLY, FILE_ATTRIBUTE_HIDDEN para ocultar de una lista de directorio normal.

Descifrar la configuración es sencillo, los fragmentos cifrados están separados por bytes nulos. Para cada byte dentro de los fragmentos cifrados, podemos incrementarlos en 0x1.

La configuración consta de:

• Posible fecha de campaña
• Cadenas que se emplearán para crear servicios
• Nuevo nombre para MonitoringHost.exe (DevQueryBroker.exe)
• Nombre de la DLL que se va a cargar lateralmente mediante MonitoringHost.exe (HealthServiceRuntime.dll)
• Rutas absolutas para etapas adicionales (archivos .log )
• El objetivo de inyección principal para alojar GOSAR (svchost.exe)

El directorio DevQueryBroker (C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\) contiene todas las etapas cifradas (archivos .log ) que se descifran en tiempo de ejecución. El archivo (DevQueryBroker.exe) es una copia renombrada de la aplicación legítima de Microsoft (MonitoringHost.exe).

Finalmente, crea un proceso para ejecutar DevQueryBroker.exe que carga el HealthServiceRuntime.dll malicioso en la misma carpeta.

HealthServiceRuntime.dll

Este módulo coloca un shellcode cifrado y parcialmente descifrado en el directorio %TEMP% del usuario. El nombre del archivo para el shellcode sigue el formato: log<random_string>.tmp. Luego, cada byte del shellcode parcialmente descifrado se decrementa en 0x10 para descifrarlo completamente. El shellcode se ejecuta en un nuevo hilo del mismo proceso.

El malware aprovecha el hash API empleando el mismo algoritmo que aparece en la investigación publicada por SonicWall; el algoritmo hash aparece en la sección Apéndice. El shellcode descifra DevQueryBroker.log en un archivo PE y luego realiza una operación XOR simple con un solo byte (0x42) en el primer tercio del archivo donde luego descomprime el resultado empleando el algoritmo LZNT1.

Luego, el shellcode desasigna cualquier asignación existente en la dirección base preferida del archivo PE usando NtUnmapViewOfSection, lo que garantiza que una llamada a VirtualAlloc asignará memoria comenzando en la dirección base preferida. Finalmente, asigna el archivo PE descifrado a esta memoria asignada y transfiere la ejecución a su punto de entrada. Todos los códigos shell identificados y ejecutados por SADBRIDGE comparten una estructura de código idéntica, diferenciar únicamente en los archivos .log específicos a los que hacen referencia para su descifrado y ejecución.

Registro de DevQueryBroker

El malware carga dinámicamente amsi.dll para deshabilitar mecanismos de seguridad críticos en Windows. Parchea AmsiScanBuffer en amsi.dll insertando instrucciones para modificar el valor de retorno a 0x80070057, el código de error estandarizado de Microsoft E_INVALIDARG que indica argumentos no válidos y regresa prematuramente para evitar efectivamente la lógica de escaneo. De manera similar, parchea AmsiOpenSession para que siempre devuelva el mismo código de error E_INVALIDARG. Además, parchea EtwEventWrite en ntdll.dll, reemplazando la primera instrucción con una instrucción ret para deshabilitar el Seguimiento de eventos para Windows (ETW), suprimiendo cualquier registro de actividad maliciosa.

Luego de aplicar el parche, se escribe un código shell cifrado en temp.ini en la ruta (C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\temp.ini).
El malware verifica la membresía del grupo del token del proceso actual para determinar su nivel de privilegio. Verifica si el proceso pertenece a la cuenta LocalSystem inicializando un SID con SECURITY_LOCAL_SYSTEM_RID y llamando CheckTokenMembership. En caso contrario, intenta verificar la membresía en el grupo Administradores creando un SID usando SECURITY_BUILTIN_DOMAIN_RID y DOMAIN_ALIAS_RID_ADMINS y realizando una verificación de membresía de token similar.

Si el proceso actual no tiene privilegios de Sistema local o Administrador, los privilegios se elevan primero a Administrador a través de un mecanismo de omisión de UAC aprovechando la interfaz COM ICMLuaUtil . Crea una cadena de nombre "Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}" para crear una instancia del objeto CMSTPLUA con privilegios de administrador. Una vez que se crea el objeto y se obtiene la interfaz ICMLuaUtil , el malware emplea el método ShellExec expuesto de la interfaz para ejecutar DevQueryBroker.exe.

Si una tarea o un servicio no se crea para ejecutar DevQueryBroker.exe de forma rutinaria, el malware verifica si el proceso antivirus 360tray.exe se está ejecutando. Si no se está ejecutando, se crea un servicio para la escalada de privilegios a SISTEMA, con las siguientes propiedades:

• Nombre del servicio: DevQueryBrokerService
  Nombre de ruta binaria: “C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\DevQueryBroker.exe -svc”.
• Nombre para mostrar: Servicio de agente de descubrimiento en segundo plano de DevQuery
• Descripción: Permite que las aplicaciones descubran dispositivos con una tarea en segundo plano.
• Tipo de inicio: Automáticamente al arrancar el sistema
• Privilegios: Sistema local

Si se detecta que 360tray.exe está ejecutar, el malware escribe un archivo PE cifrado en DevQueryBrokerService.log y luego asigna un archivo PE de la siguiente etapa (Etapa 1) a la memoria del proceso actual y le transfiere la ejecución.

Una vez que DevQueryBroker.exe se vuelve a activar con privilegios de nivel de SISTEMA y llega a esta parte de la cadena, el malware verifica la versión de Windows. Para los sistemas que ejecutan Vista o posterior (excluyendo Windows 7), asigna otra etapa siguiente (Etapa 2) a la memoria y transfiere la ejecución allí.

Sin embargo, en Windows 7, ejecuta un código shell que descifra y ejecuta el archivo DevQueryBrokerPre.log .

Inyección de etapa 1 (explorer.exe)

SADBRIDGE emplea la variante 7 de PoolParty para inyectar código shell en explorer.exe apuntando a la cola de finalización de E/S de su grupo de subprocesos. Primero duplica un identificador para la cola de finalización de E/S del proceso de destino. Luego asigna memoria dentro de explorer.exe para almacenar el shellcode. Se asigna memoria adicional para almacenar una estructura TP_DIRECT diseñada, que incluye la dirección base del shellcode como dirección de devolución de llamada. Finalmente, llama a ZwSetIoCompletion y pasa un puntero a la estructura TP_DIRECT para poner en cola un paquete en la cola de finalización de E/S de la fábrica de trabajadores del proceso de destino (administrador de subprocesos de trabajo), activando efectivamente la ejecución del shellcode inyectado.

Este código shell descifra el archivo DevQueryBrokerService.log , desasigna cualquier región de memoria que ocupe su dirección base preferida, asigna el archivo PE a esa dirección y luego ejecuta su punto de entrada. Este comportamiento refleja el código shell observado anteriormente.

Inyección de etapa 2 (spoolsv.exe/lsass.exe)

Para la Etapa 2, SADBRIDGE inyecta código shell en spoolsv.exe, o lsass.exe si spoolsv.exe no está disponible, empleando la misma técnica de inyección que en la Etapa 1. El shellcode exhibe un comportamiento similar a las etapas anteriores: descifra DevQueryBrokerPre.log en un archivo PE, desasigna cualquier región que ocupe su dirección base preferida, asigna el archivo PE y luego transfiere la ejecución a su punto de entrada.

DevQueryBrokerService.log

El código shell descifrado de DevQueryBrokerService.log como se mencionó en la sección anterior aprovecha una técnica de escalada de privilegios mediante el Programador de tareas de Windows. SADBRIDGE integra una técnica de omisión de UAC pública empleando el objeto COM IElevatedFactorySever para crear indirectamente la tarea programada. Esta tarea está configurada para ejecutar DevQueryBroker.exe diariamente con privilegios de nivel de SISTEMA empleando el nombre de tarea DevQueryBrokerService.

Para ocultar sus huellas, el malware falsifica la ruta de la imagen y la línea de comandos modificando directamente el bloque de entorno de proceso (PEB), probablemente en un intento de disfrazar el servicio COM como si viniera de explorer.exe.

Registro DevQueryBrokerPre

SADBRIDGE crea un servicio llamado DevQueryBrokerServiceSvc bajo la subclave de registro SYSTEM\CurrentControlSet\Services\DevQueryBrokerServiceSvc con los siguientes atributos:

• Descripción: Permite que las aplicaciones descubran dispositivos con una tarea en segundo plano.
• Nombre para mostrar: Servicio de agente de descubrimiento en segundo plano de DevQuery
• Control de errores: 1
• Ruta de la imagen: %systemRoot%\system32\svchost.exe -k netsvcs
• Nombre del objeto: Sistema local
• Inicio: 2 (inicio automático)
• Tipo: 16.
• Acciones en caso de fallo:
  • Restablece el recuento de fallas cada 24 horas.
  • Ejecuta tres intentos de resetear: un retraso de 20 ms para el primero y un retraso de 1 minuto para el segundo y el tercero.

Los parámetros del servicio especifican el ServiceDll ubicado en C:\Program Files (x86)\Common Files\Microsoft Shared\Stationery\<hostname_hash>\DevQueryBrokerService.dll. Si el archivo DLL no existe, se colocará en el disco inmediatamente después.

DevQueryBrokerService.dll tiene una estructura de código similar a HealthServiceRuntime.dll, que se ve en las primeras etapas de la cadena de ejecución. Es responsable de descifrar DevQueryBroker.log y ejecutarlo. El ServiceDll será cargado y ejecutado por svchost.exe cuando se inicie el servicio.

Además, modifica la clave SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs para incluir una entrada para DevQueryBrokerServiceSvc para integrar el servicio recién creado en el grupo de servicios gestionados por el grupo de host de servicios netsvcs .

Luego, SADBRIDGE elimina la tarea programada y el servicio creado previamente eliminando las subclaves de registro SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tree\\DevQueryBrokerService y SYSTEM\\CurrentControlSet\\Services\\DevQueryBrokerService.

Finalmente, elimina los archivos DevQueryBroker.exe y HealthServiceRuntime.dll en la carpeta C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker , ya que el nuevo mecanismo de persistencia está en su lugar.

Inyección de GOSAR

En la segunda mitad del código, SADBRIDGE enumera todas las sesiones activas en la máquina local empleando la API WTSEnumerateSessionsA .

Si se encuentran sesiones, se itera a través de cada sesión:

• Para cada sesión, intenta recuperar el nombre de usuario (WTSUserName) empleando WTSQuerySessionInformationA. Si la consulta falla, pasa a la siguiente sesión.
• Si WTSUserName no está vacío, el código apunta a svchost.exe y pasa su ruta, el ID de sesión y el contenido de la configuración del cargador a una subrutina que inyecta la etapa final.
• Si WTSUserName está vacío pero el WinStationName de la sesión es "Services" (lo que indica una sesión de servicio), apunta a dllhost.exe en su lugar y pasa los mismos parámetros a la subrutina de inyección de la etapa final.

Si no se encuentran sesiones, entra en un bucle infinito para enumerar sesiones repetidamente e invocar la subrutina para inyectar la etapa final, mientras realiza verificaciones para evitar inyecciones redundantes.

Las sesiones iniciadas con sesión iniciada tienen como objetivo svchost.exe, mientras que las sesiones de servicio o las sesiones sin un usuario iniciado con sesión iniciada tienen como objetivo dllhost.exe.

Si hay un ID de sesión disponible, el código intenta duplicar el token de usuario para esa sesión y elevar el nivel de integridad del token duplicado a S-1-16-12288 (integridad del sistema). Luego emplea el token elevado para crear un proceso secundario (svchost.exe o dllhost.exe) a través de CreateProcessAsUserA.

Si la manipulación del token falla o no hay ninguna ID de sesión disponible (los procesos del sistema pueden tener una ID de sesión de 0), se recurre a la creación de un proceso sin un token usando CreateProcessA.

El código shell cifrado C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\temp.ini se descifra empleando la misma técnica de descompresión XOR y LZNT1 vista anteriormente para descifrar archivos .log , y se emplea la inyección APC para poner en cola el código shell para su ejecución en el hilo del proceso recién creado.

Finalmente, el shellcode inyectado descifra DevQueryBrokerCore.log a GOSAR y lo ejecuta en la memoria del proceso recién creado.

Introducción a GOSAR

GOSAR es un troyano de acceso remoto multifuncional que ataca sistemas Windows y Linux. Esta puerta trasera incluye capacidades como recuperar información del sistema, tomar capturas de pantalla, ejecutar comandos, registrar teclas y mucho más. La puerta trasera GOSAR conserva gran parte de la funcionalidad y el comportamiento principales de QUASAR, aunque incorpora varias modificaciones que la diferencian de la versión original.

Al reescribir el malware en lenguajes modernos como Go, se pueden ofrecer tasas de detección reducidas, ya que muchas soluciones antivirus y clasificadores de malware tienen dificultades para identificar características/cadenas maliciosas en estas nuevas construcciones de programación. A continuación se muestra un buen ejemplo de un GOSAR descomprimido que recibe solo 5 detecciones al cargar.

En individuo, esta variante admite múltiples plataformas, incluidos binarios ELF para sistemas Linux y archivos PE tradicionales para Windows. Esta capacidad multiplataforma se alinea con la adaptabilidad de Go, haciéndolo más versátil que el QUASAR original basado en .NET. En la siguiente sección, nos centraremos en destacar la estructura del código de GOSAR, las nuevas características y las adiciones en comparación con la versión de código abierto (QUASAR).

Descripción general del análisis del código GOSAR

Estructura del código de GOSAR

Como el binario conservó todos sus símbolos, pudimos reconstruir la estructura del código fuente, que se extrajo de una muestra de la versión 0.12.01

• vibrante/config: contiene los archivos de configuración del malware.
• vibrante/proto: Alberga todas las declaraciones de Google Protocol Buffers (proto).
• vibrante/red: incluye funciones relacionadas con la red, como el bucle de conexión principal, el manejo del proxy y también el subproceso para configurar el firewall y configurar un oyente.
• vibrante/msgs/resolvers: define los comandos manejados por el malware. Estos comandos se asignan a un objeto dentro de las funciones vibrant_msgs_init* .
• vibrante/msgs/servicios: introduce nuevas funcionalidades, como la ejecución de servicios como keyloggers, registradores del portapapeles, estos servicios se inician en la función vibrant_network._ptr_Connection.Start .
• vibrante/logs: responsable de registrar la ejecución del malware. Los registros se cifran con una clave AES almacenada en la configuración. El malware descifra los registros en fragmentos empleando AES.
• vibrante/pkg/helpers: contiene funciones auxiliares empleadas en varios comandos y servicios de malware.
• vibrante/pkg/screenshot: maneja la funcionalidad de captura de pantalla en el sistema infectado.
• vibrante/pkg/utils: incluye funciones de utilidad, como la generación de valores aleatorios.
• vibrante/pkg/native: proporciona funciones para llamar a funciones de la API de Windows (WINAPI).

Nuevas incorporaciones a GOSAR

Comunicación y recopilación de información

Esta nueva variante continúa empleando el mismo método de comunicación que el original, basado en TCP TLS. Al conectarse, primero envía información del sistema al C2, con 4 campos nuevos agregados:

• Dirección IP
• Antivirus
• Configuración del portapapeles
• Carteras

La lista de antivirus y billeteras digitales se inicializa en la función vibrant_pkg_helpers_init y se puede encontrar al final de este documento.

Servicios

El malware maneja 3 servicios que se inician durante la conexión inicial del cliente al C2:

• vibrant_services_KeyLogger
• vibrant_services_ClipboardLogger
• vibrant_services_TickWriteFile

KeyLogger

La funcionalidad de registro de teclas en GOSAR se implementa en la función vibrant_services_KeyLogger . Esta función se basa en las API de Windows para interceptar y registrar las pulsaciones de teclas en el sistema infectado mediante la configuración de un gancho global de Windows con SetWindowsHookEx con el parámetro WH_KEYBOARD_LL para monitorear eventos de teclado de bajo nivel. La función de gancho se llama vibrant_services_KeyLogger_func1.

ClipboardLogger

La funcionalidad de registro del portapapeles es sencilla y se basa en las API de Windows. Primero verifica la disponibilidad de los datos del portapapeles usando IsClipboardFormatAvailable y luego los recupera usando la API GetClipboardData .

TickWriteFile

Los servicios ClipboardLogger y KeyLogger recopilan datos que TickWriteFile escribe periódicamente en el directorio (C:\ProgramData\Microsoft\Windows\Start Menu\Programs\diagnostics) bajo un archivo de la fecha actual, ejemplo 2024-11-27.
Se puede descifrar restando primero el valor 0x1f y luego aplicando el xor al valor 0x18 como se muestra en la receta de CyberChef.

Configuración de red

Luego de inicializar sus servicios, el malware genera tres subprocesos dedicados a su configuración de red.

• vibrant_network_ConfigFirewallRule
• vibrant_network_ConfigHosts
• vibrant_network_ConfigAutoListener

Subprocesos que gestionan la configuración de la red

Regla de configuración del firewall

El malware crea una regla de firewall entrante para el rango de puertos 51756-51776 bajo un nombre chino que se traduce como Distributed Transaction Coordinator (LAN) , permite todos los programas y direcciones IP entrantes, la descripción está configurada como:Inbound rules for the core transaction manager of the Distributed Transaction Coordinator service are managed remotely through RPC/TCP.

Hosts de configuración

Esta función agrega una entrada a c:\Windows\System32\Drivers\etc\hosts el siguiente 127.0.0.1 micrornetworks.com. El motivo para agregar esta entrada no está claro, pero es probable que se deba a funcionalidades faltantes o características incompletas en la etapa de desarrollo actual del malware.

ConfigAutoListener

Esta funcionalidad del malware ejecuta un escucha de servidor HTTP en el primer puerto disponible dentro del rango 51756-51776, que previamente estaba permitido por una regla de firewall. Curiosamente, el servidor no maneja ningún comando, lo que demuestra que el malware aún está en desarrollo. La versión actual que tenemos solo procesa una solicitud GET a la URI /security.js, respondiendo con la cadena callback();, cualquier otra solicitud devuelve un código de error 404 . Esta respuesta mínima podría indicar que el servidor es un marcador de posición o parte de una etapa de desarrollo temprana, con el potencial de que se agreguen funcionalidades más complejas más adelante.

Logs

El malware almacena sus registros de tiempo de ejecución en el directorio: %APPDATA%\Roaming\Microsoft\Logs bajo el nombre de archivo formateado como: windows-update-log-<YearMonthDay>.log.
Cada entrada de registro está cifrada con el algoritmo HMAC-AES; la clave está codificada en la función vibrant_config , el siguiente es un ejemplo:

El atacante puede recuperar de forma remota los registros de ejecución del malware emitiendo el comando ResolveGetRunLogs.

Plugins

El malware tiene la capacidad de ejecutar complementos, que son archivos PE descargados del C2 y almacenados en un disco cifrado con un algoritmo XOR. Estos complementos se almacenan en la ruta: C:\ProgramData\policy-err.log. Para ejecutar un complemento, se llama al comando ResolveDoExecutePlugin , primero verifica si hay un complemento disponible.

Luego, carga de forma reflexiva una DLL nativa que se almacena en formato base64 en el binario llamado plugins.dll y ejecuta su función de exportación ExecPlugin.

ExecPlugin crea un proceso suspendido de C:\Windows\System32\msiexec.exe con los argumentos /package /quiet. Luego, pone en cola llamadas a procedimientos asincrónicos (APC) en el hilo principal del proceso. Cuando se reanuda el hilo, se ejecuta el shellcode en cola.

El código shell lee el complemento encriptado almacenado en C:\ProgramData\policy-err.log, lo desencripta empleando una clave XOR de 1 byte codificada y lo carga y ejecuta de manera reflexiva.

HVNC

El malware admite VNC oculto (HVNC) a través del socket existente y expone comandos 5

• Resolver comando HVNC
• ResolverGetHVNCScreen
• ResolverDetenerHVNC
• ResolveDoHVNCKeyboardEvent
• ResolveDoHVNCMouseEvent

El primer comando que se ejecuta es ResolveGetHVNCScreen que primero lo inicializará y configurará una vista, emplea una DLL nativa incorporada HiddenDesktop.dll en formato base64, la DLL se carga de forma reflexiva en la memoria y se ejecuta.

La DLL es responsable de ejecutar API de bajo nivel para configurar el HVNC, con un total de 7 funciones exportadas:

• Comando de ejecución
• Desplazar el mouse
• Hacer clic derecho con el mouse
• HacerModoDeModo
• Hacer clic izquierdo del mouse
• Presionar tecla
• Captura de pantalla

La primera función de exportación llamada es Initialise para inicializar un escritorio con API CreateDesktopA . Esta implementación de HVNC maneja 17 comandos en total que se pueden encontrar en la exportación ExcuteCommand , como se señaló, tiene un error tipográfico en el nombre, el ID del comando se reenvía desde el comando ResolveHVNCCommand del malware que llamará ExcuteCommand.

Captura de pantalla

El malware carga de forma refleja la tercera y última DLL PE incrustada en formato base64 denominada Capture.dll, tiene 5 funciones de exportación:

• Capturar la primera pantalla
• Capturar siguiente pantalla
• GetBitmapInfo
• GetBitmapInfoSize
• Establecer calidad

La biblioteca se inicializa primero llamando a resolvers_ResolveGetBitmapInfo que carga y ejecuta de forma reflexiva su DllEntryPoint que configurará las estructuras de captura de pantalla empleando API comunes de Windows como CreateCompatibleDC, CreateCompatibleBitmap y CreateDIBSection. Las funciones de exportación 2 CaptureFirstScreen y CaptureNextScreen se emplean para capturar una captura de pantalla del escritorio de la víctima como una imagen JPEG.

Observación

Curiosamente, el servidor .NET QUASAR original todavía puede emplear para recibir señales de muestras GOSAR, ya que conservaron el mismo protocolo de comunicación. Sin embargo, su uso operativo requeriría modificaciones significativas para soportar las funcionalidades de GOSAR.

No está claro si los autores actualizaron o ampliaron el servidor .NET QUASAR de código abierto o desarrollaron uno completamente nuevo. Vale la pena mencionar que mantuvieron el puerto de escucha predeterminado, 1080, consistente con la implementación original.

Nueva funcionalidad

La siguiente tabla proporciona una descripción de todos los comandos recién agregados:

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

La táctica representa el porqué de una técnica o subtécnica. Es el objetivo táctico del adversario: la razón para realizar una acción.

• Colección
• Comando y control
• Evasión de defensa
• Descubrimiento
• Ejecución
• Exfiltración
• Persistencia
• Escalada de privilegios

Técnicas

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

• Flujo de ejecución de secuestro: carga lateral de DLL
• Captura de entrada: registro de teclas
• Inyección de proceso: llamada a procedimiento asincrónico
• Descubrimiento de procesos
• Ocultar artefactos: Ventana oculta
• Crear o modificar proceso del sistema: Servicio de Windows
• Puerto no estándar
• Mecanismo de control de elevación de abuso: omitir el control de cuentas de usuario
• Información o archivos ofuscados
• Debilitar defensas: deshabilitar o modificar herramientas
• Evasión de virtualización/sandbox: evasión basada en el tiempo

Mitigación de REF3864

Detección

• Posible omisión de la interfaz de análisis antimalware mediante PowerShell
• Proceso secundario inusual del administrador de trabajos de impresión
• Ejecución desde un directorio inusual - Línea de comandos
• Búsqueda de IP externa desde un proceso que no es del navegador
• Relación inusual entre padre e hijo
• Conexión de red inusual a través de DllHost
• Persistencia inusual a través del Registro de Servicios
• Suplantación de PID del proceso principal

Prevención

• Conexión de red mediante un proceso con argumentos inusuales
• Potential Masquerading as SVCHOST (Enmascaramiento potencial como SVCHOST)
• Módulo de red cargado desde una memoria sospechosa sin respaldo
• UAC Bypass via ICMLuaUtil Elevated COM Interface (Elusión de UAC a través de la interfaz COM elevada de ICMLuaUtil)
• Posible carga de imagen con un tiempo de creación falsificado

YARA

Elastic Security creó reglas YARA para identificar esta actividad.

• Multi.Trojan.Gosar
• Windows.Trojan.SadBridge

Observaciones

En esta investigación se discutieron los siguientes observables:

Referencias

A lo largo de la investigación anterior se hizo referencia a lo siguiente:

• https://zcgonvh.com/post/Advanced_Windows_Task_Scheduler_Playbook-Part.2_from_COM_to_UAC_bypass_and_get_SYSTEM_dirtectly.html
• https://www.sonicwall.com/blog/project-androm-backdoor-trojan
• https://www.safebreach.com/blog/process-injection-using-windows-thread-pools/
• https://gist.github.com/api0cradle/d4aaef39db0d845627d819b2b6b30512

Apéndice

Algoritmo hash (SADBRIDGE)

def ror(x, n, max_bits=32) -> int:
    """Rotate right within a max bit limit, default 32-bit."""
    n %= max_bits
    return ((x >> n) | (x << (max_bits - n))) & (2**max_bits - 1)

def ror_13(data) -> int:
    data = data.encode('ascii')
    hash_value = 0

    for byte in data:
        hash_value = ror(hash_value, 13)
        
        if byte >= 0x61:
            byte -= 32  # Convert to uppercase
        hash_value = (hash_value + byte) & 0xFFFFFFFF

    return hash_value


def generate_hash(data, dll) -> int:
    dll_hash = ror_13(dll)
    result = (dll_hash + ror_13(data)) & 0xFFFFFFFF
    
    return hex(result)

Productos AV revisados en GOSAR