Campanha de espionagem alinhada à China usa e-mails de spear phishing com arquivos ZIP, carregador em Rust, carregamento lateral de DLL e canal de comando e controle baseado em Azure Blob Storage.
| Componente | Campanha Operation Dragon Weave, com agente AdaptixC2 chamado AZUREVEIL, carregador RUSTCLOAK e execução por RuntimeBroker_update.exe com UnityPlayer.dll maliciosa. |
| Vetor | E-mails de spear phishing entregam anexos ZIP a alvos na República Tcheca e em Taiwan; a execução começa por arquivo LNK disfarçado de PDF ou por binário incluído no mesmo arquivo compactado. |
| Impacto | Controle remoto do endpoint comprometido, exfiltração de dados, operações em arquivos, execução de comandos, proxy, encaminhamento de portas e execução em memória de Beacon Object Files. |
| Prioridade | Restringir anexos ZIP suspeitos, investigar execução de LNKs e binários originados de arquivos compactados, revisar carregamento lateral de DLL e monitorar uso anômalo de Azure Blob Storage. |
| Setores | Governo, pesquisa, academia, tecnologia e serviços financeiros aparecem como áreas visadas pela campanha. |
| Artefatos | Arquivos e componentes observados incluem LNK disfarçado de PDF, script PowerShell, arquivo DAT intermediário, RuntimeBroker_update.exe, UnityPlayer.dll, RUSTCLOAK e AZUREVEIL. |
A Operation Dragon Weave é uma campanha de espionagem cibernética alinhada à China observada contra autoridades e cidadãos da República Tcheca e de Taiwan. A atividade tem como objetivo instalar um agente AdaptixC2 identificado como AZUREVEIL, com capacidade de controle remoto, execução de comandos e movimentação operacional pós-comprometimento no endpoint afetado. O conjunto de alvos descrito inclui organizações governamentais, instituições de pesquisa, ambientes acadêmicos, empresas de tecnologia e serviços financeiros, o que indica interesse em informações estratégicas, acesso persistente e coleta orientada a setores sensíveis.
A cadeia começa com spear phishing e anexos ZIP preparados para parecerem documentos ou pacotes legítimos. Depois que o conteúdo é extraído, o usuário encontra múltiplos arquivos com aparência plausível, mas a estrutura do pacote foi montada para iniciar payloads em segundo plano. O ponto central da operação é reduzir a fricção de execução pelo usuário e, em seguida, transferir o fluxo para componentes compilados em Rust e para carregamento lateral de DLL, uma técnica que aproveita a confiança de binários aparentemente legítimos para carregar código malicioso com menor ruído operacional.
A campanha usa dois caminhos de infecção. No primeiro, o destinatário abre um arquivo Windows Shortcut, ou LNK, disfarçado como documento PDF dentro do ZIP. Esse atalho aciona um script PowerShell cuja função é extrair o executável RuntimeBroker_update.exe de um arquivo DAT intermediário e iniciá-lo no sistema. O uso de um arquivo DAT como contêiner ajuda a separar o artefato executável do primeiro clique do usuário e pode dificultar triagens superficiais baseadas apenas no conteúdo visível do arquivo compactado.
No segundo caminho, a vítima executa diretamente um binário presente no mesmo arquivo ZIP. Esse binário atua como um dropper autocontido baseado em Rust e também leva à execução de RuntimeBroker_update.exe. Independentemente do caminho inicial, o executável carrega uma DLL maliciosa chamada UnityPlayer.dll por meio de DLL side-loading. Esse padrão é relevante para defesa porque o processo que aparece nos logs pode não carregar um nome obviamente malicioso; a anomalia fica na relação entre o executável, o diretório de execução, a DLL carregada e a origem do arquivo.
Após o carregamento lateral, entra em ação o carregador em Rust chamado RUSTCLOAK. Ele descriptografa e executa o payload principal, o agente AZUREVEIL. O componente realiza verificações anti-análise e foi descrito como projetado para prosseguir apenas quando determina que está sendo executado em ambiente de sandbox. Esse detalhe deve ser tratado com cautela operacional: para equipes de análise, a lógica de ambiente pode alterar o comportamento observado em laboratório e produzir diferenças entre execução controlada, detonação automatizada e execução real em endpoint de usuário.
O AZUREVEIL usa Microsoft Azure Blob Storage para comando e controle. Em vez de depender de uma conexão direta tradicional entre o host infectado e um servidor do operador, o modelo descrito é de dead drop: o sistema comprometido e o operador trocam dados por meio de um mesmo contêiner de armazenamento. Esse desenho mistura tráfego malicioso a um serviço amplamente usado por empresas legítimas, elevando a importância de telemetria contextual, correlação com processo de origem e análise de padrões de acesso, em vez de bloqueio genérico do provedor.
A superfície principal está nos usuários que recebem anexos ZIP por e-mail e têm permissão para extrair e executar atalhos, scripts ou binários em estáções Windows. Ambientes com controles frágeis sobre anexos compactados, execução de arquivos em diretórios temporários, scripts PowerShell iniciados por artefatos de e-mail e carregamento de DLL a partir de diretórios controlados pelo usuário ficam mais expostos. O risco aumenta quando o endpoint permite que um executável recém-extraído carregue bibliotecas locais sem validação efetiva de assinatura, reputação e caminho.
Do ponto de vista setorial, a campanha tem foco em governo, pesquisa, academia, tecnologia e finanças. Essas áreas concentram comunicações sensíveis, documentação estratégica, credenciais com acesso a sistemas internos e relacionamentos externos úteis para novas etapas de espionagem. A menção a autoridades e cidadãos em dois países também sugere que a triagem defensiva não deve se limitar a perímetros institucionais: contas pessoais usadas em contexto profissional, dispositivos fora de domínio e caixas de e-mail menos monitoradas podem participar do mesmo fluxo de ataque.
- Estáções Windows que extraem anexos ZIP recebidos por e-mail e permitem execução de LNKs ou binários locais.
- Controles de e-mail e endpoint que não correlacionam arquivo compactado, script PowerShell, execução de binário e carregamento de DLL.
- Organizações governamentais, acadêmicas, de pesquisa, tecnologia e serviços financeiros na República Tcheca e em Taiwan.
- Ambientes que usam Azure Blob Storage legitimamente e dependem apenas de reputação de domínio para decidir tráfego permitido.
A investigação deve começar pela cadeia de origem: mensagens de spear phishing com ZIP, extração local, abertura de LNK com aparência de PDF e criação ou execução de RuntimeBroker_update.exe. Em endpoint, sinais importantes incluem PowerShell iniciado a partir de artefatos extraídos de anexo, execução de binários em diretórios temporários ou de usuário, arquivos DAT usados como contêiner intermediário e carregamento de UnityPlayer.dll por um processo que não pertence a uma instalação esperada de aplicação legítima.
A detecção de DLL side-loading exige observar caminho, assinatura, linhagem de processo e proximidade temporal com a extração do ZIP. Um evento isolado de DLL carregada pode ser ambíguo, mas a sequência arquivo compactado, LNK, script, executável recém-criado e DLL no mesmo diretório reduz falsos positivos. Em EDR, a busca por execução de componentes Rust desconhecidos, criação de processos com nomes que imitam componentes do Windows e atividades de arquivo logo antes de conexões para serviços de armazenamento em nuvem pode revelar pontos de pivô.
Na rede, o uso de Azure Blob Storage deve ser analisado pelo contexto do processo e pelo perfil de uso. O serviço é legítimo e comum, portanto a defesa deve procurar acessos incomuns originados de processos recém-executados, hosts de usuário sem histórico de uso do serviço, padrões de leitura e escrita repetidos para contêineres não associados a aplicações corporativas e volume de transferência incompatível com a função da máquina. O AZUREVEIL também suporta upload e download de arquivos, execução de comandos, enumeração e encerramento de processos, encaminhamento de portas, controle de proxy SOCKS, gestão de C2 e execução em memória de BOFs; cada uma dessas capacidades deixa rastros distintos em logs de endpoint, rede e identidade.
- E-mails com anexos ZIP seguidos por extração e execução de LNK disfarçado de PDF.
- PowerShell iniciado por artefato de anexo e criação de
RuntimeBroker_update.exea partir de arquivo DAT. - Carregamento de
UnityPlayer.dllem diretório não esperado e próximo à execução de binário recém-extraído. - Acesso a Azure Blob Storage por processo sem histórico corporativo legítimo ou sem relação com aplicações autorizadas.
- Eventos de execução de comandos, enumeração de processos, operações intensivas em arquivos, proxy SOCKS ou encaminhamento de portas no endpoint.
A Dragon Weave aparece em um período de alta atividade atribuída a grupos alinhados à China. No mesmo conjunto de observações, uma tentativa de intrusão contra a filial indiana de uma fabricante global buscou entregar TencShell, um implante em Go derivado do framework aberto rshell. Nesse caso, o vetor de acesso inicial não foi identificado, mas a avaliação de alinhamento com atores chineses considerou uso histórico de rshell, imitação de APIs com tema Tencent e padrões de infraestrutura. Se bem-sucedido, o implante poderia oferecer execução remota de comandos, execução em memória, proxy, pivoting, perfilamento de sistema e caminho para ferramentas adicionais.
Outras atividades no mesmo panorama incluem o cluster SteppeDriver, descoberto em 2024 e observado contra entidades na França, Mongólia e América do Sul, com uso de ferramentas como ShadowPad, COOLCLIENT, CurlyDoor, RudeGull e MKTDownloader. Também foi descrito o kit PhiliKit, ligado a UNC5221, como backdoor passivo para execução de comandos shell e scripts Python e Perl, possivelmente associado ao conjunto SPAWN usado anteriormente pelo grupo. Esses elementos não provam relação direta com a Dragon Weave, mas ajudam a contextualizar a diversidade de ferramentas, linguagens e técnicas mantidas por operações alinhadas ao mesmo ecossistema de ameaça.
Um terceiro grupo citado, NegativeGlimmer, teria sobreposição com TGR-STA-1030, documentado em atividade contra dezenas de organizações governamentais e de infraestrutura crítica em vários países. Em dezembro de 2025, esse ator foi observado mirando uma organização governamental no Panamá por meio de spear phishing e DLL side-loading para entregar um downloader que implantava AdaptixC2 enquanto exibia documento isca à vítima. Em janeiro de 2026, iterações posteriores trocaram AdaptixC2 por Cobalt Strike, com infecções também reportadas no Camboja e na Coreia do Sul. Esse histórico reforça que o uso de frameworks de C2 públicos ou disponíveis comercialmente deve ser tratado como parte de operações reais de espionagem, não apenas como artefato de teste.
A resposta deve combinar controles preventivos sobre e-mail e endpoint com investigação retroativa. No e-mail, anexos ZIP vindos de remetentes externos devem passar por inspeção de conteúdo, detonação controlada e bloqueio ou quarentena quando contiverem LNKs, executáveis, scripts, arquivos DAT suspeitos ou combinações incomuns desses artefatos. Em estáções Windows, políticas de restrição de execução devem impedir que usuários iniciem binários e atalhos extraídos em diretórios temporários, downloads ou locais graváveis pelo usuário quando não houver necessidade operacional clara.
Para endpoint, a prioridade é detectar e interromper a sequência completa, não apenas um hash ou nome de arquivo. Bloqueios baseados em linhagem de processo, assinatura, reputação, caminho e carregamento de DLL são mais resistentes a pequenas mudanças de nomenclatura. O controle de PowerShell deve registrar argumentos, origem do processo e criação de arquivos, mas a publicação defensiva não depende de comandos específicos: o ponto de atenção é a extração de um executável a partir de um contêiner intermediário e sua execução logo após interação com anexo.
Como o canal de comando e controle usa Azure Blob Storage, a mitigação não deve assumir que todo tráfego para o serviço é malicioso. O caminho mais seguro é criar inventário de aplicações autorizadas que usam o serviço, aplicar inspeção e registro por identidade, processo e host, e alertar para novos padrões de acesso a contêineres externos. Quando houver suspeita de comprometimento, a contenção deve isolar o host, preservar artefatos do ZIP e do diretório de execução, coletar memória quando viável, revisar credenciais usadas na máquina e procurar sinais semelhantes em outros usuários que receberam a mesma campanha.
- Bloquear ou quarentenar anexos ZIP externos que contenham LNK, executáveis, scripts ou arquivos DAT sem justificativa de negócio.
- Aplicar restrições de execução para impedir binários e atalhos recém-extraídos em diretórios graváveis pelo usuário.
- Monitorar DLL side-loading com foco em caminho, assinatura, processo pai e proximidade com extração de anexos.
- Criar linha de base para uso legítimo de Azure Blob Storage e alertar acessos novos ou incompatíveis com a função do host.
- Isolar endpoints suspeitos, preservar artefatos, revisar credenciais expostas e buscar a mesma cadeia em outros destinatários.
0 Comentários