Sob a SADBRIDGE com GOSAR: QUASAR ganha uma reescrita de Golang

Introdução

O Elastic Security Labs observou recentemente um novo conjunto de intrusões direcionado a regiões de língua chinesa, rastreado como REF3864. Essas campanhas organizadas têm como alvo as vítimas, disfarçando-se de softwares legítimos, como navegadores da web ou serviços de mensagens de mídia social. O grupo de ameaças por trás dessas campanhas mostra um grau moderado de versatilidade na distribuição de malware em diversas plataformas, como Linux, Windows e Android. Durante esta investigação, nossa equipe descobriu uma cadeia de infecção exclusiva do Windows com um carregador personalizado que chamamos de SADBRIDGE. Este carregador implementa uma reimplementação do QUASAR baseada em Golang, que chamamos de GOSAR. Esta é a primeira vez que nossa equipe observa uma reescrita do QUASAR na linguagem de programação Golang.

Principais conclusões

• Campanhas em andamento direcionadas a falantes de chinês com instaladores maliciosos disfarçados de software legítimo, como o Telegram e o navegador Opera
• As cadeias de infecção empregam injeção e carregamento lateral de DLL usando um carregador personalizado (SADBRIDGE)
• SADBRIDGE implementa uma variante recém-descoberta do backdoor QUASAR escrito em Golang (GOSAR)
• GOSAR é um backdoor multifuncional em desenvolvimento ativo com recursos incompletos e iterações de recursos aprimorados observados ao longo do tempo
• O Elastic Security fornece recursos abrangentes de prevenção e detecção contra essa cadeia de ataques

Visão geral da campanha REF3864

Em novembro, a equipe do Elastic Security Labs observou uma cadeia de infecção única ao detonar diversas amostras diferentes enviadas ao VirusTotal. Essas diferentes amostras foram hospedadas por meio de páginas de destino disfarçadas de software legítimo, como o Telegram ou o navegador Opera GX.

Durante esta investigação, descobrimos múltiplas cadeias de infecção envolvendo técnicas semelhantes:

• Instaladores MSI trojanizados com baixas detecções
• Disfarce usando software legítimo agrupado com DLLs maliciosas
• Carregador SADBRIDGE personalizado implantado
• Estágio final GOSAR carregado

Acreditamos que essas campanhas passaram despercebidas devido a vários níveis de abstração. Normalmente, a primeira fase envolve a abertura de um arquivo compactado (ZIP) que inclui um instalador MSI. Software legítimo como o aplicativo de depuração do Windows x64dbg.exe é usado nos bastidores para carregar uma DLL maliciosa e corrigida (x64bridge.dll). Esta DLL inicia um novo programa legítimo (MonitoringHost.exe) onde ele carrega lateralmente outra DLL maliciosa (HealthServiceRuntime.dll), realizando a injeção e carregando o implante GOSAR na memória por meio da injeção.

Pesquisadores de malware extraíram configurações do SADBRIDGE que revelam datas de campanha designadas pelo adversário e indicam que operações com TTPs semelhantes estão em andamento desde pelo menos dezembro de 2023. A infraestrutura de comando e controle (C2) do GOSAR frequentemente se disfarça de serviços ou softwares confiáveis para parecer benigna e estar de acordo com as expectativas das vítimas em relação aos instaladores de software. Ao longo da cadeia de execução, há um foco centrado na enumeração de produtos antivírus chineses, como 360tray.exe, juntamente com nomes de regras de firewall e descrições em chinês. Devido a essas personalizações, acreditamos que essa ameaça tem como alvo falantes de chinês. Além disso, o uso extensivo de registros em chinês indica que os invasores também são falantes de chinês.

O QUASAR já foi usado em espionagem patrocinada pelo Estado, hacktivismo não estatal e ataques criminosos motivados financeiramente desde 2017 (Qualys, Evolution of Quasar RAT), incluindo o APT10 vinculado à China. Uma reescrita em Golang poderia capitalizar o conhecimento institucional adquirido durante esse período, permitindo capacidades adicionais sem a necessidade de um extenso retreinamento de TTPs anteriormente eficazes.

