Os carregadores de malware são essencialmente trojans de acesso remoto (RATs) que estabelecem a comunicação entre o atacante e o sistema comprometido. Os carregadores normalmente representam o primeiro estágio de um compromisso. Seu objetivo principal é baixar e executar cargas adicionais, do servidor controlado pelo atacante, no sistema comprometido sem serem detectadas.

Pesquisadores da ProofPoint descobriram um novo carregador de malware chamado Bumblebee. O carregador de malware tem o nome de uma string exclusiva de agente de usuário usada para comunicação C2. Foi observado que os adversários começaram a usar o Bumblebee para implantar malwares como os beacons CobaltStrike e os projetos Meterpreter. O grupo de ameaças TA578 também tem usado o carregador Bumblebee em suas campanhas.

Este artigo explora e decodifica o carregador de malware Bumblebee:

• Características técnicas
• Fluxo lógico
• Processo de exploração
• Manutenção da rede
• Características exclusivas

Entrega da campanha

Os adversários enviam arquivos ISO por meio de cadeias de e-mail (resposta) comprometidas, conhecidas como e-mails sequestrados por tópicos, para implantar o carregador Bumblebee. Os arquivos ISO contêm uma cópia byte a byte dos dados de baixo nível armazenados em um disco. Os arquivos ISO maliciosos são inseridos por meio de links do Google Cloud ou pastas zip protegidas por senha.

 

 

Os arquivos ISO contêm uma DLL oculta com nomes aleatórios e um arquivo LNK. DLL (Dynamic Link Library) é uma biblioteca que contém códigos e dados que podem ser usados por mais de um programa ao mesmo tempo. LNK é uma extensão de nome de arquivo no Microsoft Windows para atalhos para arquivos locais.

O arquivo LNK geralmente contém um link direto para um arquivo executável ou metadados sobre o arquivo executável, sem a necessidade de rastrear o caminho completo do programa. Os arquivos LNK são uma alternativa atraente para abrir um arquivo e, portanto, uma forma eficaz de os agentes de ameaças criarem ataques baseados em scripts. O local de destino dos arquivos LNK está definido para ser executado rundll32.exe, que chamará uma função exportada na DLL associada. Se a opção “mostrar itens ocultos” não estiver ativada no sistema da vítima, as DLLs podem não ficar visíveis para o usuário.

Análise do Bumblebee Loader

A amostra analisada (f98898df74fb2b2fad3a2ea2907086397b36ae496ef3f4454bf6b7125fc103b8) é um arquivo DLL com funções exportadas.

Funções exportadas para o arquivo DLL de amostra

Ambas as funções exportadas, Trabalho interno e Definir caminho, execute a função Sub_180004AA0.

InternalJob executando a função sub_180004AA0 SetPath executando a função sub_180004AA0

Entropia da DLL

A entropia de um arquivo mede a aleatoriedade dos dados no arquivo. A entropia pode ser usada para determinar se há dados ocultos ou scripts suspeitos no arquivo. A escala de entropia é de 0 (não aleatória) a 8 (totalmente aleatória). Valores de entropia altos indicam que há dados criptografados armazenados no arquivo, enquanto valores mais baixos indicam que a criptografia e o armazenamento da carga são úteis em diferentes seções durante o tempo de execução.

 

O pico está espalhado pelos segmentos de dados do arquivo DLL. É altamente possível que esse pico tenha sido causado pela presença de dados compactados nos segmentos de dados da DLL de amostra. Isso indica que o malware, em algum momento do tempo de execução, buscará os dados do segmento de dados e os descompactará para uso posterior.

Desempacotando e implantando a carga útil (função sub_180004AA0)

A função exportada Sub_180004AA0 é um componente essencial para descompactar e implantar a carga principal no sistema de destino.

 

A função sub_180003490 serve como descompactador da carga principal.

 

Função sub_180003490

Função sub_180003490 contém 2 funções de interesse:

Sub_1800021D0: Essa rotina de funções é responsável por alocar memória de pilha.

 

