Bumblebee ajusta C2 e entrega cargas diferentes conforme o ambiente da vítima

O carregador usa DLL empacotada, configuração cifrada com RC4 e seleção de payloads que muda entre máquinas em grupo de trabalho e hosts ligados a domínio Active Directory.

Componente	Carregador Bumblebee distribuído como binário semelhante a DLL, empacotado com packer próprio e entregue por arquivos ISO ou VHD.
Vetor	A cadeia observada embute a DLL empacotada no primeiro estágio; em uma variação de junho de 2022, arquivos VHD acionavam PowerShell para baixar e decifrar a DLL.
Impacto	Após validações anti-análise, o malware faz check-in cifrado no C2 e pode receber tarefas para baixar e executar arquivos, injetar código ou carregar shellcode, com payloads diferentes conforme o tipo de ambiente.
Prioridade	Priorizar detecção de ISO/VHD suspeitos, DLLs empacotadas, check-ins JSON cifrados com atrasos recorrentes e execução de payloads de segundo estágio em hosts de domínio.
Artefatos	Configuração em memória com chave ASCII usada em RC4, campo group_name, bloco de servidores C2 e identificador client_id derivado de nome da máquina e GUID.
Mitigação	Restringir montagem de imagens não confiáveis, controlar execução de scripts, monitorar carregamento de DLLs incomuns e isolar máquinas com sinais de comunicação C2 ou injeção de payload.

Resumo técnico

Bumblebee aparece como um carregador de malware com evolução rápida na etapa de entrega, no empacotamento e na lógica de comunicação com comando e controle. A amostra típica chega como um binário semelhante a DLL, protegido por um packer próprio, e foi observada embutida em arquivos de primeiro estágio como ISO ou VHD. Em um intervalo curto de junho de 2022, a cadeia também usou VHD com um script PowerShell responsável por baixar e decifrar a DLL empacotada, mas essa rota deixou de ser dominante no material analisado e a DLL voltou a aparecer diretamente dentro do primeiro arquivo entregue.

Depois do desempacotamento, o malware executa verificações destinadas a evitar ambientes de sandbox e análise. Parte desse código foi associada ao projeto aberto Al-Khaser, o que indica reaproveitamento de técnicas conhecidas de identificação de laboratório. Se as verificações não interrompem a execução, Bumblebee carrega sua configuração para a memória a partir de ponteiros presentes na seção .data. Essa configuração inclui uma chave ASCII usada com RC4, campos cifrados e uma lista de servidores de comando e controle, com a observação de que muitos endereços no bloco podem funcionar como elementos falsos ou de distração.

Fluxo técnico

A configuração interna é composta por quatro ponteiros para buffers cifrados em uma estrutura contígua. O primeiro bloco reserva até 80 bytes para a chave RC4, embora as chaves observadas sejam mais curtas. Outros dois blocos de 80 bytes e um bloco de 1024 bytes são decifrados com essa mesma chave. Um dos campos decifrados frequentemente contém o valor 444, sem uso funcional claro no comportamento descrito. Outro campo contém o identificador ASCII chamado pelo próprio malware de group_name, enquanto o bloco maior armazena a lista de servidores C2 que podem ser usados na comunicação.

Para identificar a vítima, Bumblebee monta um client_id pseudorrandômico e específico da máquina. Esse valor é calculado a partir de parâmetros relativamente estáveis do host, incluindo nome da máquina e GUID, e depois convertido em um resumo MD5. Com esse identificador, o group_name e outros dados coletados do sistema, o malware constrói uma requisição de check-in em JSON. O conteúdo é cifrado com a mesma chave RC4 da configuração e enviado repetidamente ao C2 com atrasos aleatórios entre cerca de 25 segundos e 3 minutos, mesmo quando o servidor não responde.

As respostas do C2 também usam JSON cifrado com RC4. Quando não há tarefa, a resposta pode ser vazia; quando há execução planejada, a estrutura inclui uma lista de tarefas, cada uma com um nome de comando e um payload codificado em base64 dentro de task_data. Entre os comandos observados, DEX leva ao download e execução de um arquivo no disco, enquanto DIJ e SHI se relacionam a download e injeção de código ou shellcode. Esses nomes são relevantes para defesa porque delimitam o tipo de efeito esperado no endpoint sem exigir reprodução operacional da cadeia.

Um comportamento importante foi alterado no servidor C2 por volta de junho de 2022. Antes da mudança, quando um client_id era aceito a partir de um IP externo, o C2 deixava de aceitar outros identificadores diferentes vindos do mesmo IP público. Em uma organização com várias máquinas atrás do mesmo endereço de saída, isso limitava a quantidade de vítimas ativas aceitas pelo backend. A remoção dessa política aumentou o número de conexões estabelecidas e o volume de tráfego C2, sugerindo mudança de um modelo mais restritivo para uma operação com maior capacidade de acompanhamento de hosts infectados.

Superfície afetada

A superfície mais exposta envolve estáções Windows que recebem arquivos de imagem ou contêineres de primeiro estágio e permitem a execução do conteúdo embutido. O comportamento posterior muda de acordo com o contexto de rede da máquina. Hosts ligados apenas a WORKGROUP tendem a receber o comando DEX, resultando na gravação e execução de arquivos associados a ladrões de informação ou trojans bancários. Máquinas ingressadas em domínio Active Directory, por outro lado, tendem a receber comandos de injeção como DIJ ou SHI, com payloads associados a estruturas de pós-exploração como Cobalt Strike, Sliver ou Meterpreter.

