Uma campanha de phishing com tema judicial está visando organizações colombianas e entregando o malware XWorm por meio de scripts ofuscados, PowerShell criptografado e um carregador .NET reutilizável.
O carregador recuperado é idêntico, em nível binário, a um documentado em um caso de 10 de setembro de 2026 ligado ao Reino Unido, conectando cadeias de entrega que, de outra forma, estavam empacotadas de maneiras diferentes.
A sobreposição comprova o reúso do carregador, e não uma atribuição comum. Hashes de payload diferentes, alvos de execução e infraestrutura de comando e controle (conhecida como C2) distinguem os casos.
Separadamente, três endpoints de C2 recuperados aparecem em registros públicos de sandbox do XWorm associados a outras versões, ampliando as evidências de reúso de infraestrutura.
Os e-mails colombianos partiram de organizações da Colômbia e continham mensagens em espanhol pedindo atenção imediata.
Os arquivos VBScript e JavaScript anexados tinham nomes que imitavam correspondências administrativas ou judiciais, incentivando os destinatários a executar scripts disfarçados de documentos.
A proteção do VBScript combinava identificadores gerados, variáveis de configuração enganosas, concatenação de strings criptografadas e um invólucro de execução.
Uma camada interna implementava uma decodificação Base93 personalizada, agrupando pares de símbolos em valores de 13 ou 14 bits de acordo com uma regra dependente de limite.
O conteúdo decodificado passava por substituição com chave e rotinas de manipulação de bits. Transformações personalizadas de blocos de oito e de 12 bytes usavam consultas em tabelas, mistura de palavras, operações XOR (ou exclusivo) e rotações ou deslocamentos.
A construção de 12 bytes encadeava blocos por meio de XOR com o texto cifrado anterior, lembrando o modo CBC (encadeamento de blocos) em torno de uma primitiva não padronizada. Outra camada, AES-256-CBC (Padrão de Criptografia Avançada em modo de encadeamento de blocos), ajudou a recuperar o PowerShell.
Carregador de malware XWorm
Variantes em JavaScript ocultavam o PowerShell por meio de strings codificadas, concatenação e nomes de função construídos dinamicamente.
A Arctic Wolf identificou que o descriptografador de configuração do XWorm derivava sua chave do hash MD5 (algoritmo de resumo criptográfico) da string do mutex e aplicava AES-256-ECB aos valores decodificados em Base64.
Uma camada combinava criptografia SM4-CBC e Square-CBC, com chaves recuperadas de valores ofuscados por XOR. Outra usava verificação de integridade e strings Unicode codificadas dentro de um contêiner criptográfico personalizado.
O desempacotador do PowerShell processava duas strings protegidas com chaves e vetores de inicialização separados. Sua codificação Base52 personalizada representava sete bytes com dez caracteres, em grupos completos.
Tabelas de substituição de 256 entradas com chave, o comportamento determinístico da classe System.Random do .NET e um gerador de fluxo inspirado no RC4 acabaram expondo uma DLL (biblioteca de vínculo dinâmico) .NET no formato PE32 e um executável VB.NET.
O PowerShell carregou de forma reflexiva a DLL RSG_UnityApp e invocou um método estático público com seis argumentos, incluindo o caminho do RegAsm.exe e os bytes do payload do XWorm.
O assembly se identificava como versão 1.1.0.0 e tinha a proteção Crypto Obfuscator.
O relatório de setembro de Buschbeck documentou o mesmo hash de DLL e a mesma estrutura de invocação, mas usava entrega em JavaScript, o MSBuild.exe como processo-alvo configurado e valores diferentes de payload do XWorm e de C2.
Outra amostra monitorada entrega o DCRat pelo mesmo carregador.
O padrão é semelhante ao de campanhas do XWorm documentadas separadamente, que combinam phishing, PowerShell, componentes .NET carregados na memória e executáveis legítimos da Microsoft. A Fortinet relatou uma cadeia Excel para HTA (aplicativo HTML) que culmina na execução do XWorm dentro do MSBuild.exe, demonstrando arquitetura de entrega semelhante, sem estabelecer uma conexão direta entre as campanhas.
As comunicações de rede, por outro lado, usavam AES-128-ECB, com mensagens criptografadas precedidas pelo tamanho decimal em bytes e por um separador NUL.
As mensagens descriptografadas usavam o delimitador <XWormmm>. Os beacons INFO iniciais revelavam nomes de usuário, detalhes do sistema operacional, datas de instalação, status de elevação de privilégios, disponibilidade de webcam, especificações de hardware e status do antivírus.
Os comandos suportados incluíam update, DW, FM, LN, RunShell, $Cap, plugin, savePlugin, StartDDos e operações com arquivos hosts. Os plugins podiam ser carregados como assemblies gerenciados, ampliando as funcionalidades.
Registros públicos de sandbox vinculavam os três endpoints a amostras com hashes, mutexes e valores de grupo diferentes. Essas diferenças indicam reúso entre versões configuradas separadamente, e não observações repetidas de um mesmo executável.
Em conjunto, as descobertas mostram por que a identidade do carregador, a configuração do payload e a infraestrutura devem permanecer analiticamente distintas.
IOCs (indicadores de comprometimento)
Nota: endereços IP e domínios são intencionalmente desfigurados (por exemplo, com [.]) para evitar resolução ou hiperlink acidentais. Restaure o formato original apenas em plataformas controladas de inteligência de ameaças, como MISP, VirusTotal ou seu SIEM (sistema de gerenciamento de eventos e informações de segurança).