Sub_1800029BC: Essa função grava os dados incorporados, no segmento de dados da amostra de DLL, na memória heap recém-alocada. A carga útil compactada é obtida do segmento de dados e gravada na memória da pilha alocada. O segmento de código destacado na imagem abaixo é responsável pela transferência dos dados.

Função Sub_1800029BC

 

• O código de montagem destacado em amarelo transfere os dados incorporados (carga útil compactada) do segmento de dados da DLL para um registro CL intermediário.
• O código de montagem destacado em vermelho transfere os dados do CL para a pilha alocada. Durante o tempo de execução, a memória de pilha continua sendo preenchida com a carga útil compactada incorporada nas amostras de DLL.

 

Função Sub_180002FF4

Depois de despejar a carga útil embalada na memória alocada, o controle volta para Sub_180004AA0 e função Sub_180002FF4 é executado.

Função Sub_180002FF4

Função Sub_180002FF4 executa as seguintes operações:

• Aloque uma nova memória de pilha.
• Transfere a carga útil compactada anteriormente despejada para a memória recém-alocada.
• Desaloque a memória alocada anteriormente.

Depois que o controle retornar para Sub_180004AA0 função sub_180004180 é executado.

Função sub_180004180

Função sub_180004180

Três funções encapsuladas na função sub_180004180

Função sub_180004180 tem 3 funções:

• sub_180001670: Essa função é responsável por alocar várias memórias de heap para o malware. Posteriormente, o malware despeja o arquivo MZ descompactado em uma das memórias alocadas.
• Sub_180003CE4: Essa função é responsável por descompactar a carga útil embalada anteriormente despejada na pilha do processo e despejá-la em uma das memórias alocadas por sub_180001670.
• Sub_180001A84: Essa função é responsável pela desalocação da memória.

 

Implementação do

Hooking se refere a uma variedade de técnicas usadas para modificar o comportamento de um sistema operacional, software ou componente de software, interceptando chamadas de função, eventos ou comunicação entre componentes de software. O código que manipula essas chamadas de função, eventos ou comunicações interceptadas é chamado de gancho.

Logo após o carregador do Bumblebee descompactar a carga principal na memória, ele conecta algumas funções interessantes exportadas pelo ntdll.dll (um arquivo contendo funções do kernel do NT, suscetíveis a ataques cibernéticos) por meio de uma técnica de conexão em linha. Os ganchos em linha desempenham um papel significativo na execução da carga útil final. O mecanismo de gatilho, para a implantação da carga útil, mostra a criatividade do desenvolvedor do malware. Função sub_180001000 é responsável pela implementação dos ganchos em linha.

 

Função sub_180001000 salva inicialmente os endereços das 3 funções de desenvolvimento usadas para enganar. As funções de desenvolvimento são responsáveis por sequestrar o fluxo de controle em funções conectadas do Windows. Depois de armazenar os endereços, Sub_1800025EC é executado para resolver os endereços das funções de API (Interface de Programação de Aplicativos) de destino para conexão.

Funções de desenvolvimento na função sub_180001000

Sub_1800025EC carrega ntdll.dll no espaço de endereço do processo de carregamento usando a função Carregar biblioteca A. Após o carregamento do ntdll, função Obtenha o endereço do Proc é usado para resolver os endereços das funções:

• NT Abrir arquivo
• NT Criar seção
• Visualização do mapa NT da seção

Funções LoadLibraryA e GetProcAddress

Depois de obter os endereços nas páginas de memória das funções de desvio para enganchar, o carregador usa a função VirtualProtect para alterar as permissões de memória das páginas de destino. Depois de alterar as permissões, o carregador grava os ganchos em linha em sub_180002978. Então VirtualProtect é chamado novamente para restaurar as permissões da página.

Funções do VirtualProtect e sub_180002978

Os dados passados para VirtualProtect em tempo de execução é mostrado na imagem abaixo. A chamada para VirtualProtect muda de ntdll.nt Abrir arquivo permissão de página para 0x40 (PAGE_EXECUTE_READWRITE).

Dados passados/chamados para a função VirtualProtect

Depois de alterar as permissões da página do ntdll.nt Abrir arquivo, o carregador modifica a sequência inicial de bytes não NT Abrir arquivo API executando a função sub_180002978.

