BREEZE COMET: uma ameaça de motivação financeira no Brasil

Introdução

Desde 2024 a Mandiant investigou uma série de comprometimentos que afetam organizações brasileiras dos setores de serviços financeiros, varejo e comércio eletrônico. O Google Threat Intelligence Group (GTIG) mapeou esse cluster como BREEZE COMET (anteriormente UNC5669), um ator de ameaças com motivação financeira especializado em manipular sistemas de pagamento e softwares bancários no Brasil para realizar transferências fraudulentas em grande quantidade. Essa atividade se sobrepõe às operações realizadas publicamente atribuídas ao Plump Spider e SHADOW-AETHER-064. Neste blog, detalhamos as táticas e as ferramentas do BREEZE COMET, além de fornecer recomendações de mitigação e detecções para auxiliar as organizações na defesa contra essa ameaça ativa e em constante desenvolvimento.

As táticas do BREEZE COMET evoluíram ao longo do tempo para explorar um seu próprio arsenal de malware, conjuntamente a sites confiáveis ​​comprometidos a fim de facilitar o seu acesso inicial, o comando e controle (C2) e a interação com softwares financeiros e APIs de pagamento. A infraestrutura operacional do BREEZE COMET também pode indicar a intenção de expandir sua infraestrutura para outros países na América latina e África. Adicionalmente, evidências apontam que o BREEZE COMET usa inteligência artificial (IA) generativa para dar suporte ao desenvolvimento de malware, aumentando a escala, velocidade e sofisticação de suas operações no futuro.

BREEZE COMET mira no setor de tecnologia financeira brasileiro

As operações do BREEZE COMET têm como alvo organizações com permissão para realizar transações por meio de softwares bancários, APIs e sistemas de pagamento, como PIX, STR e Boleto. Isso geralmente inclui bancos, processadores de pagamento, varejistas, corretoras, bem como fintechs e fornecedores de software bancário.

Para alcançar seus objetivos de realizar transferências fraudulentas, BREEZE COMET deve manter:

• Acesso a Rede Nacional do Setor Financeiro, RSFN, por meio de uma entidade com esse acesso.
• Acesso a credenciais mTLS que permitem enviar payloads com ordens transnacionais para PIX, STR (Sistema Brasileiro de Transferência de Reservas) ou qualquer API transacional para ser executado com restrições mínimas em nome de uma organização com fundos disponíveis.
• Acesso persistente a múltiplas contas no Active Directory e/ou ambientes de nuvem de organizações-alvo.
• Compreensão dos procedimentos de processamento de transferências de uma organização, controles de rede, integrações de fintech e sistemas anti-fraude.

Para atender a esses requisitos, BREEZE COMET evoluiu de forma a operar em múltiplos ambientes comprometidos simultaneamente, criando malware personalizado de comando e controle (C2) para automatizar atividades como reconhecimento, movimentação lateral, persistência e exfiltração.

Comprometimento inicial e estabelecimento de posição

BREEZE COMET utiliza diversos métodos para obter acesso inicial. Nos primeiros ambientes comprometidos analisados, a Mandiant observou esse atores de ameaças utilizando ataques de password spraying, também como chamadas de voz que se fazem passar por equipes de suporte de TI, para convencer os usuários a instalar ferramentas de monitoramento e gerenciamento remoto (RMM), como AnyDesk e SoftEther. Axur corrobora o uso de phishing por voz e sugere que o grupo também tentou recrutar funcionários de dentro das organizações visadas.

Em meados de 2025, o GTIG observou BREEZE COMET usando sites de pequenas prefeituras no Brasil que foram comprometidos para fins de staging de ferramentas RMM, “infostealers” disfarçados de documentos fiscais ou recibos legítimos (por exemplo, ComprovantePDF.exe), ou backdoors como o XWORM configurado para persistir por meio de modificações automáticas no atalho de inicialização. O XWORM é um backdoor amplamente disponível para compra em fóruns de crimes cibernéticos, com versões vazadas ou "crackeadas" também disponíveis. O grupo BREEZE COMET posteriormente utilizou esses sites governamentais comprometidos para facilitar operações de engenharia social para acesso inicial e como pontos de comando e controle (C2). O uso de infraestrutura comprometida e confiável permitiu que os atores da ameaça evitassem a detecção por filtros de reputação de domínio de rede. O GTIG também observou o BREEZE COMET replicando esse comportamento com outros domínios municipais na Nigéria, Paraguai, Gana e Venezuela, sugerindo um foco de segmentação potencialmente crescente. A análise de domínios municipais comprometidos, indicou que o BREEZE COMET reutilizou a mesma infraestrutura para hospedar e distribuir payloads XWORM em operações direcionadas a múltiplas organizações.

