SharpPanda usa phishing direcionado e backdoor inédito contra governo do Sudeste Asiático

Campanha atribuída com confiança média a alta a um grupo chinês combina documentos DOCX, modelos RTF armados, loaders em memória e uma backdoor personalizada chamada internamente de VictoryDll.

Componente	Campanha SharpPanda contra entidade governamental do Sudeste Asiático, com documentos DOCX maliciosos, modelos RTF criados com variante de RoyalRoad, loader Download.dll e backdoor VictoryDll_x86.dll.
Vetor	Phishing direcionado para funcionários de uma entidade governamental; os e-mails usavam anexos DOCX que pareciam documentos oficiais e carregavam modelos remotos RTF a partir de servidores controlados pelo operador.
Impacto	Instalação condicionada de uma backdoor em memória, coleta de informações do host, comunicação com C2, persistência por tarefa agendada e possibilidade de entrega de módulos adicionais.
Prioridade	Revisar telemetria de e-mail e endpoint para documentos Office que acionem modelos remotos, uso suspeito de comando operacional omitido com DLL em %Temp%, tarefa agendada chamada Windows Update e comunicação com infraestrutura C2 defangada.
Artefatos	DLL salva como 5.t, exportações StartW e MainThread, evento de instância única 9DJ8;;L;'4299FDS12JS, endpoint Main.php?Data= e recurso interno TXT associado ao executável SurvExe.
IoCs	Backdoor C2 observado em 107.148.165[.]151; servidores de primeiro estágio foram descritos como hospedados em serviços de nuvem na Ásia, incluindo Hong Kong e Malásia.

Resumo técnico

A campanha SharpPanda foi observada em uma operação de vigilância contra uma entidade governamental no Sudeste Asiático. O fluxo começa com e-mails de phishing direcionado enviados a diferentes funcionários, em alguns casos com remetentes falsificados para simular origem em outras entidades relacionadas ao governo. Os anexos eram cópias armadas de documentos oficiais aparentemente legítimos, formatados como DOCX, e usavam a técnica de modelo remoto para buscar a próxima etapa em servidores controlados pelo operador. Essa escolha reduz o conteúdo malicioso diretamente embutido no primeiro arquivo recebido pela vítima e desloca parte da lógica de ataque para infraestrutura externa.

A atribuição foi feita a um agrupamento chinês com confiança média a alta, sem ligação conclusiva com um grupo conhecido. O conjunto de ferramentas indica evolução ao longo de pelo menos três anos: amostras antigas submetidas em 2018, chamadas MClient e ligadas internamente a um projeto SharpM, preservavam parte das capacidades depois repartidas em múltiplos componentes. Essa fragmentação sugere uma tentativa de reduzir a exposição de cada estágio, dificultar análise estática e permitir que a infraestrutura decida se uma máquina comprometida receberá apenas um loader ou uma backdoor completa.

A operação combina vulnerabilidades antigas do Microsoft Word exploradas por documentos RTF gerados com uma variante de RoyalRoad, loaders que executam código em memória, mecanismos de antianálise, comunicação cifrada simples e uma backdoor personalizada chamada internamente de VictoryDll_x86.dll. O impacto confirmado não deve ser tratado como um vazamento de dados por si só, porque o material disponível sustenta uma cadeia de acesso, persistência, inventário de máquina e controle remoto modular. O risco operacional principal é a presença de um implante capaz de receber comandos e módulos adicionais quando o operador considera a vítima interessante.

Fluxo técnico

Os documentos DOCX iniciais puxavam modelos remotos RTF a partir de URLs diferentes, mas com um padrão semelhante. As pastas de trabalho nos caminhos recebiam nomes associados a marcas, como ipad, surface e apple, aparentemente para separar vítimas ou campanhas. Os modelos RTF eram armados por uma variante de RoyalRoad, ferramenta conhecida por produzir documentos com objetos incorporados que exploram falhas antigas do Equation Editor no Microsoft Word. Embora essas vulnerabilidades já tivessem anos de exposição pública na época da campanha, elas continuavam úteis contra ambientes sem endurecimento adequado, sem bloqueio de conteúdo remoto ou com parque Office desatualizado.

Após a exploração do documento RTF, a cadeia extraía uma carga cifrada e um shellcode. A carga era descriptografada com RC4 usando uma chave fixa simples e resultava em uma DLL gravada em %Temp% com o nome 5.t. O shellcode também criava persistência por meio de uma tarefa agendada chamada Windows Update, configurada para acionar diariamente comando operacional omitido contra a função exportada StartW na DLL. Esse detalhe é relevante para defesa porque o nome da tarefa imita atualização do sistema, mas a combinação de DLL em diretório temporário, exportação incomum e execução por comando operacional omitido cria uma trilha de telemetria concreta.

A DLL 5.t tinha nome original Download.dll e funcionava como loader. Antes de avançar, ela tentava detectar ambientes de sandbox medindo o comportamento de uma chamada de espera e verificando se o tempo foi artificialmente acelerado. Em seguida, coletava informações do sistema, incluindo nome do host, nome e versão do sistema operacional, arquitetura, usuário, endereços MAC de adaptadores de rede e dados de antivírus consultados via WMI. Esses atributos eram cifrados e codificados antes do envio ao servidor, permitindo que o operador avaliasse a vítima antes de entregar uma carga mais sensível.