função sub_180002978 modificando a API NtOpenFile

A conexão em linha envolve as seguintes etapas:

ntdll.ntOpenfile antes da execução (hook) da função sub_180002978

• Depois sub_180002978 é executado, uma chamada para NT Abrir arquivo faz com que o código do malware vá para a localização 1800023D4 (desvio). É assim que ganchos em linha maliciosos alteram o fluxo de execução das APIs.

Ligue para NTOpenfile fazendo com que o malware saísse para 1800023D4

• Depois de escrever o gancho, VirtualProtect é usado novamente para restaurar a permissão da página do ntdll.nt Abrir arquivo para 0x20 (PAGE_EXECUTE_READ).

Função VirtualProtect usado para restaurar a permissão da página Ntdll.ntopenfile

• O processo de alterar a permissão de memória e escrever ganchos em linha é repetido em um loop do-while, para o resto das funções de destino, NT Criar seção e Visualização do mapa NT da seção.

 

Resumo das funções conectadas

Após a conexão bem-sucedida, sempre que as funções de destino são chamadas no espaço de endereço do processo do carregador, o fluxo de controle é transferido para os respectivos endereços de gancho em linha:

Função alvoGancho em linha (Desvios)ntdll.nt Abrir arquivo1800023D4Ntdll.nt Criar seção1800041ECNTDLL.NTMAP Visualização da seção180001D4C

Carregar gdiplus.dll é exclusivo do Bumblebee

A função final executada pelo carregador é Sub_1800013A0. O malware usa uma função Carregar biblioteca W para carregar o módulo DLL. Em seguida, ele usa a função Obtenha o endereço do Proc para obter o endereço de uma função específica exportada pela biblioteca carregada.

Isso representa uma etapa crucial na implantação da carga principal no sistema da vítima. Ao contrário dos TTPs (táticas, técnicas e procedimentos) dos carregadores de malware comuns, é aqui que o carregador do Bumblebee é criativo.

Função sub_1800013A0 com as funções LoadLibraryW e GetProcAddress

O módulo gdiplus.dll é carregado no espaço de endereço da memória do processo. Gdiplus.dll é um módulo importante, contendo bibliotecas que suportam o GDI Window Manager, no sistema operacional Microsoft Windows.

Execução em tempo de execução da função Sub_1800013A0

O módulo gdiplus.dll é executado na última função do carregador de malware. Essa é a primeira instância em que a carga útil MZ descompactada é usada diretamente pelo carregador. Portanto, o carregamento deste módulo parece suspeito. Além disso, um endereço base incomum (0x1d54fd0000) é atribuído ao carregado gdiplus.dll módulo.

Endereço base incomum atribuído a gdiplus.dll

Ao examinar mais detalhadamente a memória suspeita, descobriu-se que o endereço é uma página mapeada com permissão RWX no espaço de endereço do carregador. Esse é um caso de uso clássico de esvaziamento, em que o conteúdo do módulo é substituído por artefatos maliciosos descompactados.

Endereço como uma página mapeada com permissão RWX

Mas, em nossa análise até agora, não encontramos nenhum código que faça o esvaziamento. Então, como o malware alterou o conteúdo do gdiplus.dll? Curiosamente, foi aqui que o desenvolvedor de malware decidiu ser criativo! O engate visto anteriormente é responsável por esvaziar o módulo carregado com a carga útil descompactada. Mais detalhes sobre o mesmo são abordados na seção a seguir.

Investigando os ganchos e o gatilho

Conforme visto na seção anterior, o malware conecta 3 APIs específicas:

• NT Abrir arquivo
• NT Criar seção
• Visualização do mapa NT da seção

A seleção da API não é aleatória. O funcionamento interno de carregar qualquer DLL via Carregar biblioteca A API usa as 3 funções mencionadas acima. Conectar essas funções dá ao malware a flexibilidade de implantar secretamente a carga útil descompactada. Esse recurso torna difícil para os pesquisadores caçar a carga principal.

A função de desvio em 0x180001D4C é usada para conectar a função Visualização do mapa NT da seção, que estabelece as bases para o esvaziamento do módulo carregado (neste caso, gdiplus.dll) como o binário Bumblebee descompactado. A função de desvio é capaz das seguintes ações:

• Criação de objeto de seção via NT Criar seção API
• Mapeamento da visualização de gdiplus.dll para o espaço de endereço do carregador via Visualização do mapa NT da seção
• Escrevendo a carga descompactada na visualização mapeada de gdiplus.dll
• Desalocando a memória de pilha que contém a carga útil descompactada das etapas anteriores

A implementação da função de desvio em 0x180001D4C mostra o uso de um ponteiro para o NT Criar seção API, para criar um objeto de seção a ser usado posteriormente no mapeamento do gdiplus.dll módulo.

Ponteiro para a API NtCreateSection

Depois de criar um objeto de seção, a função de desvio chama Visualização do mapa NT da seção, por meio de um ponteiro. Agora, a visualização da seção é criada pelo sistema. A função Sub_180002E74 é responsável por preencher a visualização mapeada com uma carga útil descompactada.

Ponteiro para NTMapViewOfSection junto com a função sub_180002E74

O endereço da visualização mapeada, retornado por Visualização do mapa NT da seção O ponteiro no processo do carregador, que é 0x1D54F5D0000, é o mesmo endereço visto ao examinar os módulos do processo.

Endereço da visualização mapeada retornado por NTMapViewOfSection

Endereço base incomum atribuído a “gdiplus.dll”, conforme visto anteriormente

A visualização mapeada começa em 0x1D54F5D0000. O carregador despeja a carga útil descompactada aqui, esvaziando gdiplus.dll. Portanto, a carga útil final do Bumblebee permanece oculta dentro do módulo carregado. gdiplus.dll.

Logo após mapear a visualização, a função de desvio é executada Sub_180002E74 para iniciar a escrita do binário descompactado.

Função Sub_180002E74 responsável por preencher a visualização mapeada com a carga final

Os ganchos são ativados assim que o carregador carrega o gdiplus.dll módulo via Carregar biblioteca W API. Em seguida, a carga útil é carregada secretamente no gdiplus.dll módulo. A carga final é uma DLL, portanto, o carregador precisa chamar explicitamente uma função exportada para acionar a execução.

Nesse caso, o carregador obtém o endereço da função exportada Definir caminho via função Obtenha o endereço do Proc. O controle é então transferido para a carga final pela chamada final para Definir caminho, fornecendo o nome do programa carregador como argumento.

O carregador obtém o endereço da função exportada “setPath” via getProcAddress

A imagem abaixo mostra a função Definir caminho exportado pela carga útil descompactada do Bumblebee.

Função setPath

Análise da carga útil principal do Bumblebee

O principal componente malicioso da abelha é executado na memória, quando a abelha está oca gdiplus.dll é carregado por meio do Carregar biblioteca API. Quando o módulo é carregado na memória, a função DLL principal cria um novo tópico e executa Sub_180008EC0 rotina.

A função dllMain do carregamento útil do bumblebee

Sub_180008EC0 rotina é uma função bastante grande que é responsável por todas as atividades maliciosas realizadas pelo Bumblebee no sistema comprometido.

Fluxo lógico da função Sub_180008EC0

Verificações anti-VM

A primeira atividade realizada por Sub_180008EC0 é verificar se há um ambiente de máquina virtual (VM). Se a função retornar True, o Bumblebee desligará executando o Processo de saída função.

Sub_18003DA0 executa a verificação da VM

A rotina de verificação da VM é. Rigoroso. Ele emprega várias técnicas para garantir que o malware não seja executado em um ambiente de sandbox usado por pesquisadores de segurança. Algumas das características interessantes são:

• Iteração por meio de processos em execução por meio de funções Crie um instantâneo do ToolHelp32, processo 32 primeiro W, e Process32 NextW.

Funções de malware que ajudam na iteração dos processos em execução

• Cada processo em execução é comparado a uma lista de nomes de programas.

Processo em execução sendo comparado com a lista de nomes de programas

• O malware também verifica nomes de usuários específicos usados em ambientes de área restrita para confirmar a ausência de uma VM.

Verificação de malware para nomes de usuário específicos

