Hack Alerta

Campanha de phishing com faturas distribui XWorm via .vbs e fileless

Campanha recente usa anexos .vbs em falsos avisos de pagamento para instalar Backdoor.XWorm. O fluxo envolve um .vbs de 429 linhas que grava IrisBud.bat e aoc.bat, usa PowerShell para descriptografar payloads (AES) e carrega executáveis em memória; mutex 5wyy00gGpG6LF3m6 confirma a família XWorm.

Ataques por e‑mail com anexos .vbs vêm sendo usados para entregar o RAT XWorm, que rouba credenciais e executa payloads diretamente em memória.

Descoberta e panorama

Pesquisadores da Malwarebytes identificaram uma campanha que usa falsos avisos de pagamento e anexos em Visual Basic Script (.vbs) para instalar o backdoor classificado como Backdoor.XWorm. O anexo inicial contém 429 linhas de código ofuscado que gravam e executam uma cadeia de artefatos em múltiplas etapas, permitindo roubo de credenciais e controle remoto silencioso das máquinas infectadas.

Vetor e fluxo de execução

O ataque começa com um e‑mail que parece uma notificação de fatura; ao abrir o anexo .vbs, o script grava um arquivo batch chamado IrisBud.bat na pasta temporária do Windows e usa WMI para executá‑lo de forma invisível. Em seguida, o batch se copia para o perfil do usuário como aoc.bat para persistência.

O estágio intermediário inclui técnicas deliberadas de padding — variáveis repetidas que dificultam análise — e duas seções encaixadas no próprio batch que contêm payloads cifrados. Um script PowerShell lê esses blocos do aoc.bat, descriptografa com AES (com chave embutida no código analisado) e descomprime os dados via GZip. O resultado são dois executáveis que são carregados diretamente na memória, evitando gravação em disco (fileless execution).

Em análise de sandbox, o malware apresentou o mutex 5wyy00gGpG6LF3m6, associado à família XWorm, o que permitiu a classificação como Backdoor.XWorm.

Capacidades e riscos

  • Roubo de credenciais e arquivos sensíveis;
  • Keylogging e espionagem de usuários;
  • Capacidade de instalar ameaças adicionais, incluindo ransomware;
  • Uso de modelo malware‑as‑a‑service, facilitando a expansão da campanha por grupos menos técnicos.

Mitigações e recomendações técnicas

As fontes descrevem medidas práticas a partir da cadeia observada: bloquear ou bloquear a execução de anexos .vbs em gateways e endpoints, aplicar regras de DLP para anexos inesperados, inspecionar e desarmar anexos, e monitorar comportamentos de processo que realizem leitura de arquivos batch e execução de PowerShell com parâmetros incomuns. Ferramentas EDR devem ser configuradas para detectar carregamento de binários em memória e o mutex identificado pode ser incluído em listas de IOC para detecção.

Limites das informações

As análises públicas relatam o fluxo técnico e indicadores como nomes de arquivos e mutex, mas não detalham números de vítimas ou alvos específicos. As fontes também não informam métricas de alcance (nº de organizações afetadas) nem atribuição do ator por trás da operação.

Implicações operacionais

A combinação de engenharia social simples (faturas) com execução fileless e ofuscação torna a campanha eficaz contra ambientes corporativos que dependem apenas de assinaturas. Organizações devem revisar controles de e‑mail, restringir execução de scripts por usuários, reforçar políticas de execução de PowerShell (Constrained Language/Applocker) e tratar .vbs como artefato de alto risco.

Fontes e observações

Detalhes técnicos citados correspondem à investigação da Malwarebytes reportada pela Cyber Security News; as matérias descrevem o uso de .vbs, IrisBud.bat, aoc.bat, AES com chave embutida, GZip e o mutex 5wyy00gGpG6LF3m6.


Baseado em publicação original de Malwarebytes
Publicado pela Redação Hack Alerta com base em fontes externas citadas e monitoramento editorial do Hack Alerta. Para decisões técnicas, operacionais ou jurídicas, confirme sempre os detalhes na fonte original.