O loader se comunicava com um endpoint semelhante a Main.php?Data= usando um agente de usuário que imitava Microsoft Internet Explorer. Quando o operador considerava o host de interesse, a resposta continha o próximo executável cifrado. A integridade do conteúdo era validada por uma combinação de verificação de prefixo com A257, cálculo FNV-1A64 e conferência de MD5 indicado na própria mensagem. Depois disso, a DLL recebida era carregada diretamente na memória, executada a partir da exportação StartW e o resultado era reportado ao servidor.

Uma segunda camada de loader reforçava a execução em memória. Para evitar múltiplas instâncias, criava o evento 9DJ8;;L;'4299FDS12JS. A funcionalidade principal estava implementada como shellcode cifrado dentro do binário, com resolução dinâmica de APIs por hash, reduzindo importações estáticas suspeitas. A configuração desse shellcode continha IP e porta do C2, além de valores usados no protocolo. Ele enviava uma mensagem HTTP CONNECT, transmitia um identificador como admin transformado por XOR e verificava se a resposta começava com o marcador 0x11d4. Quando a resposta era válida, a backdoor era carregada em memória e acionada pela função MainThread.

A backdoor final VictoryDll_x86.dll seguia uma arquitetura própria de comunicação. Ela iniciava uma conversa com o servidor por uma mensagem identificada como 0x540; o servidor respondia com uma solicitação de informações da vítima, identificada como 0x541, e fornecia uma nova chave de 256 bytes para as comunicações posteriores. O formato subsequente combinava tamanho, identificador de tipo e dados transformados por XOR. O contexto também indica que a arquitetura poderia receber outros módulos além da backdoor analisada, mas essa possibilidade deve ser tratada como capacidade condicionada pela arquitetura, não como confirmação de módulos adicionais entregues em todos os casos.

Superfície afetada

A superfície exposta começa em usuários governamentais que recebem documentos Office por e-mail e trabalham em estáções Windows com Microsoft Word suscetível às falhas antigas exploradas por objetos do Equation Editor. A campanha não depende apenas do anexo inicial: ela exige que o documento consiga buscar um modelo remoto RTF e que o ambiente permita a execução da cadeia subsequente. Controles que bloqueiam templates remotos, desabilitam conteúdo ativo em documentos recebidos pela internet, inspecionam anexos Office e mantêm correções aplicadas reduzem materialmente a chance de progressão.

No endpoint, os elementos críticos estão no diretório temporário do usuário, na criação de tarefa agendada, na execução de comando operacional omitido e no carregamento de DLLs sem origem administrativa clara. A presença de uma DLL chamada 5.t em %Temp% não deve ser analisada isoladamente; o valor defensivo está na correlação entre criação do arquivo, exportação StartW, tarefa chamada Windows Update, processos Office no início da árvore e comunicação HTTP para infraestrutura externa.

A infraestrutura do operador incluía servidores de primeiro estágio em serviços de nuvem na Ásia, localizados em Hong Kong e Malásia, e um servidor C2 da backdoor em 107.148.165[.]151, hospedado na Zenlayer. A operação dos servidores ocorria em uma janela diária limitada: as próximas etapas eram retornadas apenas entre 01:00 e 08:00 UTC em dias úteis. Essa janela dificulta análise repetida fora do horário operacional, mas também oferece um pivô temporal para caça em proxy, firewall, EDR e registros de DNS.

• Estáções Windows com Microsoft Word expostas a documentos DOCX recebidos por e-mail e capazes de carregar modelos remotos RTF.
• Contas de funcionários governamentais ou entidades relacionadas que recebem anexos com aparência de documento oficial.
• Ambientes que permitem criação de tarefa agendada por processo derivado de documento Office ou loader em diretório temporário.
• Segmentos de rede com tráfego HTTP de saída para servidores externos em janelas recorrentes de 01:00 a 08:00 UTC em dias úteis.

Hunting e telemetria

A caça deve começar pela cadeia de e-mail e documento, não apenas pela backdoor. Em gateways e sandboxes, procure anexos DOCX que façam referência a modelos remotos RTF, especialmente quando o remetente se apresenta como entidade governamental e o conteúdo imita documentos oficiais. Em logs de proxy ou EDR, a sequência de processo WINWORD.EXE seguida por tráfego para URLs externas de template, gravação em %Temp% e criação de tarefa agendada oferece uma correlação forte. A análise deve considerar que cada documento pode baixar template de URL diferente, portanto o padrão comportamental é mais importante que uma URL única.

No endpoint, sinais úteis incluem criação de 5.t, execução de comando operacional omitido com exportação StartW, consultas WMI para informações de antivírus logo após abertura de documento e coleta de metadados do host. A consulta a dados como nome da máquina, versão do sistema, arquitetura, usuário e MACs não é maliciosa por si só, mas se torna suspeita quando parte de uma árvore originada no Microsoft Word e acompanhada por codificação ou envio HTTP para um endpoint de coleta. Defesas baseadas apenas em hash podem falhar porque a campanha usa estágios em memória e componentes refinados ao longo do tempo.