• A rotina de verificação da VM também enumera os serviços ativos do sistema em execução por meio do Gerenciador OpenSC W API. Os nomes dos serviços comuns usados pelos softwares de VM são armazenados em uma matriz.

Enumerando serviços ativos do sistema em execução via OpenSCManagerW

• Ele também verifica o diretório do sistema em busca de drivers e arquivos de biblioteca comuns usados por aplicativos de VM.

Verificação do sistema em busca de drivers e arquivos de biblioteca comuns usados por aplicativos populares de VM

• A rotina também verifica os tubos nomeados para identificar a presença da VM.

Verificando tubos nomeados

Esses são alguns exemplos de técnicas empregadas pelo malware para identificar ambientes de análise. Ele também possui outras funcionalidades criadas, como o uso de recursos de WMI e registro para identificar informações de hardware e verificar a presença de ambientes de VM instalados no sistema de destino.

Criação de eventos

Após as verificações da VM, se for seguro continuar, o malware cria um evento. A ID do evento é 3C29FEA2-6FE8-4BF9-B98A-0E3442115F67. Isso é usado para sincronização de tópicos.

O evento criado por malware

Persistência

O malware usa wsript.exe como um vetor de persistência para executar o malware toda vez que o usuário faz login no sistema. A instrução VB é escrita em um .vbs arquivo. Isso é realizado quando o C2 envia o comando “ins” como uma tarefa a ser executada no sistema.

Wsript.exe

Instrução VB escrita em um arquivo.vbs

Manipulação de tokens

O malware realiza a manipulação de tokens para aumentar seu privilégio no sistema de destino, concedendo ao processo de malware uma Veja o privilégio de depuração. Com esse privilégio, o malware pode realizar operações arbitrárias de leitura/gravação.

O malware recebe o “SEDebugPrivilege”

O malware é capaz de realizar injeções de código para implantar código malicioso em processos em execução usando várias APIs. O malware recupera dinamicamente os endereços das APIs necessárias para a injeção de código. A carga principal do bumblebee vem com arquivos incorporados que são injetados no processo em execução para atacar ainda mais a vítima.

Lista de APIs usadas para realizar injeções de código

Injeção de código via NTQueueAPCThread

Quando o malware recebe o comando junto com um buffer de DLL que é injetado, o malware começa a procurar uma lista de processos no sistema. Um dos executáveis da lista é escolhido aleatoriamente para injetar uma DLL maliciosa.

Malware procurando uma lista de processos no sistema

Lista de executáveis

Após a injeção de código, o malware:

• Cria um processo a partir da imagem executável selecionada anteriormente via COM (Component Object Model), no qual o acesso aos dados de um objeto é recebido por meio de interfaces, em um estado suspenso.
• Enumera por meio do processo em execução por meio do Crie um instantâneo do ToolHelp32 API para encontrar o processo recém-gerado criado na etapa anterior.
• Quando o processo é encontrado, o malware manipula o token e adquire o Veja o privilégio de depuração token para realizar mais manipulações de memória.
• Se a manipulação do token for concluída com sucesso, o malware injeta um código de shell no processo para fazer dormir.

Malware criando um processo e injetando código de shell nele

Função Sub_180037A80 é responsável por realizar a injeção do shellcode no processo gerado no estado suspenso.

Função Sub_180037A80

Depois de injetar o shellcode no processo, o malware retorna ao processo. Em seguida, execute a função Sub_18003A9BC para finalmente injetar DLL maliciosa criando várias seções e visualizações de memória.

Executando a função sub_18003A9BC para injetar DLL maliciosa

O código DLL é executado por meio do Tópico NTQueueAPC API, que é resolvida dinamicamente durante a execução.

Código DLL executado por meio da API NtQueueAPCThread

Rede C2

A Infraestrutura de Comando e Controle, também conhecida como C2 ou C&C, é uma coleção de ferramentas e técnicas usadas para manter contato com um sistema de dispositivos comprometido após a obtenção do acesso inicial. O endereço IP do C2 pode ser recuperado do código de carregamento, conforme mostrado abaixo.

Recuperando o endereço IP do C2

