Breeze Comet: grupo brasileiro desvia dinheiro via Pix e STR

O Google Threat Intelligence Group (GTIG) e a Mandiant publicaram em 1º de setembro um relatório sobre o Breeze Comet, grupo criminoso que opera a partir do Brasil e se especializou em manipular sistemas de pagamento e software bancário para fazer transferências fraudulentas. Não é fraude contra o correntista: o grupo invade a empresa que tem permissão para movimentar dinheiro e manda as ordens de pagamento em nome dela. Numa das intrusões investigadas, depois de chegar às aplicações financeiras centrais da vítima, o Breeze Comet disparou duas ondas de centenas de transações fraudulentas em 24 a 48 horas.

O grupo era rastreado antes como UNC5669, e a atividade se sobrepõe à que outras empresas de segurança chamam de Plump Spider e SHADOW-AETHER-064. Desde 2024 a Mandiant investiga intrusões atribuídas a ele em empresas brasileiras de serviços financeiros, varejo e comércio eletrônico.

Resumo para quem decide

  • Quem está na mira: toda organização com permissão para transacionar por software bancário, APIs e sistemas como Pix, STR e Boleto. O relatório cita bancos, processadoras de pagamento, varejistas, corretoras, fintechs e fornecedores de software bancário.
  • O que o grupo quer: dinheiro. Houve pelo menos um roubo concluído de dezenas de milhares de dólares em ativos, segundo o GTIG.
  • Como entra: pulverização de senhas, ligação se passando pelo suporte de TI para o funcionário instalar AnyDesk, arquivos maliciosos hospedados em sites de prefeituras brasileiras invadidas e até equipamento físico plugado na rede de lojas.
  • Quanto tempo você tem: pouco. Entre o acesso aos sistemas financeiros e as transferências passaram de 24 a 48 horas no caso descrito. Detecção que depende de revisão manual no dia seguinte chega tarde.
  • O que pedir ao time agora: bloquear ferramentas de acesso remoto não aprovadas, exigir MFA resistente a phishing em VPN e SaaS, ativar controle de acesso nas portas de rede das filiais e conferir os indicadores publicados pelo GTIG.

Como o Breeze Comet chega até o dinheiro

O ponto que diferencia o Breeze Comet dos trojans bancários brasileiros conhecidos é o alvo. Em vez de roubar a senha do cliente final, o grupo mira a infraestrutura que liquida as transferências. Para conseguir executar as ordens fraudulentas, segundo o relatório, ele precisa reunir quatro coisas:

  1. Acesso à Rede do Sistema Financeiro Nacional (RSFN) por meio de uma entidade que tenha essa conexão.
  2. As credenciais mTLS que autenticam as mensagens enviadas ao Pix, ao STR (Sistema de Transferência de Reservas) ou a qualquer outro receptor de transações, para que as ordens sejam executadas em nome de uma organização com saldo disponível.
  3. Acesso persistente a várias contas no Active Directory ou no ambiente de nuvem da vítima.
  4. Conhecimento dos procedimentos de transferência da empresa, dos controles de rede, das integrações com fintechs e dos sistemas antifraude.

Na prática, isso exige presença prolongada e silenciosa no ambiente antes do roubo, estudando como o dinheiro sai. No caso analisado pela Mandiant, o grupo usou o malware COBALTSPIN e contas privilegiadas comprometidas para chegar às aplicações financeiras centrais. As transferências em si levaram um ou dois dias, mas reunir os quatro requisitos acima leva mais tempo. É nessa fase de preparação que a empresa tem chance real de detectar a intrusão.

As portas de entrada: senha, telefone, prefeitura e cabo de rede

O relatório descreve quatro caminhos de acesso inicial, e cada um cai numa área diferente da empresa.

Pulverização de senhas e ligação do “suporte de TI”. Nas primeiras intrusões, o grupo testava senhas comuns contra muitas contas ao mesmo tempo e ligava para funcionários fingindo ser o suporte técnico, com o objetivo de convencê-los a instalar uma ferramenta de acesso remoto como o AnyDesk. Uma vez instalada, a ferramenta é legítima, assinada e muitas vezes já liberada pelo antivírus. Já tratamos desse padrão em abuso de ferramentas de acesso remoto legítimas por cibercriminosos.

