BRONZE SANDCASTLE usa Sandboxie para carregar Meterpreter modificado

A Counter Threat Unit (CTU) da Sophos publicou em 20 de outubro de 2026 a análise de um grupo de espionagem que batizou de BRONZE SANDCASTLE, atribuído com base em evidências operacionais a um ator baseado na China. O relatório, assinado pela equipe de pesquisa da CTU e por Gabor Szappanos, reúne incidentes observados entre agosto de 2025 e agosto de 2026 em organizações da Ásia e da África.

O traço mais característico do grupo não é um malware inédito, e sim uma técnica repetida com disciplina incomum: o carregamento lateral de DLL (DLL sideloading) usando executáveis legítimos do Sandboxie, ferramenta de isolamento de aplicações bastante conhecida entre administradores Windows. É essa assinatura operacional, mais do que o código em si, que permitiu à Sophos separar a atividade de grupos vizinhos.

A relevância está menos no ineditismo técnico e mais no que o caso revela sobre maturidade operacional: um adversário que troca payload sem trocar binário, que esconde o fluxo de execução por trás de uma máquina de estados virtualizada e que migra a entrega de configuração para o GitHub tende a sobreviver a detecções baseadas em arquivo.

BRONZE SANDCASTLE: por que um nome novo

A CTU afirma ter criado a designação BRONZE SANDCASTLE porque não conseguiu vincular a atividade de forma confiável a BRONZE PRESIDENT — grupo também conhecido como Mustang Panda e HoneyMate — nem a BRONZE ATLAS, apesar da sobreposição geográfica de alvos. Na nomenclatura da CTU, o prefixo BRONZE identifica atores avaliados como ligados à China.

O argumento de atribuição geográfica apresentado no relatório é de ritmo de trabalho: a maior parte da atividade ocorre no fuso UTC+8, compatível, segundo a Sophos, com a jornada conhecida como 996, difundida no setor de tecnologia chinês. Vale separar o que é fato do que é inferência — o padrão de fuso é observação; a vinculação a um Estado não é afirmada no material público.

As vítimas identificadas nos incidentes estão nas Filipinas, em Taiwan, no Afeganistão e na Namíbia, com um caso provável na República da Coreia. O relatório não nomeia setores econômicos, e não há contagem de organizações afetadas. O vetor de acesso inicial também não é descrito, o que é uma lacuna importante para quem tenta montar defesa na borda.

O carregamento lateral com binários do Sandboxie

A técnica é conceitualmente simples: colocar uma DLL maliciosa ao lado de um executável assinado que a carregue por nome, de modo que a execução comece dentro de um processo de reputação boa. O grupo mantém um repertório fixo de pares, o que é uma dádiva para a detecção — e a Sophos publicou a tabela completa. Os principais:

A lista mistura software de produtividade (Java, Krita, o leitor de tela NVDA, o cliente LINE) e utilitários Sysinternals (Vmmap, BgInfo). Nenhum desses binários é malicioso — o abuso está na ordem de busca de bibliotecas do Windows.

O ponto que importa para a defesa é o que vem depois. A DLL carregada não traz o payload embutido: ela lê um arquivo config.ini cifrado no mesmo diretório, decifra o conteúdo e o executa em memória. Um dos exemplares documentados é um arquivo ZIP com exatamente três itens — o executável limpo, a DLL e o config.ini. A consequência operacional é direta: o operador muda comportamento editando um arquivo de texto cifrado, sem recompilar nem redistribuir a DLL, e a execução não deixa artefato adicional em disco.

Ofuscação e o backdoor derivado do Meterpreter

A DLL maliciosa usa achatamento de fluxo de controle: em lugar de desvios diretos, há um despachante com máquina de estados virtualizada. Um valor de estado indexa uma tabela, o valor obtido passa por uma rotina própria de mistura de bits — trocas de bytes, rotações, inversão e negação — e o resultado indexa uma tabela de saltos, seguida de um salto indireto. Alguns índices resolvem para posições de passagem, apenas para dificultar a análise estática.

O payload decifrado é um backdoor cujo cabeçalho funciona como carregador de PE independente de posição, isto é, um carregador reflexivo. A Sophos aponta semelhanças com o shellcode stageless do Metasploit: execução independente de posição, validação manual de PE e carregamento em memória de um executável embutido. As diferenças, porém, são decisivas para quem assume que se trata de Meterpreter padrão:

• a resolução de APIs usa funções de hash e transformação próprias, e não o algoritmo ROR13 empregado pelo Metasploit;
• a base de código é significativamente maior e mais complexa que o shellcode típico do framework;
• há elementos do projeto COFFLoader nas amostras, o que sugere, segundo a Sophos, um Beacon Object File (BOF) próprio para funcionalidades de pós-exploração;
• cadeias de decoração de funções C++ encontradas em memória apontam para capacidades de roubo de dados.