O GOSAR estende o QUASAR com recursos adicionais de coleta de informações, suporte a vários sistemas operacionais e evasão aprimorada contra produtos antivírus e classificadores de malware. No entanto, os sites de isca genéricos e a falta de informações adicionais sobre segmentação ou ações sobre o objetivo nos deixam com evidências insuficientes para identificar a(s) motivação(ões) do invasor.

Introdução SADBRIDGE

O carregador de malware SADBRIDGE é empacotado como um executável MSI para entrega e usa carregamento lateral de DLL com várias técnicas de injeção para executar cargas maliciosas. O SADBRIDGE abusa de aplicativos legítimos como x64dbg.exe e MonitoringHost.exe para carregar DLLs maliciosas como x64bridge.dll e HealthServiceRuntime.dll, o que leva a estágios subsequentes e shellcodes.

A persistência é alcançada por meio da criação de serviços e modificações no registro. A escalada de privilégios para Administrador ocorre silenciosamente usando uma técnica de desvio de UAC que abusa da interface COM ICMLuaUtil . Além disso, o SADBRIDGE incorpora um bypass de escalonamento de privilégios por meio do Agendador de Tarefas do Windows para executar sua carga principal com privilégios de nível de SISTEMA.

A configuração SADBRIDGE é criptografada usando uma subtração simples de 0x1 em cada byte da string de configuração. Todos os estágios criptografados são anexados com uma extensão .log e descriptografados durante o tempo de execução usando XOR e o algoritmo de descompressão LZNT1.

O SADBRIDGE emprega técnicas de PoolParty, filas APC e manipulação de tokens para injeção de processos. Para evitar a análise de sandbox, ele usa longas chamadas de API Sleep . Outra técnica de evasão de defesa envolve a aplicação de patches na API para desabilitar mecanismos de segurança do Windows, como a Antimalware Scan Interface (AMSI) e o Event Tracing for Windows (ETW).

O seguinte mergulho profundo é estruturado para explorar a cadeia de execução, fornecendo um passo a passo dos recursos e funcionalidades de arquivos e estágios significativos, com base na configuração da amostra analisada. A análise visa destacar a interação entre cada componente e seus papéis para atingir a carga final.

Análise de código SADBRIDGE

Análise MSI

Os arquivos iniciais são empacotados em um MSI usando o Advanced Installer, os principais arquivos de interesse são x64dbg.exe e x64bridge.dll.

Usando a ferramenta MSI (lessmsi), podemos ver que o ponto de entrada LaunchApp em aicustact.dll está configurado para executar o caminho do arquivo especificado na propriedade AI_APP_FILE .

Se navegarmos até esta propriedade AI_APP_FILE , podemos ver que o arquivo vinculado a esta configuração é x64dbg.exe. Isso representa o arquivo que será executado após a conclusão da instalação, o NetFxRepairTool.exe legítimo nunca é executado.

x64bridge.dll Carregamento lateral

Quando x64dbg.exe é executado, ele chama a exportação BridgeInit de x64bridge.dll. BridgeInit é um wrapper para a função BridgeStart .

Semelhante às técnicas observadas com o BLISTER, o SADBRIDGE corrige a exportação de uma DLL legítima.

Durante a rotina de inicialização do malware, o SADBRIDGE começa gerando um hash usando o nome do host e uma semente mágica 0x4E67C6A7. Este hash é usado como um nome de diretório para armazenar o arquivo de configuração criptografado. A configuração criptografada é gravada em C:\Users\Public\Documents\<hostname_hash>\edbtmp.log. Este arquivo contém os atributos FILE_ATTRIBUTE_SYSTEM, FILE_ATTRIBUTE_READONLY, FILE_ATTRIBUTE_HIDDEN para se ocultar de uma listagem de diretório comum.

Descriptografar a configuração é simples: os blocos criptografados são separados por bytes nulos. Para cada byte dentro dos blocos criptografados, podemos incrementá-los em 0x1.

A configuração consiste em:

• Possível data da campanha
• Strings a serem usadas para criar serviços
• Novo nome para MonitoringHost.exe (DevQueryBroker.exe)
• Nome da DLL para a DLL a ser carregada lateralmente pelo MonitoringHost.exe (HealthServiceRuntime.dll)
• Caminhos absolutos para estágios adicionais (.log arquivos)
• O alvo primário de injeção para hospedar GOSAR (svchost.exe)

O diretório DevQueryBroker (C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\) contém todos os estágios criptografados ( arquivos .log ) que são descriptografados em tempo de execução. O arquivo (DevQueryBroker.exe) é uma cópia renomeada do aplicativo legítimo da Microsoft (MonitoringHost.exe).

Por fim, ele cria um processo para executar DevQueryBroker.exe que carrega lateralmente o HealthServiceRuntime.dll malicioso na mesma pasta.

HealthServiceRuntime.dll

Este módulo coloca um shellcode criptografado e parcialmente descriptografado no diretório %TEMP% do usuário. O nome do arquivo para o shellcode segue o formato: log<random_string>.tmp. Cada byte do shellcode parcialmente descriptografado é então decrementado em 0x10 para descriptografar completamente. O shellcode é executado em um novo thread do mesmo processo.

O malware aproveita o hash da API usando o mesmo algoritmo da pesquisa publicada pela SonicWall; o algoritmo de hash está listado na seção Apêndice. O shellcode descriptografa DevQueryBroker.log em um arquivo PE e então executa uma operação XOR simples com um único byte (0x42) no primeiro terço do arquivo, onde então descompacta o resultado usando o algoritmo LZNT1.

O shellcode então desmapeia quaisquer mapeamentos existentes no endereço base preferencial do arquivo PE usando NtUnmapViewOfSection, garantindo que uma chamada para VirtualAlloc alocará memória começando no endereço base preferencial. Por fim, ele mapeia o arquivo PE descriptografado para essa memória alocada e transfere a execução para seu ponto de entrada. Todos os shellcodes identificados e executados pelo SADBRIDGE compartilham uma estrutura de código idêntica, diferindo apenas nos arquivos .log específicos aos quais eles fazem referência para descriptografia e execução.

DevQueryBroker.log

O malware carrega dinamicamente amsi.dll para desabilitar mecanismos de segurança críticos no Windows. Ele corrige AmsiScanBuffer em amsi.dll inserindo instruções para modificar o valor de retorno para 0x80070057, o código de erro padronizado da Microsoft E_INVALIDARG indicando argumentos inválidos e retornando prematuramente, para efetivamente ignorar a lógica de varredura. Da mesma forma, ele corrige AmsiOpenSession para sempre retornar o mesmo código de erro E_INVALIDARG. Além disso, ele corrige EtwEventWrite em ntdll.dll, substituindo a primeira instrução por uma instrução ret para desabilitar o Rastreamento de Eventos para Windows (ETW), suprimindo qualquer registro de atividade maliciosa.

Após a aplicação do patch, um shellcode criptografado é gravado em temp.ini no caminho (C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\temp.ini).
O malware verifica a associação de grupo do token de processo atual para determinar seu nível de privilégio. Ele verifica se o processo pertence à conta LocalSystem inicializando um SID com SECURITY_LOCAL_SYSTEM_RID e chamando CheckTokenMembership. Caso contrário, ele tenta verificar a associação ao grupo Administradores criando um SID usando SECURITY_BUILTIN_DOMAIN_RID e DOMAIN_ALIAS_RID_ADMINS e executando uma verificação de associação de token semelhante.

Se o processo atual não tiver privilégios de LocalSystem ou Administrador, os privilégios serão primeiro elevados para Administrador por meio de um mecanismo de desvio de UAC , aproveitando a interface COM ICMLuaUtil . Ele cria uma string de apelido "Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}" para criar uma instância do objeto CMSTPLUA com privilégios de administrador. Depois que o objeto é criado e a interface ICMLuaUtil é obtida, o malware usa o método ShellExec exposto da interface para executar DevQueryBroker.exe.

Se uma tarefa ou um serviço não for criado para ser executado DevQueryBroker.exe rotineiramente, o malware verifica se o processo antivírus 360tray.exe está em execução. Se não estiver em execução, um serviço será criado para escalonamento de privilégios para SYSTEM, com as seguintes propriedades:

• Nome do serviço: DevQueryBrokerService
  Nome do caminho binário: “C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\DevQueryBroker.exe -svc”.
• Nome de exibição: DevQuery Background Discovery Broker Service
• Descrição: Permite que aplicativos descubram dispositivos com uma tarefa em segundo plano.
• Tipo de inicialização: Automaticamente na inicialização do sistema
• Privilégios: LocalSystem

Se 360tray.exe for detectado em execução, o malware grava um arquivo PE criptografado em DevQueryBrokerService.log e, em seguida, mapeia um arquivo PE de próximo estágio (Estágio 1) na memória do processo atual, transferindo a execução para ele.

Quando DevQueryBroker.exe é reativado com privilégios de nível de SISTEMA e atinge essa parte da cadeia, o malware verifica a versão do Windows. Para sistemas que executam o Vista ou posterior (excluindo o Windows 7), ele mapeia outro próximo estágio (Estágio 2) na memória e transfere a execução para lá.

No Windows 7, no entanto, ele executa um shellcode, que descriptografa e executa o arquivo DevQueryBrokerPre.log .

Estágio 1 Injeção (explorer.exe)

O SADBRIDGE utiliza a variante 7 do PoolParty para injetar shellcode em explorer.exe direcionando a fila de conclusão de E/S do seu pool de threads. Primeiro, ele duplica um identificador para a fila de conclusão de E/S do processo de destino. Em seguida, ele aloca memória dentro de explorer.exe para armazenar o shellcode. Memória adicional é alocada para armazenar uma estrutura TP_DIRECT criada, que inclui o endereço base do shellcode como endereço de retorno de chamada. Por fim, ele chama ZwSetIoCompletion, passando um ponteiro para a estrutura TP_DIRECT para enfileirar um pacote para a fila de conclusão de E/S da fábrica de trabalho do processo de destino (gerenciador de threads de trabalho), acionando efetivamente a execução do shellcode injetado.

Este shellcode descriptografa o arquivo DevQueryBrokerService.log , desmapeia quaisquer regiões de memória que ocupem seu endereço base preferido, mapeia o arquivo PE para esse endereço e, então, executa seu ponto de entrada. Esse comportamento reflete o shellcode observado anteriormente.

Estágio 2 Injeção (spoolsv.exe/lsass.exe)

Para o Estágio 2, o SADBRIDGE injeta shellcode em spoolsv.exe, ou lsass.exe se spoolsv.exe não estiver disponível, usando a mesma técnica de injeção do Estágio 1. O shellcode exibe comportamento semelhante aos estágios anteriores: ele descriptografa DevQueryBrokerPre.log em um arquivo PE, desmapeia quaisquer regiões que ocupem seu endereço base preferido, mapeia o arquivo PE e então transfere a execução para seu ponto de entrada.

DevQueryBrokerService.log

O shellcode descriptografado de DevQueryBrokerService.log , conforme mencionado na seção anterior, utiliza uma técnica de escalonamento de privilégios usando o Agendador de Tarefas do Windows. O SADBRIDGE integra uma técnica de bypass de UAC público usando o objeto COM IElevatedFactorySever para criar indiretamente a tarefa agendada. Esta tarefa está configurada para ser executada DevQueryBroker.exe diariamente com privilégios de nível de SISTEMA usando o nome de tarefa DevQueryBrokerService.

Para cobrir seus rastros, o malware falsifica o caminho da imagem e a linha de comando modificando o Process Environment Block (PEB) diretamente, provavelmente em uma tentativa de disfarçar o serviço COM como vindo de explorer.exe.

DevQueryBrokerPre.log

SADBRIDGE cria um serviço chamado DevQueryBrokerServiceSvc na subchave de registro SYSTEM\CurrentControlSet\Services\DevQueryBrokerServiceSvc com os seguintes atributos:

• Descrição: Permite que aplicativos descubram dispositivos com uma tarefa em segundo plano.
• DisplayName: Serviço de descoberta de plano de fundo do DevQuery
• Controle de erro: 1
• Caminho da imagem: %systemRoot%\system32\svchost.exe -k netsvcs
• Nome do objeto: Sistema local
• Início: 2 (início automático)
• Tipo: 16.
• Ações de falha:
  • Redefine a contagem de falhas a cada 24 horas.
  • Executa três tentativas de reinicialização: um atraso de 20 ms para a primeira e um atraso de 1 minuto para a segunda e terceira.

Os parâmetros de serviço especificam o ServiceDll localizado em C:\Program Files (x86)\Common Files\Microsoft Shared\Stationery\<hostname_hash>\DevQueryBrokerService.dll. Se o arquivo DLL não existir, ele será descartado no disco logo em seguida.

DevQueryBrokerService.dll tem uma estrutura de código semelhante a HealthServiceRuntime.dll, que é vista nos estágios iniciais da cadeia de execução. Ele é responsável por descriptografar DevQueryBroker.log e executá-lo. O ServiceDll será carregado e executado por svchost.exe quando o serviço iniciar.

Além disso, ele modifica a chave SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs para incluir uma entrada para DevQueryBrokerServiceSvc para integrar o serviço recém-criado no grupo de serviços gerenciados pelo grupo de hosts de serviço netsvcs .

O SADBRIDGE então exclui a tarefa agendada e o serviço criado anteriormente removendo as subchaves de registro SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tree\\DevQueryBrokerService e SYSTEM\\CurrentControlSet\\Services\\DevQueryBrokerService.

Por fim, ele remove os arquivos DevQueryBroker.exe e HealthServiceRuntime.dll na pasta C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker , pois o novo mecanismo de persistência está em vigor.

Injeção de GOSAR

Na segunda metade do código, o SADBRIDGE enumera todas as sessões ativas na máquina local usando a API WTSEnumerateSessionsA .

Se forem encontradas sessões, ele itera por cada sessão:

• Para cada sessão, ele tenta recuperar o nome de usuário (WTSUserName) usando WTSQuerySessionInformationA. Se a consulta falhar, ela passa para a próxima sessão.
• Se WTSUserName não estiver vazio, o código terá como alvo svchost.exe, passando seu caminho, o ID da sessão e o conteúdo da configuração do carregador para uma sub-rotina que injeta o estágio final.
• Se WTSUserName estiver vazio, mas o WinStationName da sessão for "Services" (indicando uma sessão de serviço), ele terá como alvo dllhost.exe , passando os mesmos parâmetros para a sub-rotina de injeção do estágio final.

Se nenhuma sessão for encontrada, ele entra em um loop infinito para enumerar sessões repetidamente e invocar a sub-rotina para injetar o estágio final, enquanto realiza verificações para evitar injeções redundantes.

As sessões conectadas têm como alvo svchost.exe, enquanto as sessões de serviço ou sessões sem um usuário conectado têm como alvo dllhost.exe.

Se um ID de sessão estiver disponível, o código tentará duplicar o token do usuário para essa sessão e elevar o nível de integridade do token duplicado para S-1-16-12288 (integridade do sistema). Em seguida, ele usa o token elevado para criar um processo filho (svchost.exe ou dllhost.exe) via CreateProcessAsUserA.

Se a manipulação do token falhar ou nenhuma ID de sessão estiver disponível (os processos do sistema podem ter uma ID de sessão de 0), ele retorna à criação de um processo sem um token usando CreateProcessA.

O shellcode criptografado C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\temp.ini é descriptografado usando a mesma técnica de descompressão XOR e LZNT1 vista anteriormente para descriptografar arquivos .log , e a injeção de APC é usada para enfileirar o shellcode para execução no thread do processo recém-criado.

Por fim, o shellcode injetado descriptografa DevQueryBrokerCore.log para GOSAR e o executa na memória do processo recém-criado.

Introdução ao GOSAR

GOSAR é um trojan de acesso remoto multifuncional que tem como alvo sistemas Windows e Linux. Esse backdoor inclui recursos como recuperação de informações do sistema, captura de tela, execução de comandos, keylogging e muito mais. O backdoor GOSAR mantém grande parte da funcionalidade e do comportamento principais do QUASAR, ao mesmo tempo em que incorpora diversas modificações que o diferenciam da versão original.