Em 2025, observamos pela primeira vez o BREEZE COMET conectar dispositivos de hardware não autorizados diretamente às redes das lojas de varejo para estabelecer pontos de acesso em ambientes específicos. A partir desse acesso inicial à rede, o BREEZE COMET moveu-se lateralmente para sistemas internos e, em seguida, baixou ferramentas como netcat juntamente com scripts personalizados para baixar estruturas subsequentes de pós-exploração de diretórios externos expostos. Um relatório da Trend Micro reportou que o grupo também explora vulnerabilidades em servidores JBoss AS para obter acesso inicial.

Escalar privilégios e realizar reconhecimento interno

O BREEZE COMET utiliza ferramentas de reconhecimento disponíveis publicamente, como Impacket, ADRecon e ADVipscan, bem como seus próprios malwares, frequentemente se aproveitando de ambientes com baixa observabilidade de segurança. Observou-se frequentemente que esses utilitários eram baixados de repositórios do GitHub e executados na memória via PowerShell para evasão de defesa.

O ator da ameaça implantou o utilitário personalizado de força bruta de LDAP REALBREEZE. Além das soluções tradicionais do Active Directory, o grupo visa especificamente ambientes de desenvolvimento e nuvem para escalar privilégios. Ele realiza mineração em ambientes de integração contínua e entrega contínua (CI/CD) para roubar credenciais de pipeline codificadas, chaves de API e tokens de acesso à nuvem com alto privilégio.

O BREEZE COMET utilizou scripts personalizados para pesquisar arquivos de host internos e variáveis ​​de ambiente para identificar credenciais mTLS e certificados administrativos necessários para autenticação em sistemas bancários centrais. Os termos de pesquisa observados incluíram: boleto, cnab, remessa, webhook.*pix e instant.*payment.

Movimento Lateral

O BREEZE COMET abusa dos protocolos padrões para navegar na rede, usando contas de serviço sequestradas para iniciar sessões não autorizadas em RDP e executar comandos por meio de compartilhamentos de arquivos de rede via SMB. Foi observado o uso de ferramentas de varredura de rede em sub-redes internas, especificamente para enumerar os servidores SMB.

Para navegar por redes financeiras segmentadas e contornar firewalls internos, o BREEZE COMET foi observado usando o malware de roteamento: COBALTSPIN. Escrito em Rust, o COBALTSPIN funciona como um tunelador de rede leve e evasivo, usado para se comunicar com infraestruturas de API financeiras e manter acesso persistente à rede. Ao estabelecer um proxy reverso SOCKS5 sobre uma conexão WebSocket, o COBALTSPIN roteia o tráfego de rede de forma segura entre o servidor de comando e controle (C2) e os alvos internos, permitindo a movimentação lateral diretamente através de firewalls de borda sem a necessidade de mecanismos de persistência integrados que possam desencadear a detecção.

Manter a Presença: Orquestrando o Comprometimento por meio de uma Estrutura C2 Personalizadas

Em 2024, o BREEZE COMET dependia de RMMs comerciais para manter o acesso a ambientes específicos. Em 2025, o BREEZE COMET também implantou pods maliciosos do Kubernetes para manter a persistência e roubar segredos da nuvem, exfiltrando-os para sites de bloco de notas públicos (como dontpad[.]com).

Em 2025 e 2026, a Mandiant identificou vários backdoors que o BREEZE COMET desenvolveu para estabelecer acesso redundante e expandir sua presença em ambientes específicos.