Na rede, a telemetria deve buscar requisições HTTP com agente de usuário simulando Internet Explorer, caminhos com Main.php?Data=, uso de CONNECT HTTP/1.1 para IP e porta definidos em configuração interna e contato com o C2 defangado 107.148.165[.]151. O horário de resposta do servidor também importa: se houver tentativas repetidas fora da janela operacional, elas podem não receber payload, mas ainda indicam hosts que chegaram a uma etapa de comunicação. Logs de firewall, proxy autenticado e EDR com captura de conexões por processo ajudam a separar navegação comum de tráfego gerado por loader.

A presença do recurso TXT com executável associado a SurvExe e caminhos PDB deixados pelo operador indica resquícios de desenvolvimento ou versões anteriores. Esse dado é mais útil para análise de amostras e engenharia reversa do que para detecção operacional em larga escala. Já nomes internos como MClient, SharpM, AutoStartup_DLL e VictoryDll_x86.dll devem ser usados como pivôs em repositórios de malware, histórico de EDR e telemetria de sandbox, mantendo a atribuição limitada ao agrupamento observado e evitando concluir vínculo definitivo com grupos chineses conhecidos sem sobreposição adicional.

• Documentos DOCX que carregam modelos remotos RTF após abertura no Microsoft Word.
• Criação de tarefa agendada chamada Windows Update apontando para DLL em %Temp% executada por comando operacional omitido.
• Arquivo 5.t ou DLL temporária com exportação StartW e nome original compatível com loader.
• Consultas WMI a produtos antivírus em sequência próxima à abertura de documento Office suspeito.
• Requisições para endpoint Main.php?Data= com agente de usuário similar a Microsoft Internet Explorer.
• Tráfego para 107.148.165[.]151 ou para servidores de primeiro estágio em nuvem asiática dentro da janela de 01:00 a 08:00 UTC em dias úteis.

Mitigação

A mitigação deve priorizar a interrupção do vetor inicial e a redução da execução pós-exploração. Ambientes expostos a documentos Office devem manter correções aplicadas para vulnerabilidades antigas do Equation Editor, bloquear ou controlar modelos remotos em documentos recebidos de fora da organização e executar anexos em ambiente isolado antes da entrega ao usuário. Políticas de proteção do Office, marcação de arquivos provenientes da internet e inspeção de conteúdo ativo reduzem a probabilidade de um DOCX aparentemente legítimo alcançar a etapa RTF armada.

Em endpoints, restrinja criação de tarefas agendadas por usuários e processos que não precisam dessa capacidade, monitore comando operacional omitido carregando DLLs fora de diretórios confiáveis e trate %Temp% como local de alto risco para execução de bibliotecas. Regras de EDR devem correlacionar árvore de processo, caminho de arquivo, exportação chamada, escrita em diretório temporário e comunicação externa, evitando depender de um único indicador. Quando houver suspeita, isole o host, preserve artefatos voláteis, colete registros de processo, tarefas agendadas, conexões recentes e amostras do diretório temporário para análise controlada.

Na camada de rede, bloqueie indicadores confirmados em formato defangado após validação interna, mas trate infraestrutura de nuvem como dinâmica. A defesa deve combinar bloqueio de IP com inspeção comportamental de tráfego HTTP incomum originado de processos Office ou de loaders. Como a operação entregava etapas avançadas somente em janela limitada de dias úteis, a revisão histórica deve cobrir múltiplos ciclos de trabalho e não apenas o momento da investigação. Proxies com autenticação e registros por processo, quando integrados ao EDR, aumentam a precisão da resposta.

A resposta a incidentes deve assumir que a ausência da backdoor final em disco não elimina comprometimento, pois a cadeia carrega componentes em memória. A validação deve incluir busca por persistência, revisão de tarefas agendadas, análise de memória quando disponível, verificação de conexões C2 e comparação de hosts que receberam documentos semelhantes. Caso a backdoor seja confirmada, a organização deve reconstruir a linha do tempo desde o e-mail inicial, identificar outros destinatários, revogar sessões e credenciais potencialmente expostas no host e reforçar controles de e-mail para documentos oficiais falsificados.

• Aplicar correções do Microsoft Office e reduzir exposição a objetos antigos do Equation Editor.
• Bloquear ou submeter a aprovação carregamento de modelos remotos em documentos Office recebidos externamente.
• Monitorar criação de tarefas agendadas por processos originados de Office, especialmente com nome Windows Update fora do padrão corporativo.
• Alertar para comando operacional omitido executando DLLs em %Temp% com exportações como StartW.
• Revisar tráfego HTTP de hosts afetados para endpoints com Main.php?Data= e para C2 defangado 107.148.165[.]151.
• Isolar sistemas suspeitos, preservar memória e artefatos temporários e correlacionar destinatários de e-mails semelhantes antes de liberar o ambiente.