Sites de prefeituras invadidos. A partir de meados de 2025, o GTIG observou o grupo usando sites de pequenos órgãos públicos brasileiros para hospedar ferramentas de acesso remoto, ladrões de credenciais disfarçados de comprovante ou documento fiscal e o backdoor XWORM, vendido em fóruns criminosos. Os nomes dos arquivos listados no relatório mostram a isca: ComprovantePDF.exe, ComprovanteBBpix.exe, COAF-POLICIAFEDERAL.exe. Os mesmos sites serviam de apoio à engenharia social e como servidores de comando e controle. É isso que torna o esquema eficaz: um endereço terminado em .gov.br passa por filtros de reputação de domínio que bloqueariam um domínio recém-registrado. O relatório lista esses endereços: órgãos estaduais, prefeituras e câmaras municipais de Goiás, Maranhão, Minas Gerais, São Paulo e Santa Catarina. O mesmo esquema foi repetido com domínios municipais na Nigéria, no Paraguai, em Gana e na Venezuela, o que o GTIG lê como sinal de expansão para a América Latina e a África.

Equipamento plugado na rede da loja. Em 2025, o grupo passou a conectar dispositivos físicos diretamente na rede de lojas do varejo para ganhar um ponto de apoio no ambiente. Para uma rede com dezenas ou centenas de filiais, cada tomada de rede exposta ao público vira porta de entrada.

Servidores JBoss vulneráveis. A Trend Micro, citada no relatório, documentou a exploração de falhas em servidores JBoss AS como acesso inicial.

Três dos quatro caminhos dependem de pessoas ou de processos físicos, não de uma vulnerabilidade com correção disponível. Não existe patch para o funcionário que atende a ligação.

O que o grupo instala depois que entra

Uma vez dentro, o Breeze Comet monta uma estrutura redundante: se uma ferramenta cai, outra mantém o acesso. O GTIG descreve seis famílias próprias:

  • REALBREEZE: utilitário de força bruta contra LDAP, usado para comprometer o Active Directory.
  • COBALTSPIN: malware de roteamento para atravessar redes financeiras segmentadas e contornar firewalls internos. Foi o usado para chegar às aplicações financeiras no roubo descrito.
  • LIGHTPAINT: backdoor em Java que instala uma VPN legítima, como a SoftEther, e a configura para persistir.
  • MILDFROST: backdoor passivo em Java escondido dentro do processo da JVM, que se comunica por túneis DNS lentos e discretos.
  • KICKPLATE: entrega cargas auxiliares e garante a persistência no host.
  • BOATBEAM: backdoor em Go que sobe um falso servidor HTTPS do IIS na porta 443.

Em 2025 o grupo também implantou pods maliciosos no Kubernetes para manter acesso e roubar segredos da nuvem, que eram enviados para sites públicos de bloco de notas como o dontpad[.]com.

Inteligência artificial no desenvolvimento. A Mandiant encontrou indícios de que o grupo usa modelos de linguagem para acelerar a criação de scripts de reconhecimento de rede, validação de credenciais, implantação em massa, movimentação lateral específica para cada vítima e extração de dados. Os scripts recuperados funcionam bem e são adaptados a cada ambiente, mas têm a marca de código gerado: estruturas repetidas sem laço, comentários explicativos longos e cabeçalhos padronizados. A consequência para quem defende é que o grupo consegue adaptar ferramentas a cada vítima mais rápido do que antes. O tema da IA a serviço do atacante já apareceu aqui em vibe hacking, quando a engenharia social encontra a inteligência artificial.

O que fazer na empresa

As recomendações abaixo são as publicadas pelo GTIG, organizadas pela ordem em que cortam o ataque.

1. Fechar a porta do acesso remoto.

  • Aplicar controle de aplicações (WDAC no Windows, Gatekeeper ou MDM no macOS, fapolicyd no Linux) para impedir execução a partir de pastas graváveis pelo usuário, como %APPDATA%, ~/Downloads e /tmp.
  • Montar /tmp e /home com noexec nos servidores Linux.
  • Alertar sobre execução de ferramenta de acesso remoto portátil e sobre registro de serviço não aprovado.
  • Treinar os funcionários para desconfiar de ligação do “suporte” pedindo instalação de software, e combinar um canal de confirmação.