Essa diferença torna o ambiente de domínio um sinal de interesse para o operador. A mesma família de carregador consegue operar como etapa inicial de infecção em máquinas isoladas e como porta de entrada para ferramentas mais avançadas quando a vítima está em uma rede corporativa. A análise também mostra que group_name não é suficiente como único critério de agrupamento: amostras com a mesma chave RC4 e group_name diferente podem se comportar da mesma forma, entregar as mesmas cargas e bloquear os mesmos client_id. A chave de cifragem se mostra um pivô mais coerente para relacionar amostras e botnets.

• Hosts que montam ou processam arquivos ISO e VHD recebidos por canais não confiáveis.
• Estáções Windows com execução de PowerShell ou carregamento de DLL fora de caminhos e assinaturas esperadas.
• Máquinas em domínio Active Directory, nas quais o carregador tende a entregar ferramentas de pós-exploração por injeção.
• Ambientes com NAT corporativo, porque a mudança no C2 removeu a restrição anterior de um único client_id aceito por IP público.

Hunting e telemetria

A investigação deve combinar telemetria de endpoint, proxy, DNS, EDR e identidade. No endpoint, os sinais mais úteis incluem montagem recente de ISO ou VHD seguida de carregamento de DLL, execução de script para obter ou decifrar conteúdo, criação de processos a partir de diretórios temporários e presença de binários empacotados com entropia elevada. Como o malware usa verificações anti-análise, falhas silenciosas em ambientes instrumentados e amostras que encerram cedo também devem ser preservadas para comparação com execuções em laboratório controlado.

Na rede, o padrão defensivo não depende de publicar endereços específicos. O que importa é identificar check-ins recorrentes para infraestrutura externa, com corpo de requisição cifrado, formato compatível com JSON antes da cifragem e intervalos variáveis dentro da faixa observada. A resposta pode ser vazia ou conter tarefas cifradas, então ausência de payload não elimina comprometimento. Em hosts de domínio, a correlação deve dar peso a injeção de processo, criação de sessões anômalas, artefatos de frameworks de pós-exploração e conexões subsequentes para servidores de equipe ligados ao payload de segundo estágio.

Para agrupamento de atividade, a chave RC4 extraída de amostras é mais útil do que group_name isolado. Amostras com a mesma chave podem apontar para o mesmo conjunto operacional mesmo quando usam valores distintos de campanha, servidores de borda diferentes ou nomes de grupo divergentes. Quando servidores C2 diferentes retornam os mesmos payloads e aplicam as mesmas regras de aceitação de client_id, isso sugere que esses endereços podem atuar como frentes para um backend comum.

• Montagem de ISO ou VHD seguida por carregamento de DLL empacotada ou execução de script de recuperação de conteúdo.
• Requisições externas repetidas com atrasos aleatórios entre aproximadamente 25 segundos e 3 minutos.
• Processos com injeção de código após recebimento de tarefas equivalentes a DIJ ou SHI.
• Execução de arquivos no disco após tarefa equivalente a DEX, especialmente em máquinas fora de domínio.
• Agrupamento de amostras por chave RC4, payload entregue e comportamento do C2, não apenas por group_name.

Mitigação

A resposta deve começar pela redução da superfície de execução do primeiro estágio. Organizações devem restringir a abertura automática ou não monitorada de arquivos ISO e VHD recebidos por e-mail, mensageria, compartilhamentos externos ou navegação. Controles de aplicação, políticas de execução de scripts e regras de reputação ajudam a impedir que uma DLL empacotada seja carregada sem revisão. Em endpoints com alerta de Bumblebee, a máquina deve ser isolada antes da coleta, porque o carregador pode continuar tentando check-in mesmo sem resposta do C2 e pode receber tarefas adicionais quando o servidor passa a responder.

A contenção precisa considerar o tipo de host. Em máquinas WORKGROUP, a prioridade é buscar executáveis gravados e possíveis ladrões de informação ou trojans bancários entregues como segundo estágio, com revisão de credenciais locais e sessões de navegador. Em hosts ligados a domínio, a prioridade aumenta porque a cadeia observada favorece injeção e ferramentas de pós-exploração. Nesses casos, a resposta deve incluir revisão de credenciais usadas no host, eventos de autenticação lateral, conexões de saída posteriores ao primeiro check-in e evidências de beaconing associado a frameworks ofensivos abusados.

Após a contenção, a organização deve extrair artefatos da configuração quando possível, incluindo chave RC4, group_name, lista de C2 cifrada e material usado na criação do client_id. Esses elementos ajudam a relacionar máquinas afetadas sem depender de indicadores frágeis. A validação final deve confirmar ausência de novas montagens suspeitas, encerramento do tráfego periódico, remoção de payloads de segundo estágio, revisão de credenciais potencialmente expostas e melhoria dos controles sobre arquivos de imagem, PowerShell e carregamento de DLL em diretórios não administrados.

• Bloquear ou exigir inspeção para ISO e VHD provenientes de fontes externas ou não confiáveis.
• Aplicar controle de execução para PowerShell, DLLs e binários criados em diretórios temporários ou de usuário.
• Isolar hosts com check-in recorrente, injeção de processo ou execução de payload após montagem de imagem.
• Investigar máquinas de domínio com prioridade maior por risco de ferramentas de pós-exploração.
• Usar chave RC4, comportamento de C2 e payload entregue como pivôs de correlação entre amostras e incidentes.