• LIGHTPAINT: Este backdoor personalizado baseado em Java foi projetado especificamente para instalar uma VPN legítima (e.g. SoftEther), e configurá-la para persistência no ambiente. Para proteger este acesso, a GTIG observou BREEZE COMET adicionando regras de entrada do Firewall do Windows Defender para permitir todo o tráfego do gerenciador de VPN implantado e, posteriormente, limpando o Plataforma/Operacional de Plugin VPN de Rede Windows registros de eventos para apagar evidências forenses da conexão.
• MILDFROST: Operando como um backdoor passivo em formato JAR Java, oculto dentro do espaço de processo da JVM, o MILDFROST utiliza classes como DnsCommandBeacon.class para túneis DNS lentos e furtivos. Também serve como um C2 de contingência; Consulta dinamicamente subdomínios delegados para receber instruções e baixar novas cópias dos executáveis ​​em C++.
• KICKPLATE:Para fornecer continuamente payloads auxiliares e impor persistência em nível de host, o BREEZE COMET usa o KICKPLATE Este backdoor personalizado baseado em Nim se faz passar pelas Ferramentas de Saúde do Windows Update. Ele executa comandos para controlar túneis SOCKS5, atualizar chaves de inicialização do registro e modificar silenciosamente serviços do Windows. O grupo complementa o KICKPLATE abusando de tarefas agendadas nativas (schtasks.exe executando como SISTEMA) e atalho malicioso (.lnk) modificações nas pastas de inicialização do usuário.
• BOATBEAM: Adicionando uma camada final à sua arquitetura redundante, o BREEZE COMET implanta o BOATBEAM, um backdoor em Golang que inicia um servidor HTTPS IIS falso na porta 443. Este artefato oculta seu tráfego de backdoor ao se disfarçar de um servidor web legítimo, ativando suas funcionalidades de C2 somente quando recebe um cookie de sessão específico.

Para garantir a sobrevivência desses mecanismos de persistência, o BREEZE COMET prejudica ativamente as defesas dos endpoints. A telemetria confirma que os atores de ameaça estão executando comandos diretos do PowerShell (Set-MpPreference -DisableRealtimeMonitoring $true) para desativar o monitoramento em tempo real do Windows Defender em hosts comprometidos, garantindo que seu pacote de malware permaneça operacional.

Além disso, a Mandiant identificou evidências de que o BREEZE COMET utilizava grandes modelos de linguagem (LLMs) para acelerar a criação de scripts personalizados para reconhecimento de rede, validação de credenciais, implantação em massa, direcionamento específico para cada vítima e extração de dados. A análise dos scripts recuperados do BREEZE COMET mostrou que as ferramentas são altamente personalizadas e funcionais, mas carecem de idiossincrasias humanas, dependendo fortemente de estruturas de código lineares, comentários explicativos verbosos e cabeçalhos de execução padronizados.

#!/bin/bash

# RODA DENTRO DO 10.0.9.9 - DIRETO NA REDE INTERNA

echo"###############################################"

echo"### PASSO 1: ENUM ALL LINUX (PORTA SSH 22) ###"

echo"###############################################"

# Scan SSH em todos os ranges conhecidos

echo"=== VERIFICANDO PORTAS SSH ==="

> /tmp/ssh_open.txt

Figura 1: Trecho do roteiro mostrando comentários detalhados

Missão Concluída: Transações Fraudulentas em Massa

Evidências forense analisadas pela Mandiant demonstram que o BREEZE COMET utilizou o COBALTSPIN e comprometeu contas privilegiadas para acessar aplicações financeiras. Dentro de 24 a 48 horas após obter esse acesso, o ator malicioso costuma realizar ondas de múltiplas transações fraudulentas.

O ator de ameaça costuma apagar os registros de eventos em todos os hosts comprometidos para ocultar evidências de movimentação lateral, escalonamento de privilégios e interações com APIs associadas a softwares financeiros e sistemas de pagamento. Além disso, os atores de ameaça apagam os diretórios criados durante a invasão para dificultar sua identificação.

Perspectivas e implicações

Desde 2024, o BREEZE COMET tem aumentado constantemente a complexidade e a eficácia de suas operações de manipulação de sistemas e softwares financeiros brasileiros, tendo executado com sucesso pelo menos um roubo de dezenas de milhões de dólares em ativos. Esta análise tem como objetivo auxiliar organizações dos setores de serviços financeiros, fintech, varejo e Governo, principalmente no Brasil, no monitoramento e defesa contra o BREEZE COMET.

Enquanto o ecossistema do cibercrime latino-americano foi historicamente caracterizado por fraudes de varejo em larga escala no lado do cliente, as campanhas do BREEZE COMET representam uma mudança notável que pode servir de modelo para futuras ameaças com motivação financeira contra organizações nesta região. Essa transição de fraudes bancárias oportunistas no varejo para intrusões diretas na infraestrutura central de comutação financeira e pagamentos instantâneos é notável não apenas pela mudança no alvo, mas também pelas capacidades do ator da ameaça.

