Construtor de documentos maliciosos para Office foi usado em campanhas por e-mail com macros XLM, scripts BAT, evasão de antivírus e carga final associada ao BitRAT.
| Componente | Documentos XLS com macro XLM Macro 4.0 gerados pelo APOMacroSploit, scripts BAT intermediários e carga Windows observada como fola.exe ou ernm.exe. |
| Vetor | E-mails maliciosos com anexos XLS; a cadeia começa quando o conteúdo dinâmico do documento é habilitado e a macro XLM inicia o download de um script Windows por encurtadores e serviços de hospedagem. |
| Impacto | Execução de malware em Windows, tentativa de exclusão ou desativação do Windows Defender, bypass de UAC, persistência via VBS na pasta de inicialização e controle remoto com roubo de informações por BitRAT. |
| Prioridade | Bloquear macros XLM legadas em documentos recebidos por e-mail, auditar exclusões do Windows Defender, revisar eventos de criação de scripts BAT e investigar downloads por encurtadores e cdn.discordapp.com. |
| Artefatos | Foram observados arquivos XLS como spetsifikatsiya.xls, biotech.xls, royalmail.xls e boat.xls; a cadeia também envolveu fola.exe, ernm.exe, DelphiCrypter e BitRAT. |
| IoCs | Exemplos essenciais defangados incluem cutt[.]ly, rebrand[.]ly, cdn.discordapp[.]com, um caminho hxxp para fola[.]exe em site búlgaro aparentemente legítimo e C2 185[.]157[.]161[.]109. |
O APOMacroSploit aparece como um construtor comercial de documentos maliciosos para Microsoft Office, usado para produzir arquivos XLS com macros XLM Macro 4.0 ofuscadas. A cadeia analisada começa com mensagens de e-mail que carregam anexos alinhados ao tema da isca, como pedido de entrega, consulta comercial, notificação postal e solicitação relacionada a embarcação. Quando o usuário abre o arquivo e habilita o conteúdo dinâmico, a macro é acionada automaticamente e busca um script BAT intermediário em infraestrutura externa, frequentemente por encurtadores de URL ou por serviços usados para hospedar arquivos. O ponto central da campanha não é uma vulnerabilidade específica do Office, mas o abuso de macros legadas, engenharia social e automação de execução em Windows para entregar uma carga remota.
A operação tinha escala suficiente para indicar uso por vários clientes ou operadores do construtor. O material descreve mais de 80 organizações impactadas por mensagens maliciosas, aproximadamente 40 hackers envolvidos, cerca de 100 remetentes diferentes e ataques em mais de 30 países. Também há indícios de monetização direta do construtor: dois operadores principais, identificados por aliases, teriam vendido o produto por valores que permitiriam ao menos US$ 5.000 em receita estimada durante cerca de um mês e meio. Essa informação ajuda a explicar a padronização dos artefatos: cada comprador recebia um script BAT preparado para sua campanha, com apelidos incorporados aos nomes de arquivo e infraestrutura compartilhada para download.
A promessa operacional do APOMacroSploit era reduzir detecção por antivírus. O construtor oferecia opções para interferir no Windows Defender, incluindo uma função de desativação e outra para adicionar o caminho do malware à lista de exclusões. A cadeia também incluía bypass de UAC e técnicas simples de evasão estática. Em várias amostras, a carga final observada era associada ao BitRAT, um trojan de acesso remoto capaz de controlar a máquina da vítima e coletar informações. O uso de um crypter Delphi adicionava camadas de empacotamento e anti-análise, mas os comportamentos no host continuavam visíveis em telemetria de endpoint, logs de PowerShell, criação de arquivos, alteração de política de defesa e persistência na inicialização.
O fluxo começa no e-mail. As mensagens usavam assuntos distintos para aumentar a taxa de abertura, incluindo tema de entrega em búlgaro, consulta de biotecnologia, notificação do Royal Mail e consulta de barco. Os anexos seguiam a mesma lógica e apareciam com nomes como spetsifikatsiya.xls, biotech.xls, royalmail.xls e boat.xls. O documento continha uma macro XLM ofuscada, tecnologia antiga do Excel que ainda pode ser explorada em ambientes onde macros legadas não estão bloqueadas. Após a habilitação do conteúdo, a macro iniciava o download de um script BAT por meio de cutt[.]ly; em outros casos, rebrand[.]ly redirecionava para arquivos em cdn.discordapp[.]com. O uso de encurtadores reduz a visibilidade imediata do destino real e atrapalha filtros que dependem apenas da URL apresentada ao usuário.
O script BAT fazia a etapa de preparação no host. Ele verificava a versão do Windows antes de buscar fola.exe, aplicava alteração de atributos para esconder o próprio script, manipulava exclusões do Windows Defender e tentava contornar o UAC antes de executar a carga. O texto bruto também descreve reordenação de instruções PowerShell com atraso artificial, interpretada como tentativa de evasão estática. Para publicação defensiva, comandos e payloads foram omitidos; o dado operacional relevante é que a cadeia usa script local para ajustar o ambiente de segurança antes da execução do binário final. Em logs, isso tende a aparecer como macro criando processo filho, download de arquivo por utilitários do Windows, alterações em preferências do Defender e execução de binário em diretório de usuário.
Em um dos casos detalhados, o script buscava fola.exe em um site búlgaro legítimo de equipamentos médicos aparentemente comprometido para hospedar malware. O binário era protegido por DelphiCrypter e incluía técnicas de anti-análise. Entre elas estavam uma chamada a RtlAddVectorizedExceptionHandler seguida de falha intencional por divisão por zero para prejudicar depuradores, chamadas a QueryInformationProcess com argumentos associados à detecção de debugging e busca por palavras como sample, malware ou sandbox no caminho de execução. Se esses termos fossem encontrados, a execução era interrompida. Esse conjunto mostra uma cadeia voltada a ambientes Windows comuns e a laboratórios de análise, não apenas a execução direta sem defesa.
A persistência aparecia por injeção de shellcode em notepad.exe, que depositava um arquivo VBS na pasta de inicialização. A amostra ernm.exe era estaticamente idêntica a fola.exe; durante a execução, ela comparava seu caminho com %appdata%/Roaming/rtgb/ernm.exe e, quando essa condição era satisfeita, desempacotava o BitRAT. O hash MD5 informado para essa carga é B6AD351A3EA35CAE710E124021A77CA8. A comunicação de comando e controle citada usa o IP defangado 185[.]157[.]161[.]109, que teria resolvido para subdomínio de um site búlgaro legítimo de videomonitoramento. Para defesa, esse dado deve ser tratado como indicador histórico e correlacionado com padrões de resolução DNS, conexão de saída e criação de persistência.
A superfície principal é composta por estáções Windows que recebem documentos do Office por e-mail e ainda permitem execução de macros XLM. Ambientes que dependem de macros para processos administrativos, logística, compras ou atendimento ficam particularmente expostos, porque as iscas usavam temas comerciais plausíveis. A cadeia não depende de exploração remota sem interação; ela exige que o documento seja aberto e que o conteúdo dinâmico seja habilitado. Mesmo assim, em redes corporativas, essa condição é comum quando usuários foram treinados ao longo de anos a aceitar documentos com macros para visualizar pedidos, faturas, formulários ou relatórios.
A segunda superfície é a configuração de proteção de endpoint. O construtor anunciava opções voltadas ao Windows Defender, incluindo exclusão de caminho e desativação antes da execução da carga. Portanto, qualquer ambiente em que usuários ou processos possam alterar preferências do Defender sem controle centralizado fica mais vulnerável. A cadeia também tenta bypass de UAC, o que aumenta a importância de revisar privilégios locais, controle de aplicativos, bloqueio de script e proteção contra criação de processos filho por Office. A existência de artefatos por comprador, com nomes de arquivos personalizados, indica que bloqueios baseados apenas em nome fixo tendem a ser frágeis.
A terceira superfície envolve serviços legítimos usados como intermediários. cutt[.]ly, rebrand[.]ly, cdn.discordapp[.]com e sites aparentemente legítimos comprometidos aparecem no caminho de entrega. Isso reduz a eficácia de listas estáticas que bloqueiam apenas domínios recém-criados ou reputação baixa. A defesa deve diferenciar uso corporativo legítimo de hospedagem e encurtadores de fluxos anômalos iniciados por Office, scripts BAT ou PowerShell. O contexto também sugere uso de múltiplos remetentes, o que torna controles de e-mail baseados apenas em um endereço de origem insuficientes.
- Estáções Windows com Excel capaz de abrir XLS e executar macros XLM Macro 4.0 após habilitação de conteúdo.
- Usuários que recebem anexos comerciais por e-mail e têm permissão para executar macros ou scripts locais.
- Ambientes onde exclusões do Windows Defender podem ser adicionadas por processos de usuário ou sem aprovação central.
- Redes que permitem saída direta para encurtadores, CDN pública e sites externos a partir de processos iniciados pelo Office.
A investigação deve começar pela cadeia Office para script. Procure eventos em que excel.exe ou outro processo do Office cria processos de script, shells do Windows ou clientes de download. A macro XLM é acionada dentro do documento, então a telemetria mais útil está na relação de processo pai e filho, no momento de abertura do anexo e na conexão de rede subsequente. Logs de gateway de e-mail podem ser correlacionados com anexos XLS que chegaram com assuntos comerciais e nomes próximos aos temas descritos. Como a campanha usava remetentes variados, a correlação por assunto, nome de arquivo, tipo de anexo e comportamento pós-abertura tende a ser mais robusta do que a busca por um único remetente.
No endpoint, sinais relevantes incluem criação de arquivos BAT em diretórios de usuário, mudança de atributos para ocultação, execução de PowerShell com atrasos artificiais, alteração de exclusões do Windows Defender e tentativas de desativar proteção. Também é importante observar criação de fola.exe ou ernm.exe, execução a partir de %appdata%/Roaming/rtgb/, presença de VBS na pasta de inicialização e injeção envolvendo notepad.exe. O comportamento de desempacotar uma carga RAT quando o caminho esperado é atingido é um bom ponto de detecção por sequência de eventos: arquivo depositado, execução em diretório de usuário, criação de persistência, conexão externa e possível atividade de controle remoto.
Na rede, procure acessos a encurtadores logo após abertura de documentos Office e downloads de scripts ou binários de domínios externos. Exemplos defangados úteis para retro-hunting incluem cutt[.]ly, rebrand[.]ly, cdn.discordapp[.]com e o IP 185[.]157[.]161[.]109. Esses indicadores não devem ser tratados como lista completa; a campanha usou servidores diferentes e até sites legítimos possivelmente comprometidos. A detecção mais resistente combina processo de origem, tipo de conteúdo baixado, redirecionamento, escrita em disco e alteração de defesa local.
excel.execriando processos de shell, PowerShell, script BAT ou download imediatamente após abertura de anexo XLS.- Alterações novas em exclusões, preferências ou estado do Windows Defender sem solicitação administrativa esperada.
- Arquivos
fola.exe,ernm.exeou VBS de inicialização em diretórios de perfil do usuário. - Conexões para encurtadores ou CDN pública iniciadas por processos descendentes do Office.
- Presença do MD5
B6AD351A3EA35CAE710E124021A77CA8em inventário de malware histórico ou EDR.
A mitigação mais importante é reduzir a possibilidade de execução de macros XLM em documentos recebidos externamente. Organizações que ainda dependem de macros devem separar documentos confiáveis de anexos externos, aplicar políticas por zona de origem e registrar exceções de negócio com validade curta. Bloqueios de macros vindas da internet, abertura protegida e regras de redução de superfície de ataque para impedir que Office crie processos filhos diminuem diretamente a viabilidade da cadeia. A campanha depende da transição de um documento para script e depois para binário; quebrar qualquer uma dessas etapas limita o impacto.
A configuração do Windows Defender deve ser gerenciada centralmente. Exclusões precisam ser auditáveis, justificadas e bloqueadas para alteração por usuários comuns. Eventos de desativação de proteção, inclusão de diretórios de usuário em listas de exclusão e mudanças de política devem gerar alerta. Em paralelo, controles de aplicação podem impedir execução de binários em diretórios temporários, perfil de usuário e caminhos como %appdata%. Para persistência, monitore a pasta de inicialização, scripts VBS recém-criados e processos que tentam injetar código em aplicações comuns como notepad.exe.
Na resposta a incidentes, trate qualquer host que tenha executado a cadeia como potencialmente controlado remotamente. A contenção deve isolar a máquina, preservar telemetria, coletar árvore de processos, arquivos baixados, chaves de persistência e histórico de conexões. Em seguida, revogue sessões e credenciais usadas no endpoint, porque a carga final descrita tem capacidade de roubo de informações. Regras de bloqueio devem incluir indicadores históricos, mas a erradicação não pode depender só deles: verifique alterações do Defender, diretórios de usuário, tarefas de inicialização, anexos originais e mensagens semelhantes em caixas postais de outros usuários.
- Bloquear ou restringir macros XLM Macro 4.0 em arquivos recebidos por e-mail, especialmente XLS legado.
- Aplicar regras que impeçam processos do Office de iniciar shells, PowerShell, scripts BAT e downloads de binários.
- Auditar e proteger exclusões do Windows Defender, com alerta para mudanças feitas fora do canal administrativo.
- Restringir execução em diretórios de usuário e monitorar
%appdata%/Roaming/rtgb/quando houver suspeita relacionada à campanha. - Correlacionar gateway de e-mail, EDR, DNS e proxy para encontrar outros anexos, redirecionamentos e hosts que acessaram a mesma infraestrutura.
0 Comentários