Representação de infraestrutura governamental digital comprometida por malware na campanha PhantomEnigma

Neste artigo

O que é a campanha PhantomEnigma

Em julho de 2026, a equipe de pesquisa da ANY.RUN publicou uma investigação detalhando o PhantomEnigma: uma operação de crimeware focada no Brasil que combina infraestrutura governamental sequestrada, malware modular e servidores de comando e controle (C2) rotacionados com frequência. Não se trata de um malware isolado, e sim de uma operação coordenada que usa múltiplas frentes de ataque compartilhando a mesma infraestrutura comprometida.

O achado central é grave pela combinação de dois fatores que raramente aparecem juntos: mais de 20 sites do governo brasileiro (domínios .gov.br) foram usados como canal de distribuição de malware, e caixas de e-mail de órgãos públicos genuinamente comprometidas foram usadas para enviar phishing que passa nos três principais controles de autenticação de e-mail (SPF, DKIM e DMARC). A ANY.RUN documentou a operação a partir de 231 análises em sandbox, cobrindo uma janela de observação de janeiro a julho de 2026, com uma nova detonação ao vivo em 12 de julho de 2026 confirmando uma geração de backdoor até então não documentada.

Como 20+ sites .gov.br foram sequestrados

Os pesquisadores identificaram pelo menos 20 portais municipais e de segurança pública brasileiros hospedando componentes da cadeia de infecção, entre eles subdomínios ligados a prefeituras e secretarias estaduais de segurança pública. Esses hosts .gov.br não eram o alvo final do ataque: funcionavam como pontos de redirecionamento e hospedagem intermediária, emprestando a reputação e a confiança institucional do domínio governamental para que a cadeia de infecção passasse por filtros de segurança de e-mail e de navegação que normalmente bloqueariam domínios desconhecidos ou recém-registrados.

A cadeia de ataque documentada segue um padrão consistente:

  1. Isca inicial: e-mails temáticos de "Ofício Polícia Civil" ou "Procuração Digital", simulando comunicação oficial de órgãos de segurança pública ou cartórios;
  2. PDF com QR code: um documento no padrão DOC_<CNPJ>.pdf contendo um QR code que direciona a vítima para uma página de "Verificação de Acesso" fraudulenta;
  3. Engenharia social estilo ClickFix: a página induz a vítima a copiar e executar manualmente um comando PowerShell, contornando boa parte dos controles automatizados de download;
  4. Instalador Inno Setup: o comando baixa um instalador (ex.: Procuracao_Digital.exe) que entrega o payload final.

O e-mail que passou por SPF, DKIM e DMARC

O detalhe mais preocupante da pesquisa não é técnico, é operacional: pelo menos um dos e-mails de phishing analisados originou-se de uma caixa postal genuinamente comprometida de um departamento de polícia brasileiro. Como o e-mail saiu de um servidor legítimo, com as chaves de assinatura corretas, ele passou integralmente pelas verificações de SPF, DKIM e DMARC — os três controles que a maioria das organizações usa hoje para decidir se um e-mail é confiável.

Isso quebra um pressuposto comum em muitos playbooks de segurança de e-mail: a ideia de que "passou na autenticação" equivale a "é legítimo". SPF, DKIM e DMARC provam que a mensagem veio do servidor autorizado a enviar em nome daquele domínio — não provam que o remetente não foi comprometido. Quando o comprometimento acontece na origem (a própria caixa postal do órgão), toda a cadeia de autenticação de e-mail valida um ataque como se fosse comunicação institucional legítima.

Da extensão bancária ao backdoor modular Node.js

A ANY.RUN reconstruiu a evolução do malware ao longo de dois períodos distintos. A atividade mais antiga identificada remonta a 13 de janeiro de 2026, mas a origem da operação está em uma extensão de navegador bancária ativa durante 2025, voltada a clientes de bancos brasileiros como o Banco do Brasil.

Em 2026, a operação migrou para uma arquitetura bem mais sofisticada e modular:

  • Instalador: executável Inno Setup compilado em Delphi;
  • Empacotamento: uma versão adulterada (trojanizada) do Boostnote, um aplicativo legítimo de anotações baseado em Electron;
  • Núcleo do backdoor: um arquivo index.js ofuscado, um backdoor Node.js/Electron com reconhecimento de sistema, execução arbitrária de JavaScript via eval(), persistência por chave de registro Run e capacidade de baixar e executar payloads adicionais (stealers, loaders, RATs).

A arquitetura modular é o que torna essa campanha particularmente perigosa: o operador pode trocar o payload final sem reconstruir toda a cadeia de infecção. Isso significa que a mesma infraestrutura de distribuição — os mesmos sites .gov.br sequestrados, o mesmo instalador, o mesmo Boostnote trojanizado — pode entregar hoje um ladrão de credenciais bancárias e amanhã um RAT completo, sem que os indicadores de comprometimento (IoCs) da fase de entrega precisem mudar.