O BREEZE COMET exemplifica como atores de ameaças estão operacionalizando IA generativa para aprimorar a velocidade, a escala e a sofisticação de suas campanhas. Ao utilizar LLMs para gerar scripts de reconhecimento personalizados, validar credenciais e automatizar fluxos de trabalho de implantação em tempo real, o ator comprime o ciclo de desenvolvimento. Essa automação também reduz o limiar operacional necessário para coordenar ataques sincronizados em múltiplos ambientes. Por fim, a orquestração do uso de ferramentas geradas por IA juntamente com arquiteturas C2 multilíngues personalizadas demonstra como os atores podem elevar suas capacidades gerais e reduzir as barreiras técnicas de entrada. A progressão para um ecossistema de múltiplas camadas — combinando backdoors personalizados em Rust, Nim e Go com scripts operacionais acelerados por IA — demonstra uma maturação mensurável na capacidade técnica do BREEZE COMET.

À medida que os atores de ameaça utilizam cada vez mais as LLMs para otimizar as operações rotineiras, os defensores devem antecipar tempos de resposta mais curtos por parte dos adversários e uma maior pressão sobre os ecossistemas financeiros interconectados.

Remediação

Controle de Aplicativos e Bloqueio de Gerenciamento Remoto (RMM) Não Aprovado

• Imponha o Controle de Aplicativos (por exemplo, WDAC do Windows, Gatekeeper/MDM do macOS ou fapolicyd do Linux) para bloquear a execução em diretórios graváveis ​​pelo usuário (%APPDATA% do Windows, ~/Downloads do macOS, /tmp ou /var/tmp do Linux).
• Particione os hosts Linux para montar /tmp e /home com a flag noexec.
• Audite o inventário de software para gerar alertas sobre a execução de RMMs e registros não aprovados de serviços/daemons do sistema.
• Treine usuários em táticas de engenharia social, fingindo ser o suporte de TI.

Controle de acesso à rede e reforço físico de filiais

• Implante o Controle de Acesso à Rede (NAC) 802.1X em portas de switches Ethernet físicos em filiais/lojas para impedir que dispositivos de hardware não autorizados obtenham acesso ao endereço de protocolo de internet (IP) ou comunicação em sub-redes internas.
• Desative as portas de switch não utilizadas e aplique a segurança de porta (por exemplo, limitação de MAC) em conexões de rede críticas.
• Restrinja fisicamente o acesso aos armários de rede e proteja as tomadas públicas.

Active Directory e Reforço de Credenciais

• Restringir utilitários administrativos (por exemplo, ntdsutil.exe, vssadmin.exe) e gerar alertas sobre a criação/exclusão de cópias de sombra de volume.
• Imponha o Modo de Linguagem Restrita (CLM) do PowerShell, o Registro de Blocos de Script (ID de Evento 4104) e a Interface de Verificação Antimalware (AMSI) para detectar a execução de scripts de reconhecimento na memória.
• Exigir autenticação multifator (MFA) resistente a phishing e controles de bloqueio em todos os portais externos (VPNs, Software como Serviço (SaaS)).

Inspeção profunda de pacotes e controle de tráfego de saída

• Realize a descriptografia SSL/TLS e a inspeção profunda de pacotes (DPI) no tráfego web de saída, em vez de depender da reputação do domínio ou das listas de permissão de domínios de nível superior (TLD) .gov.
• Bloquear portas e protocolos de saída não essenciais (por exemplo, o Protocolo de Mensagens de Controle da Internet (ICMP) de saída) e restringir utilitários de tunelamento como Chisel ou GSocket).
• Segmentar redes para bloquear o tráfego lateral SMB (porta 445) e RDP (porta 3389) entre estações de trabalho e servidores.

Kubernetes e Isolamento de Carga de Trabalho na Nuvem

• Aplique um controle de acesso baseado em funções (RBAC) rigoroso no Kubernetes, utilizando o princípio do menor privilégio para contas de serviço.
• Utilize controladores de admissão dinâmicos (por exemplo, OPA Gatekeeper ou Kyverno) e o recurso nativo de Admissão de Segurança de Pod (PSA) para bloquear contêineres privilegiados.
• Aplique políticas de rede de saída para bloquear o acesso de nós e pods a plataformas públicas não autorizadas.

Gestão de Segredos e Micro Segmentação do Sistema Financeiro

• Exija um Gerenciador de Segredos centralizado (por exemplo, HashiCorp Vault) com registro de acesso; elimine as chaves em texto simples no código.
• Implementar micro segmentação baseada em identidade/Camada 7 para cargas de trabalho financeiras.
• Limitar o acesso administrativo exclusivamente a servidores de salto dedicados por meio do gerenciamento de acesso privilegiado (PAM).