Ao reescrever malware em linguagens modernas como Go, isso pode oferecer taxas de detecção reduzidas, já que muitas soluções antivírus e classificadores de malware têm dificuldade para identificar sequências/características maliciosas sob essas novas construções de programação. Abaixo está um bom exemplo de um GOSAR descompactado recebendo apenas 5 detecções no upload.

Notavelmente, esta variante suporta múltiplas plataformas, incluindo binários ELF para sistemas Linux e arquivos PE tradicionais para Windows. Essa capacidade multiplataforma se alinha à adaptabilidade do Go, tornando-o mais versátil que o QUASAR original baseado em .NET. Na seção a seguir, nos concentraremos em destacar a estrutura do código do GOSAR, novos recursos e adições em comparação com a versão de código aberto (QUASAR).

Visão geral da análise de código GOSAR

Estrutura de código do GOSAR

Como o binário manteve todos os seus símbolos, fomos capazes de reconstruir a estrutura do código-fonte, que foi extraído de uma amostra da versão 0.12.01

• vibrant/config: contém os arquivos de configuração do malware.
• vibrant/proto: Abriga todas as declarações do Google Protocol Buffers (proto).
• vibrante/rede: Inclui funções relacionadas à rede, como o loop de conexão principal, manipulação de proxy e também thread para configurar o firewall e configurar um ouvinte
• vibrant/msgs/resolvers: define os comandos manipulados pelo malware. Esses comandos são atribuídos a um objeto dentro das funções vibrant_msgs_init* .
• vibrant/msgs/services: Introduz novas funcionalidades, como executar serviços como keyloggers, clipboard logger, esses serviços são iniciados na função vibrant_network._ptr_Connection.Start .
• vibrant/logs: Responsável por registrar a execução do malware. Os logs são criptografados com uma chave AES armazenada na configuração. O malware descriptografa os logs em pedaços usando AES.
• vibrant/pkg/helpers: contém funções auxiliares usadas em vários comandos e serviços de malware.
• vibrant/pkg/screenshot: Lida com a funcionalidade de captura de tela no sistema infectado.
• vibrant/pkg/utils: Inclui funções utilitárias, como geração de valores aleatórios.
• vibrant/pkg/native: Fornece funções para chamar funções da API do Windows (WINAPI).

Novas adições ao GOSAR

Comunicação e coleta de informações

Esta nova variante continua a usar o mesmo método de comunicação do original, baseado em TCP TLS. Após a conexão, ele primeiro envia informações do sistema para o C2, com 4 novos campos adicionados:

• Endereço IP
• Antivírus
• Configurações da área de transferência
• Carteiras

A lista de antivírus e carteiras digitais é inicializada na função vibrant_pkg_helpers_init e pode ser encontrada no final deste documento.

Serviços

O malware manipula 3 serviços que são iniciados durante a conexão inicial do cliente ao C2:

• vibrant_services_KeyLogger
• vibrant_services_ClipboardLogger
• vibrant_services_TickWriteFile

KeyLogger

A funcionalidade de keylogging no GOSAR é implementada na função vibrant_services_KeyLogger . Esse recurso depende de APIs do Windows para interceptar e registrar pressionamentos de tecla no sistema infectado, definindo um gancho global do Windows com SetWindowsHookEx e o parâmetro WH_KEYBOARD_LL para monitorar eventos de teclado de baixo nível. A função de gancho é chamada vibrant_services_KeyLogger_func1.

ClipboardLogger

A funcionalidade de registro da área de transferência é simples e depende de APIs do Windows. Primeiro, ele verifica a disponibilidade dos dados da área de transferência usando IsClipboardFormatAvailable e depois os recupera usando a API GetClipboardData .

Arquivo TickWrite

Ambos os serviços ClipboardLogger e KeyLogger coletam dados que são gravados pelo TickWriteFile periodicamente no diretório (C:\ProgramData\Microsoft\Windows\Start Menu\Programs\diagnostics) em um arquivo da data atual, por exemplo 2024-11-27.
Ele pode ser decifrado primeiro subtraindo o valor 0x1f e depois correlacionando-o com o valor 0x18 conforme mostrado na receita do CyberChef.