O C2 envia periodicamente tarefas ao agente para serem executadas no sistema. O malware usa extensivamente o WMI (Windows Management Infrastructure) para coletar informações básicas da vítima, como nome de domínio e nome de usuário, e enviar as informações comprometidas para o C2. O C2 distingue os agentes ativos com base na ID do cliente atribuída a cada um.

Dados transferidos na comunicação C2

Curiosamente, a string do agente do usuário usada pelo malware para comunicação é “bumblebee”.

Tráfego de saída

Dados transferidos para fora do sistema comprometido

Parâmetros do cliente

• ID do cliente
• nome_do_grupo
• versão_sys
• Nome do usuário
• versão_cliente

Tráfego de entrada

Comandos recebidos pelo sistema comprometido

Parâmetros do cliente

• status_resposta
• tarefas

Comandos suportados

O campo de tarefa na resposta C2 contém um dos seguintes comandos:

ComandoDescriçãoDexDownloads executáveisDllKill LoaderInsPersistenceDij.dll injetar

Uma história de DLLs e ganchos agrupados

A carga principal vem com duas DLLs incorporadas no binário. A finalidade e a função de ambas as DLLs são as mesmas, mas uma é de 32 bits e a outra de 64 bits. Eles são usados para realizar mais manipulações de engate e controlar o fluxo.

Assinaturas DLL (SHA256)

• 32 bits: B9534DDEA8B672CF2E4F4ABD373F5730C7A28FE2DD5D56E009F6E5819E9E9615
• 64 bits: 1333CC4210483E7597B26042B8FF7972FD17C23488A06AD393325FE2E098671B

Nesta seção, examinaremos o funcionamento interno da DLL embutida de 32 bits. O módulo procura um conjunto específico de funções no ntdll.dll, kernel32.dll, kernelbase.dll, e advapi32.dll para remover posteriormente quaisquer ganchos presentes no código. Isso também removerá todos os ganchos implementados pelo EDR/AV (Endpoint Detection and Response/Antivirus) usados para monitoramento.

Funções em ntdll.dll verificadas quanto aos ganchos existentes

Funções em kernel32.dll verificadas quanto aos ganchos existentes

Em kernelbase32.dll, as seguintes funções são verificadas em busca de ganchos já existentes:

Funções em kernelbase32.dll verificadas quanto aos ganchos existentes

Funções em advapi32.dll verificadas quanto aos ganchos existentes

O mecanismo de desengate

O processo de desengate envolve as seguintes etapas:

• O módulo recupera identificadores para DLLs de destino por meio do API GetModuleHandleW. O identificador retornado pela API é para a DLL carregada na memória pelo processo de malware, ou seja, o processo responsável pela execução do bumble loader, que é rundll32.exe.
• Em seguida, o malware constrói o caminho absoluto para as DLLs de destino por meio do Deixe o diretório do sistema A API, para acessar o diretório system32, onde estão localizadas todas as DLLs do sistema.
• Um ponteiro para Memória virtual NTProtect é calculado seguindo a geração do caminho da DLL.
• Função Sub_10005B90 é chamado para fazer o desengate. Os parâmetros passados para a função são:
  • Primeiro argumento: caminho absoluto para a DLL de destino
  • Segundo argumento: Manipule a DLL de destino já carregada
  • Terceiro argumento: deslocamento para matriz contendo funções de destino exportadas pela DLL de destino
  • Quarto Arg: Nulo
  • Quinto argumento: ponteiro para NTProtectVirtualMemory

Etapas para desengatar o mecanismo

A função Sub_10005B90 executa as seguintes operações:

• Mapeia uma nova cópia da DLL de destino do disco rígido para endereçar o espaço do processo de malware por meio de funções Criar arquivo A, Crie um mapeamento de arquivos A, e Visualização do mapa do arquivo.
• Função de chamadas Sub_10005D40 para realizar ou desengate. Os seguintes dados são passados para a função:
  • Primeiro argumento: endereço mapeado de uma nova cópia da DLL
  • Segundo argumento: O mesmo que sub_10005b90
  • Third Arg: O mesmo que Sub_10005B90
  • Quarto argumento: O mesmo que sub_10005b90
  • Quinto Arg: O mesmo que Sub_10005B90