2. Proteger a rede física das filiais.

  • Ativar 802.1X nas portas de switch das lojas e filiais, para que um equipamento estranho não receba endereço IP nem converse com a rede interna.
  • Desligar portas sem uso, limitar endereços MAC nas portas críticas e trancar racks e tomadas expostas ao público.

3. Endurecer identidade e Active Directory.

  • Exigir MFA resistente a phishing e bloqueio por tentativas em todos os portais externos (VPN, SaaS). Isso corta a pulverização de senhas, que depende de credenciais fracas ou vazadas; veja como infostealers alimentam o vazamento de credenciais corporativas.
  • Restringir ntdsutil.exe e vssadmin.exe e alertar sobre criação ou remoção de cópias de sombra.
  • Ativar o modo de linguagem restrita do PowerShell, o registro de blocos de script (evento 4104) e o AMSI.

4. Controlar a saída de tráfego.

  • Inspecionar o tráfego web de saída com descriptografia TLS em vez de confiar na reputação do domínio. O relatório é explícito: não usar lista de permissão por .gov, porque o grupo hospeda seus arquivos justamente em sites de governo.
  • Bloquear portas e protocolos de saída desnecessários (ICMP de saída, por exemplo) e ferramentas de tunelamento como Chisel e GSocket.
  • Bloquear SMB (445) e RDP (3389) entre estações de trabalho e servidores.

5. Isolar o que movimenta dinheiro.

  • Microssegmentar por identidade as cargas de trabalho financeiras.
  • Permitir acesso administrativo a esses sistemas só por servidores de salto dedicados, com gestão de acesso privilegiado.
  • Guardar segredos, incluindo certificados e chaves de integração, num cofre central com registro de acesso, sem chave em texto puro no código.
  • No Kubernetes, aplicar RBAC de menor privilégio, controladores de admissão (OPA Gatekeeper ou Kyverno) e Pod Security Admission para barrar contêiner privilegiado, além de política de saída que impeça pods de falar com serviços públicos não autorizados.

Para o time técnico, a verificação imediata: o relatório traz os hashes SHA-256 do COBALTSPIN, REALBREEZE, MILDFROST, BOATBEAM, KICKPLATE e XWORM, os endereços usados para hospedar os arquivos maliciosos e regras YARA para quatro das famílias. Vale procurar esses indicadores nos registros de proxy, DNS e endpoint dos últimos meses. A coleção completa está no VirusTotal, para usuários cadastrados.

Perguntas frequentes

O Breeze Comet ataca clientes de banco ou as próprias instituições?
As instituições e empresas que movimentam dinheiro. O objetivo é enviar ordens de transferência pelo Pix, pelo STR ou por outro receptor de transações em nome de uma organização com saldo, usando as credenciais e o acesso dela.

Minha empresa não é banco. Estou fora do alvo?
Não necessariamente. O relatório inclui varejistas, processadoras de pagamento, corretoras, fintechs e fornecedores de software bancário. Varejo com rede de lojas também é alvo do acesso físico por equipamento plugado na rede.

Existe correção a aplicar?
Não há um patch que resolva, porque a maior parte do acesso inicial vem de engenharia social, senhas fracas e acesso físico. A exceção são servidores JBoss AS expostos, que devem ser atualizados, migrados ou tirados da internet. A defesa está nos controles listados acima.

Como saber se fomos atingidos?
Procurando os indicadores publicados pelo GTIG (hashes, domínios e regras YARA) e sinais do comportamento descrito: AnyDesk ou outra ferramenta de acesso remoto instalada fora do processo, instalação inesperada de VPN SoftEther, tráfego DNS anormal saindo de processos Java, pods desconhecidos no Kubernetes e acesso a sites de bloco de notas públicos a partir de servidores.

Por que o uso de sites .gov.br importa?
Porque filtros de reputação confiam neles. Um arquivo baixado de um site de prefeitura passa por controles que barrariam um domínio desconhecido, e o funcionário também tende a confiar. Por isso a recomendação de inspecionar o conteúdo em vez de liberar tráfego pelo domínio.

Facebook
Twitter
WhatsApp