Configuração de rede

Após inicializar seus serviços, o malware gera três threads dedicados à sua configuração de rede.

• vibrant_network_ConfigFirewallRule
• vibrant_network_ConfigHosts
• vibrant_network_ConfigAutoListener

Threads que manipulam a configuração de rede

Regra de configuração do firewall

O malware cria uma regra de firewall de entrada para o intervalo de portas 51756-51776 sob um nome chinês que é traduzido para Distributed Transaction Coordinator (LAN) , ele permite a entrada de todos os programas e endereços IP, a descrição é definida como:Inbound rules for the core transaction manager of the Distributed Transaction Coordinator service are managed remotely through RPC/TCP.

ConfigHosts

Esta função adiciona uma entrada ao c:\Windows\System32\Drivers\etc\hosts seguinte 127.0.0.1 micrornetworks.com. O motivo para adicionar esta entrada não está claro, mas provavelmente é devido a funcionalidades ausentes ou recursos incompletos no estágio atual de desenvolvimento do malware.

ConfigAutoListener

Essa funcionalidade do malware executa um ouvinte de servidor HTTP na primeira porta disponível dentro do intervalo 51756-51776, o que era permitido anteriormente por uma regra de firewall. Curiosamente, o servidor não processa nenhum comando, o que prova que o malware ainda está em desenvolvimento. A versão atual que temos processa apenas uma solicitação GET para o URI /security.js, respondendo com a string callback();, qualquer outra solicitação retorna um código de erro 404 . Esta resposta mínima pode indicar que o servidor é um espaço reservado ou parte de um estágio inicial de desenvolvimento, com potencial para funcionalidades mais complexas a serem adicionadas posteriormente.

Logs

O malware salva seus logs de tempo de execução no diretório: %APPDATA%\Roaming\Microsoft\Logs sob o nome de arquivo formatado como: windows-update-log-<YearMonthDay>.log.
Cada entrada de log é criptografada com o algoritmo HMAC-AES; a chave é codificada na função vibrant_config , veja a seguir um exemplo:

O invasor pode recuperar remotamente os logs de tempo de execução do malware emitindo o comando ResolveGetRunLogs.

Plugins

O malware tem a capacidade de executar plugins, que são arquivos PE baixados do C2 e armazenados em disco criptografados com um algoritmo XOR. Esses plugins são salvos no caminho: C:\ProgramData\policy-err.log. Para executar um plugin, o comando ResolveDoExecutePlugin é chamado e primeiro ele verifica se um plugin está disponível.

Em seguida, ele carrega uma DLL nativa reflexivamente que é armazenada no formato base64 no binário chamado plugins.dll e executa sua função de exportação ExecPlugin.

ExecPlugin cria um processo suspenso de C:\Windows\System32\msiexec.exe com os argumentos /package /quiet. Em seguida, ele enfileira Chamadas de Procedimento Assíncrono (APC) para o thread principal do processo. Quando o thread é retomado, o shellcode enfileirado é executado.

O shellcode lê o plugin criptografado armazenado em C:\ProgramData\policy-err.log, descriptografa-o usando uma chave XOR de 1 byte codificada e o carrega e executa reflexivamente.

HVNC

O malware suporta VNC oculto (HVNC) através do soquete existente, ele expõe 5 comandos

• ResolveHVNCCommand
• ResolverObterHVNCScreen
• ResolveStopHVNC
• ResolveDoHVNCKeyboardEvent
• ResolveDoHVNCMouseEvent

O primeiro comando executado é ResolveGetHVNCScreen , que primeiro o inicializará e configurará uma visualização. Ele usa uma DLL nativa incorporada HiddenDesktop.dll no formato base64. A DLL é carregada reflexivamente na memória e executada.

A DLL é responsável por executar APIs de baixo nível para configurar o HVNC, com um total de 7 funções exportadas:

• Comando Executável
• FazerRolagemDoMouse
• Clique com o botão direito do mouse
• FazerMouseMove
• CliqueEsquerdoDoMouse
• Pressione a tecla
• Captura de tela