Duas versões do payload foram identificadas, numeradas 1.1.5 e 1.1.7. Na inicialização, o implante envia um objeto JSON com um bloco de informações que inclui nome de host, nome de usuário, GUID, domínio, versão do sistema operacional, endereços IP interno e público, listagem de processos com PID e método de execução, diretório de trabalho, página de código, arquitetura da CPU, horário de início e tipo de implante.

Infraestrutura de comando e controle

As duas versões diferem na forma de receber configuração, e essa diferença resume a tendência de abuso de serviços legítimos. A versão 1.1.5 contatava dois domínios que imitam marcas reais do setor de aviação e logística — padrão clássico de typosquatting para passar por tráfego corporativo plausível. A versão 1.1.7 passou a baixar arquivos de configuração cifrados de um repositório no GitHub, acessado pela API pública, com histórico muito curto; além dos arquivos identificados como configuração, o repositório contém arquivos .ts cifrados que podem ser implantes.

A Sophos também observou o uso de serviços legítimos de compartilhamento e de mensageria em tempo real como possível canal de tarefas. Nomes e indicadores completos estão na planilha de IoCs publicada pela SophosLabs.

Na fase de pós-comprometimento, o relatório descreve dois movimentos: levantamento de rede e de contas com comandos nativos net do Windows, e criação de cópias de sombra de volume com o vssadmin.exe para então copiar o ntds.dit — a base do Active Directory, que concentra credenciais, políticas de grupo e a configuração do domínio. Em termos de impacto, essa última ação é a que transforma um comprometimento de estação em comprometimento potencial de domínio.

Detecção, limites e recomendações

A própria Sophos reconhece o limite da abordagem tradicional: como os payloads são cifrados e decodificados em tempo de execução, a detecção estática baseada em arquivo tende a ser ineficaz. A orientação é deslocar o esforço para comportamento e memória. Em termos práticos:

• alerte sobre DLLs que leem um arquivo local e, imediatamente depois, executam código em memória — o par leitura-de-config.ini seguido de execução é o sinal mais específico desta campanha;
• monitore padrões de carregamento reflexivo, cabeçalhos PE anômalos em memória e processos com comportamento de shellcode independente de posição;
• trate como suspeita a presença de binários do Sandboxie, do Krita, do NVDA ou de utilitários Sysinternals em diretórios fora do caminho de instalação esperado, acompanhados de DLLs de mesmo nome que as da tabela acima;
• audite execuções de vssadmin.exe e qualquer acesso a ntds.dit fora de janelas de backup conhecidas, e habilite o registro de criação de processos com linha de comando;
• revise o uso de serviços legítimos de armazenamento e de mensageria em tempo real como destino de tráfego de saída a partir de servidores, onde esse tráfego raramente tem justificativa;
• consulte a lista de indicadores publicada pela SophosLabs e aplique as detecções do fornecedor, lembrando que assinaturas por arquivo cobrem apenas as amostras já conhecidas.

É importante calibrar expectativas. Os indicadores de rede têm vida curta — a migração de domínios próprios para o GitHub, entre as versões 1.1.5 e 1.1.7, mostra que o grupo ajusta infraestrutura com facilidade. Já a tabela de pares executável-DLL é um ativo de detecção mais duradouro, porque mudá-la exigiria reescrever a cadeia de carregamento. Nenhum CVE é citado no relatório, e sem o vetor de acesso inicial documentado não é possível recomendar correção de uma falha específica; a defesa aqui é de visibilidade e de resposta, não de patch.

Conclusão

BRONZE SANDCASTLE não se destaca por sofisticação criptográfica ou por exploração de zero-day, mas por economia de meios: binários assinados de terceiros, configuração cifrada em arquivo externo, ofuscação suficiente para cansar o analista e um backdoor derivado de ferramenta pública o bastante para parecer comum e diferente o bastante para escapar de regras feitas para o Metasploit padrão. É o mesmo movimento observado em outras campanhas de espionagem recentes — inclusive na campanha CL-UNK-1211 contra servidores Linux de governos —, em que o diferencial do adversário está na operação, não no arsenal.

O que acompanhar a seguir: a publicação do vetor de acesso inicial, eventual vinculação futura a BRONZE PRESIDENT caso surjam sobreposições de infraestrutura, e o aparecimento de uma versão 1.1.8 ou posterior que troque novamente o canal de configuração. Para equipes de defesa em organizações com presença na Ásia e na África, a ação imediata é validar se a telemetria de endpoint registra carregamento de DLL e execução em memória com detalhe suficiente para que as regras descritas acima sejam acionáveis.

Fontes e referências

• Sophos Counter Threat Unit — “BRONZE SANDCASTLE deploys modified Meterpreter shells”: sophos.com
• SophosLabs — repositório público de indicadores de comprometimento: github.com/sophoslabs/IoCs
• Sophos (Secureworks CTU) — “BRONZE STARLIGHT Ransomware Operations Use HUI Loader”, referência de nomenclatura dos grupos BRONZE: sophos.com
• Hackread — “China-Based BRONZE SANDCASTLE Hackers Abuse Sandboxie to Load Backdoors”: hackread.com