A ANY.RUN confirmou, em uma detonação ao vivo em sandbox no dia 12 de julho de 2026, a existência de uma segunda geração de beacon até então não documentada: enquanto a primeira geração faz requisições GET para endpoints como /laravel.php, a nova geração usa POST para um endpoint /nbw/ com corpo JSON contendo ID da máquina, nome do computador, usuário e tag de campanha. Apesar da rotação constante de domínios e IPs de C2 — dois terços da infraestrutura já haviam sido trocados no momento da análise —, a cadeia de build Delphi/Inno/Node.js permaneceu estável, funcionando como o indicador mais confiável para detecção.

Sinais de detecção e indicadores observados

Times de SOC e threat intelligence que queiram caçar (threat hunting) atividade relacionada ao PhantomEnigma podem se apoiar em padrões que se mantiveram estáveis mesmo com a rotação de infraestrutura de C2:

  • Cadeia de build recorrente: instalador Inno Setup compilado em Delphi entregando um aplicativo Electron adulterado (no caso documentado, o Boostnote), com um arquivo index.js ofuscado como núcleo do backdoor;
  • Persistência por chave de registro Run: processo que se instala silenciosamente e sobrevive a reinicializações sem depender de tarefas agendadas;
  • Padrão de beacon de primeira geração: requisições GET para caminhos como /laravel.php?api=api&hash=<b64>&message=<b64>;
  • Padrão de beacon de segunda geração: requisições POST para um endpoint /nbw/, com corpo JSON carregando ID da máquina, nome do computador, usuário e tag de campanha;
  • Origem de tráfego: redirecionamentos vindos de hosts .gov.br conhecidos por hospedar as etapas intermediárias da cadeia de infecção, o que reforça a importância de inspecionar tráfego de saída mesmo quando o domínio de origem parece confiável.

Nenhum desses indicadores, isoladamente, é definitivo, mas a combinação de cadeia de build estável com padrões de beacon específicos é significativamente mais difícil de mascarar do que um simples domínio ou hash de arquivo, que os operadores trocam com frequência.

Por que infraestrutura pública é um vetor tão atraente

O PhantomEnigma não é um caso isolado de "site de prefeitura mal protegido". Ele ilustra por que infraestrutura de governo e de setor público em geral é um alvo estruturalmente atraente para operações de crimeware:

  • Confiança implícita herdada do domínio: um link ou anexo hospedado em .gov.br carrega credibilidade institucional que domínios comerciais não têm, reduzindo a taxa de suspeita da vítima e, em muitos casos, também a de filtros automatizados de reputação de domínio;
  • Passa em controles de autenticação de e-mail: quando o comprometimento ocorre na caixa postal de origem, SPF/DKIM/DMARC deixam de ser uma defesa e passam a validar o ataque;
  • Superfície fragmentada e heterogênea: milhares de municípios, secretarias e autarquias operam CMSs, versões de software e políticas de patch diferentes, sem padronização central de segurança, o que amplia a probabilidade estatística de existir algum ponto fraco explorável;
  • Baixa prioridade orçamentária para segurança: muitos órgãos públicos brasileiros, sobretudo municipais, não têm equipe de segurança dedicada nem monitoramento contínuo de integridade de domínio e de mailboxes;
  • Efeito multiplicador: um único site .gov.br comprometido pode ser reutilizado como infraestrutura de distribuição para vítimas de setores completamente diferentes — no caso do PhantomEnigma, bancos e provedores de serviços de segurança gerenciada (MSSPs).

Brasil como alvo crescente de ataques

O PhantomEnigma não acontece no vácuo. Dados divulgados por observatórios de ransomware indicam que, em junho de 2026, o Brasil entrou pela primeira vez no top 10 global de países mais afetados por ransomware, na 3ª posição, com organizações brasileiras registrando em média milhares de tentativas de ataque por semana — um volume bem acima da média global no mesmo período, com o setor público liderando como o mais visado no país. O PhantomEnigma se encaixa nesse cenário mais amplo como um exemplo concreto de como o setor público brasileiro tem sido explorado tanto como alvo direto quanto como infraestrutura reaproveitada contra terceiros. A lição para times de GRC é que a superfície de risco relevante já não se limita aos ativos que a própria organização opera: domínios governamentais, fornecedores e parceiros com os quais ela troca comunicação também precisam entrar no radar de monitoramento contínuo.

Lições práticas para CISOs, GRC e bancos

Para times de segurança de instituições financeiras, MSSPs e órgãos públicos, o PhantomEnigma reforça algumas lições que já eram conhecidas em teoria, mas que este caso torna concretas:

1. Autenticação de e-mail não é prova de legitimidade. SPF/DKIM/DMARC continuam sendo controles necessários, mas equipes de GRC e SOC precisam tratar "passou na autenticação" como condição necessária, não suficiente, para confiar em uma mensagem — especialmente quando o remetente é um órgão público com o qual a organização normalmente interage (polícia, cartório, receita, tribunal).

2. Monitoramento contínuo de domínios de terceiros é parte da cadeia de suprimentos. Bancos e empresas que recebem tráfego, links ou comunicações vindas de domínios governamentais deveriam considerar esses domínios como parte de sua superfície de risco de terceiros, com monitoramento de integridade e reputação, não apenas os próprios ativos.