A primeira função de exportação chamada é Initialise para inicializar uma área de trabalho com a API CreateDesktopA . Esta implementação HVNC manipula 17 comandos no total que podem ser encontrados na exportação ExcuteCommand , como observado, há um erro de digitação no nome, o ID do comando é encaminhado do comando do malware ResolveHVNCCommand que chamará ExcuteCommand.

Captura de tela

O malware carrega reflexivamente a terceira e última DLL PE incorporada no formato base64 chamada Capture.dll, ela tem 5 funções de exportação:

• CaptureFirstScreen
• CapturarPróximaTela
• GetBitmapInfo
• GetBitmapInfoSize
• DefinirQualidade

A biblioteca é inicializada primeiro chamando resolvers_ResolveGetBitmapInfo , que carrega e executa reflexivamente seu DllEntryPoint , que configurará as estruturas de captura de tela usando APIs comuns do Windows, como CreateCompatibleDC, CreateCompatibleBitmap e CreateDIBSection. As funções de exportação 2 CaptureFirstScreen e CaptureNextScreen são usadas para capturar uma imagem da área de trabalho da vítima como uma imagem JPEG.

Observação

Curiosamente, o servidor .NET QUASAR original ainda pode ser usado para receber beaconing de amostras GOSAR, pois eles mantiveram o mesmo protocolo de comunicação. Entretanto, seu uso operacional exigiria modificações significativas para dar suporte às funcionalidades do GOSAR.

Não está claro se os autores atualizaram ou estenderam o servidor .NET QUASAR de código aberto ou desenvolveram um completamente novo. Vale mencionar que eles mantiveram a porta de escuta padrão, 1080, consistente com a implementação original.

Nova funcionalidade

A tabela a seguir fornece uma descrição de todos os comandos recém-adicionados:

Malware e MITRE ATT&CK

A Elastic usa a estrutura MITRE ATT&CK para documentar táticas, técnicas e procedimentos comuns que as ameaças usam contra redes corporativas.

Táticas

As táticas representam o porquê de uma técnica ou subtécnica. É o objetivo tático do adversário: a razão para executar uma ação.

• Coleta
• Command and Control (Comando e controle)
• Defense Evasion
• Descoberta
• Execução
• Exfiltração
• Persistência
• Escalação de privilégios

Técnicas

Técnicas representam como um adversário atinge um objetivo tático executando uma ação.

• Fluxo de execução do Hijack: carregamento lateral de DLL
• Captura de entrada: Keylogging
• Injeção de Processo: Chamada de Procedimento Assíncrono
• Descoberta de Processos
• Ocultar Artefatos: Janela Oculta
• Criar ou modificar processo do sistema: serviço do Windows
• Porta não padrão
• Abuse do mecanismo de controle de elevação: ignore o controle de conta de usuário
• Arquivos ou informações ofuscadas
• Impair Defenses: Desabilitar ou modificar ferramentas
• Evasão de Virtualização/Sandbox: Evasão Baseada em Tempo

Mitigando REF3864

Detecção

• Possível desvio da interface de verificação antimalware via PowerShell
• Processo filho incomum do spooler de impressão
• Execução de diretório incomum - linha de comando
• Pesquisa de IP externo de processo sem navegador
• Relacionamento incomum entre pais e filhos
• Conexão de rede incomum via DllHost
• Persistência incomum via registro de serviços
• Falsificação de PID do processo pai

Prevenção

• Conexão de rede via processo com argumentos incomuns
• Potential Masquerading as SVCHOST (possível mascaramento como SVCHOST)
• Módulo de rede carregado de memória suspeita sem backup
• UAC Bypass via ICMLuaUtil Elevated COM Interface (desvio do UAC via interface COM elevada do ICMLuaUtil)
• Carregamento potencial de imagem com um tempo de criação falsificado

YARA

O Elastic Security criou regras YARA para identificar essa atividade.

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

Observações

Os seguintes observáveis foram discutidos nesta pesquisa:

Referências

Os seguintes itens foram referenciados ao longo da pesquisa acima:

• 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 de 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)

Produtos AV verificados no GOSAR