• Depois de desenhar, a visualização mapeada é liberada por meio do Desmapear a visualização do arquivo API.

Operações realizadas pela função sub_10005B90

A lógica usada para desenhar é simples. O malware compara a função de destino no módulo carregado na memória com a função definida no módulo mapeado via Visualização do mapa do arquivo. Se os dois códigos não corresponderem, o conteúdo do módulo mapeado será gravado no módulo carregado, para restaurar o estado da versão mapeada do disco rígido.

O malware passa pelas exportações da DLL carregada e executa uma correspondência de string com o conjunto de nomes de funções armazenados como uma matriz em um loop. O sub_10005930 é responsável pela correspondência de strings.

Correspondência de cadeias de caracteres com o conjunto de nomes de funções

Quando o nome da função na matriz do malware corresponde à função exportada do módulo carregado, o sinalizador é definido como [v8] e interrompe o loop. Isso ocorre nas seguintes etapas:

• O malware armazena os endereços das funções de ambos os módulos (carregados e mapeados).
• Em seguida, os códigos de função carregados e mapeados são verificados quanto aos ganchos, identificando diferenças no código. Se o código carregado for igual ao mapeado, ele sai do loop e continua a iterar pelas funções restantes.

O malware corresponde à função exportada

Se o código carregado não for igual ao código mapeado, as seguintes operações serão executadas pelo malware para desconectá-lo:

• VirtualQueryEx A API é chamada para recuperar o endereço base da página que contém a função de destino.
• Então Memória virtual NTProtect A API é usada para alterar as permissões da página que contém o código da função (READ_WRITE_EXECUTE).
• Consulta virtual é usado novamente para verificar a permissão; se a página pode ser escrita ou não.
• Função sub_10005890 é chamado para restaurar o módulo carregado com o conteúdo do módulo mapeado. Agora, as funções nos módulos mapeados e carregados estão no mesmo estado.

O malware não corresponde à função exportada

Depois de limpar todos os ganchos nas funções selecionadas, o malware instala os ganchos.

Funções Exceção RaiseFailFast de kernel32.dll e api-ms-win-core-errorhandling-l1-1-2.dll estão enganados. Em seguida, a função de desvio Sub_100057F0 sequestra o fluxo de controle quando as funções acima são chamadas pelo sistema após a conexão ser feita pelo malware.

Instalação de ganchos

Função Sub_100057F0 simplesmente retorna a chamada.

Função sub_100057F0

A DLL incorporada tem uma estratégia de conexão semelhante à do carregador Bumblebee. Várias funções usadas pelo sistema, ao carregar um módulo DLL, são conectadas e wups.dll é carregado para acionar a corrente.

Conectando as funções usadas para carregar a DLL e carregar o wups.dll

API de destinoFunção de desvioVisualização ZWMAP da seção SUB_10004C50ZW Abrir seção SUB_10004FF0ZW Criar seção SUB_10004BC0ZW Abrir arquivo SUB_10004F20

Atualizações de código na natureza

Depois de analisar muitas amostras na natureza, observamos as modificações no código do carregador.

Modificações de código proeminentes feitas no carregador Bumblebee desde sua descoberta

A amostra da extrema esquerda na imagem acima é a que abordamos neste relatório. Como podemos ver no fluxo lógico do carregador, o desenvolvedor do malware modificou o código do carregador em outras duas amostras. Todas as amostras observadas na natureza são módulos DLL de 64 bits com uma função exportada que tem uma string gerada aleatoriamente como nome da função. Isso pode ser justificado pelo fato de que o código desempenha um papel importante na detecção de malware por produtos de segurança. Para contornar esse obstáculo, os desenvolvedores de malware fazem alterações no código e no design do malware.

As amostras mais recentes de carregadores disponíveis contêm várias cargas úteis, como faróis CobaltStrike e projetos Meterpreter, ao contrário da carga útil personalizada do bumblebee vista na primeira geração.

Indicadores de compromisso (IOCs)

Bináriof98898df74fb2b2fad3a2ea2907086397b36ae496ef3f4454bf6b7125fc103b8IPv445.147.229. 23:43