3. A arquitetura modular exige detecção baseada em comportamento, não só em IoC estático. Como o payload final muda, mas a cadeia de build (Delphi/Inno Setup/Node.js-Electron) e os padrões de comunicação de C2 se mantêm estáveis, times de threat intelligence devem priorizar regras de detecção comportamentais e YARA voltadas à cadeia de entrega, em vez de depender só de hashes e domínios de C2, que rotacionam rapidamente.

4. Treinamento de usuário precisa incluir cenários "legítimos comprometidos". A maioria dos treinamentos de phishing ensina a desconfiar de domínios estranhos e erros de português. O PhantomEnigma mostra um cenário onde o e-mail vem de um domínio real, de um órgão real, sem erros — o único sinal de alerta é o padrão de comportamento solicitado (QR code, execução de comando, urgência jurídica).

Checklist de mitigação

Ações concretas para reduzir exposição a campanhas como o PhantomEnigma:

  • Implementar monitoramento contínuo de domínio e DNS para detectar alterações não autorizadas em ativos próprios e sinalizar comportamento anômalo em domínios de terceiros críticos para o negócio;
  • Manter um programa de threat intelligence operacional que acompanhe ativamente campanhas voltadas ao setor público e financeiro brasileiro, incluindo IoCs de cadeias de build recorrentes;
  • Tratar SPF/DKIM/DMARC como controle complementar, nunca único, para e-mails que solicitam ação urgente (abrir PDF, escanear QR code, executar comando);
  • Revisar continuamente a superfície de sites institucionais como possível vetor de distribuição de malware, não apenas como possível alvo de desfiguração (defacement), como aborda nosso guia sobre monitoramento contínuo de sites contra phishing e fraude;
  • Investir em detecção comportamental e engenharia de detecção alinhada aos princípios de threat intelligence operacional, priorizando padrões de cadeia de infecção sobre indicadores estáticos que rotacionam;
  • Simular, em treinamentos de conscientização, cenários de phishing originados de remetentes institucionais legítimos e comprometidos, não apenas domínios falsos.

Perguntas Frequentes

O que é o PhantomEnigma?

É uma campanha de crimeware focada no Brasil, documentada pela ANY.RUN em julho de 2026, que sequestrou mais de 20 sites do governo brasileiro (.gov.br) e caixas de e-mail de órgãos públicos para distribuir um backdoor modular baseado em Node.js/Electron, visando principalmente bancos e órgãos públicos.

Como um e-mail malicioso conseguiu passar por SPF, DKIM e DMARC?

Porque o e-mail foi enviado a partir de uma caixa postal genuinamente comprometida de um departamento de polícia brasileiro. Como a mensagem saiu do servidor legítimo e autorizado daquele domínio, ela cumpriu tecnicamente todos os requisitos de SPF, DKIM e DMARC, mesmo sendo parte de um ataque de phishing.

Quais sites do governo brasileiro foram afetados pelo PhantomEnigma?

A ANY.RUN identificou mais de 20 portais municipais e de segurança pública comprometidos, usados como infraestrutura de redirecionamento e hospedagem intermediária na cadeia de distribuição do malware, e não necessariamente como alvo final do ataque.

O malware do PhantomEnigma é o mesmo desde o início da campanha?

Não. A operação evoluiu de uma extensão de navegador bancária ativa em 2025, focada em fraude bancária, para uma arquitetura modular em 2026 baseada em instalador Inno Setup, um Boostnote (aplicativo Electron) trojanizado e um backdoor Node.js capaz de trocar o payload final sem reconstruir toda a cadeia de infecção.

Quem está em risco com essa campanha?

Principalmente bancos brasileiros, provedores de serviços de segurança gerenciada (MSSPs) e órgãos do setor público, que podem sofrer comprometimento de credenciais, acesso não autorizado, fraude financeira e exposição de dados através da infraestrutura sequestrada.

Como uma empresa pode se proteger de ataques que abusam de infraestrutura governamental?

Recomenda-se monitoramento contínuo de domínio e DNS de ativos próprios e de terceiros críticos, um programa ativo de threat intelligence voltado a campanhas regionais, tratar a autenticação de e-mail como controle complementar (não único) e treinar usuários para reconhecer padrões de ataque mesmo quando o remetente parece institucionalmente legítimo.

Conclusao

O PhantomEnigma é um lembrete concreto de que a confiança institucional embutida em um domínio .gov.br ou em um e-mail que passa por SPF, DKIM e DMARC não é garantia de segurança quando a origem em si foi comprometida. Para bancos, MSSPs e órgãos públicos, a resposta não é abandonar esses controles — é combiná-los com monitoramento contínuo de domínio, threat intelligence operacional e detecção baseada em comportamento, capaz de acompanhar campanhas modulares que trocam de payload mais rápido do que trocam de infraestrutura de entrega.

Fontes e referencias tecnicas
Inteligencia Brasil

Roberto Lima

Especialista em Seguranca Ofensiva, Threat Intelligence e Detection Engineering na Inteligencia Brasil.