Uma operação que o FBI e o Serviço Secreto dos Estados Unidos batizaram de FortiBleed transformou senhas de firewalls corporativos em produto de prateleira para compradores de acesso. O advisory conjunto publicado em 6 de outubro de 2026 descreve uma campanha global e ativa de comprometimento de credenciais contra firewalls FortiGate e gateways SSL VPN expostos na internet, com mais de 86.644 dispositivos comprometidos em 194 países, segundo verificação da SOCRadar citada no documento. A mesma cadeia de ataque já foi observada como porta de entrada para afiliados de ransomware. Para quem administra dispositivos Fortinet expostos, a ação prioritária é direta: encerrar todas as sessões administrativas e de VPN, trocar as senhas e exigir MFA resistente a phishing em todo acesso remoto.
Como a operação funcionava
Segundo o advisory, os atacantes escanearam a internet em busca de portais SSL VPN FortiGate expostos e coletaram grandes volumes de credenciais com credential stuffing e password spraying a partir de bases vazadas e de logs de infostealer. Os hashes de senha exfiltrados foram enviados a um cluster de GPUs, onde Hashcat e Hashtopolis orquestraram a quebra offline em escala industrial. O documento aponta que a campanha explora reuso de credenciais vazadas e armazenamento legado de senhas em SHA-256, formato antigo do FortiOS que facilita a quebra fora do dispositivo.
A análise da Fortinet sobre o caso reforça esse quadro: a atividade não decorre de uma nova vulnerabilidade, mas envolve o reuso de credenciais de incidentes anteriores, referenciados como FG-IR-26-060 e FG-IR-25-647, e força bruta contra dispositivos com senhas fracas e sem MFA. O elo quebrado não foi o produto em si, e sim a higiene de autenticação do perímetro.
Depois de validar as senhas, os operadores criavam contas administrativas novas nos firewalls para manter persistência, enumeravam o Active Directory das vítimas em busca de contas privilegiadas e empacotavam o acesso para revenda. O advisory classifica o grupo como corretor de acesso inicial, fornecendo redes comprometidas a outros atores, inclusive afiliados de ransomware.
O que o servidor exposto revelou
A operação ficou visível por um erro dos próprios criminosos: um servidor de retaguarda ficou aberto na internet com um diretório navegável contendo 319 arquivos da esteira completa do grupo, dos scanners aos catálogos de venda. A análise técnica da CloudSEK sobre esse material, publicada em junho de 2026, reconstituiu cada etapa a partir dos artefatos deixados para trás.
O diretório mostrou uma instância de Hashtopolis coordenando workers de GPU alugados em provedores de computação, scripts que filtravam honeypots, nos quais qualquer host que aceitasse mais de três pares de credenciais era descartado como isca, e dois tipos de dado com peso probatório muito diferente. O primeiro são hashes de credenciais do FortiOS, extraídos de configurações de dispositivos, cuja atribuição a uma empresa depende de correspondência de e-mail e IP. O segundo são dados de pré-autenticação Kerberos, capturados com sniffers implantados dentro de redes já invadidas, que carregam nomes de domínio interno das próprias vítimas.
O estágio final do pipeline entrega o propósito do grupo: um catálogo de alvos ordenado por receita, com endpoints SSH e VPN pareados com credenciais válidas, formatado exatamente como corretores de acesso inicial empacotam produto para mercados subterrâneos, além de ao menos um arquivo de configuração de SSL VPN ativa apontando para uma rede vítima. O modelo de negócio é o mesmo que já mapeamos ao explicar como o mercado de acessos precifica uma rede.
Um detalhe muda a leitura dos números: o arquivo bruto de credenciais continha também equipamentos de outros fabricantes e entradas malformadas, o que infla qualquer contagem divulgada como especificamente Fortinet.
O risco de ficar trancado fora
O advisory alerta para um efeito operacional concreto: em parte dos casos, os atacantes alteram ou apagam as senhas das contas originais do firewall, deixando a organização sem acesso ao próprio equipamento enquanto tentam movimento lateral. A resposta a esse cenário precisa ir além de correção, que aqui nem é o ponto, e da simples troca de senha.
A Fortinet orienta revisar todas as contas do dispositivo e investigar nomes não reconhecidos. Os nomes recorrentes associados à campanha incluem:
| Conta suspeita | O que verificar |
|---|---|
| forticloud | Criação sem registro de mudança e uso administrativo fora de janela de manutenção |
| fortiuser | Origem do acesso e sessões ativas de longa duração |
| fortinet-support | Suporte legítimo não cria conta local permanente; confirme o ticket antes de aceitar |
| fortinet-tech-support | Mesmo critério: conta permanente de suporte é indicador forte de invasão |
Nos logs, procure autenticações bem-sucedidas de administrador a partir de IPs desconhecidos, beaconing HTTPS em portas como 4332 e 4432 e qualquer alteração de configuração sem responsável identificado. O advisory lista o IP 45.154.12.132 como servidor de comando e controle observado na cadeia.
Resposta priorizada
Para uma equipe defensiva com dispositivos Fortinet expostos, a ordem de execução importa mais do que a lista completa. Prioridade imediata, P1:
- Encerrar todas as sessões administrativas e de VPN ativas e resetar todas as senhas de administrador e VPN, começando pelas contas acessíveis pela internet.
- Exigir MFA resistente a phishing em todo acesso remoto e administrativo, com verificação de que a exigência está de fato aplicada nos gateways externos.
- Inventariar contas locais do firewall e marcar como suspeitas as que não constam na documentação.
- Revisar as chaves de API REST do FortiGate: remover as sem função conhecida e renovar as legítimas.
Em seguida, P2, reduzir a superfície e endurecer o formato de senha:
- Atualizar para versões que suportam hash PBKDF2 de credenciais administrativas e forçar novo login para eliminar hashes legados.
- Restringir a administração externa: trusted hosts é o mínimo, política local-in é melhor e retirar a administração da internet é o ideal.
- Comparar a configuração vigente com uma baseline conhecida e auditar o Active Directory em busca de enumeração, contas novas e autenticações atípicas.
- Tratar como comprometido qualquer dispositivo com login administrativo inexplicado, seguindo o roteiro de recuperação do fabricante.
Contas criadas pelos atacantes sobrevivem à troca de senha se ninguém as fechar: o mesmo princípio do deprovisionamento que elimina contas órfãs vale aqui, com agravante, porque a órfã foi plantada de propósito.
Exposição não é invasão
A CloudSEK mediu a distância entre o número de marketing e o comprometimento real: o total de aproximadamente 21 mil domínios atribuídos à campanha se resolve, na ferramenta dos próprios operadores, em cerca de 918 organizações com tráfego interno capturado e apenas 148 comprometimentos confirmados, menos de um por cento. Nenhuma das grandes marcas citadas na cobertura inicial aparece na lista dos confirmados. A distribuição geográfica, com Índia, Estados Unidos e Taiwan concentrando a maior parte dos dispositivos atribuídos, confirma uma varredura indiscriminada, e não uma campanha setorial dirigida.
A consequência prática para o defensor: aparecer no dataset é motivo para investigar, não prova de invasão. O caminho é procurar os indicadores acima nos próprios logs, e não reagir ao titular de imprensa.