Campanha FortiBleed Contra Fortinet Segue Ativa

O FBI e o Secret Service (USSS) emitiram um alerta conjunto confirmando que a campanha FortiBleed, voltada a firewalls FortiGate e gateways SSL VPN da Fortinet expostos à internet, continua ativa. Segundo o alerta conjunto publicado em 6 de outubro, atacantes seguem escaneando firewalls Fortinet expostos com credenciais comprometidas obtidas antes. A SOCRadar verificou mais de 86.644 dispositivos comprometidos em 194 países, e o FBI aponta a cadeia de ataque como porta de entrada para afiliados de ransomware.

O ponto central do alerta é simples: isso não é um incidente isolado de junho de 2026, quando a SOCRadar e a Hudson Rock documentaram a campanha pela primeira vez e a atribuíram a uma operação de língua russa. Quase quatro meses depois, como noticiou o The Hacker News, o FBI confirma que o acesso obtido naquele momento continua sendo explorado, e que novas vítimas seguem sendo comprometidas com as mesmas credenciais.

Resumo para quem decide

FortiBleed é uma campanha de coleta e quebra de credenciais que mira firewalls e VPN gateways Fortinet expostos à internet. Não há CVE associado nem versão específica de FortiOS apontada como vulnerável nas divulgações até agora. O vetor é a combinação de credenciais reutilizadas ou vazadas com armazenamento legado de senhas em SHA-256.

A campanha é atribuída a um grupo suspeito de atuar como corretor de acesso inicial, que vende os acessos obtidos a operadores de ransomware. A SOCRadar já confirmou ao menos 12 implantações de ransomware decorrentes desse acesso, com centenas de endpoints criptografados. O FBI cita os ransomwares INC/Lynx e Payload entre os que receberam acesso pela cadeia FortiBleed.

O que fazer agora, segundo o FBI, o USSS e a CISA:

  • Encerrar todas as sessões ativas de SSL VPN e administrativas em appliances Fortinet.
  • Redefinir senhas de VPN e de contas administrativas.
  • Confirmar que as senhas de administrador são guardadas com PBKDF2 e remover os hashes legados, configuração disponível do FortiOS 7.2.11 em diante.
  • Auditar todas as contas locais e as chaves de API REST em busca do que foi criado sem autorização.
  • Impor autenticação multifator resistente a phishing em todo acesso remoto e administrativo.
  • Restringir a administração externa: hosts confiáveis já ajuda, política local-in é melhor, e o ideal é não administrar pela internet.
  • Revisar logs em busca de atividade suspeita, incluindo os nomes de conta listados mais abaixo.

Se houver indício de comprometimento, a orientação do FBI e do USSS é isolar o dispositivo, investigar o escopo da intrusão com logs e artefatos e só então aplicar as contramedidas de expulsão. O alerta também pede que o caso seja reportado ao FBI e ao USSS, orientação dirigida a organizações dos Estados Unidos.

O que é a campanha FortiBleed e como ela opera

FortiBleed não é uma vulnerabilidade de software isolada com um identificador formal. É uma operação estruturada de coleta de credenciais que explora dois fatores combinados: reutilização e vazamento de senhas, e o uso de SHA-256 legado para armazenar credenciais em dispositivos Fortinet. Isso permite que os atacantes coletem hashes em escala e os quebrem offline com infraestrutura própria.

A escala é o que chama atenção. Em 19 de junho de 2026, a SOCRadar já contava mais de 86.644 dispositivos comprometidos em 194 países, número que o FBI repete no alerta. Não há dado atualizado desde então. O que o alerta confirma é que o escaneamento continua.

O funcionamento interno da operação só ficou visível porque os próprios atacantes deixaram exposto o servidor de backend. A análise desse diretório aberto, feita pela CloudSEK e citada pelo FBI, mostrou a cadeia inteira: como os alvos eram escolhidos, como as credenciais eram validadas e como o acesso era ampliado dentro das vítimas.

As cinco etapas do ataque: do reconhecimento à exfiltração

A estrutura da campanha, segundo o alerta e o relato reproduzido pelo The Hacker News, segue cinco estágios:

  1. Reconhecimento amplo para identificar portais Fortinet expostos à internet.
  2. Acesso inicial via credential stuffing e password spraying, usando dados de vazamentos anteriores e logs de infostealers.
  3. Interceptação de tráfego com uma ferramenta escrita em Go chamada FortigateSniffer, que captura passivamente tráfego de autenticação em 24 protocolos diferentes, coletando credenciais e hashes de senha. Segundo o FBI, os atacantes também extraíram dos aparelhos a base de usuários do FortiOS e tokens de sessão.
  4. Quebra offline em escala, com hashes enviados a um cluster de GPUs alugadas que usa Hashcat e Hashtopolis, ferramenta aberta que distribui a quebra de senha entre várias máquinas. As credenciais quebradas alimentam movimento lateral, enumeração de Active Directory, validação Kerberos e autenticação SMB.
  5. Exfiltração, com dados sensíveis retirados de compartilhamentos de rede e uso de cookies de sessão roubados para manter acesso autenticado persistente, sem precisar reautenticar.

Depois da quebra, as credenciais passam por um processo de enriquecimento: scripts filtram honeypots, mapeiam a organização dona de cada credencial e priorizam alvos de alto valor com base em receita e estrutura de rede. Isso indica um nível de automação e triagem comercial pouco comum em campanhas de coleta de credenciais, reforçando a hipótese de que o grupo opera como fornecedor de acesso para terceiros, não como operador final do ataque.

Por que o armazenamento legado de senhas em SHA-256 é o elo fraco

O fator técnico recorrente em todo o relato é o uso de SHA-256 sem um KDF (Key Derivation Function) robusto para armazenar credenciais de administrador. SHA-256 é rápido de computar, o que o torna adequado para integridade de dados, mas inadequado para armazenar senhas: isso permite quebra em alta velocidade com hardware GPU, que é exatamente o que o cluster Hashmat/Hashtopolis explora.

A CISA e agora o FBI recomendam PBKDF2, que é projetado para ser computacionalmente custoso e dificultar a força bruta em massa. O alerta remete à orientação técnica da Fortinet para forçar PBKDF2 nas contas de administrador a partir do FortiOS 7.2.11 e pede a remoção dos hashes legados mais fracos. Ou seja, é configuração que o administrador aplica, numa versão que já tem o recurso.

Senha mal guardada dentro do próprio aparelho é o tipo de problema que nenhuma varredura de rede comum mostra. Para entender como falhas estruturais em firmware viram vetor de ataque, vale ler sobre segurança de firmware e vulnerabilidades ocultas em dispositivos de infraestrutura.

Por que o FBI considera a ameaça ativa quatro meses depois

O alerta de outubro de 2026 não é sobre uma vulnerabilidade nova. É sobre a confirmação de que o acesso obtido em junho continua sendo usado. Ensar Seker, CISO da SOCRadar, resume o ponto central: “FortiBleed deve ser tratado como uma operação de acesso ativa, não como um vazamento de credencial único.” Segundo ele, o escaneamento contínuo com credenciais previamente comprometidas, a criação de contas administrativas não autorizadas e os lockouts reportados mostram que os operadores ainda estão tentando preservar e expandir o acesso.

Isso muda a forma como uma organização deve responder. Não basta trocar a senha de uma conta específica depois de um incidente pontual. Se uma credencial foi exposta em junho e nunca foi rotacionada, ela pode continuar válida hoje, meses depois, servindo como porta de entrada para qualquer comprador do acesso no mercado de corretores de acesso inicial.

Contas administrativas suspeitas e o risco de lockout

Durante a intrusão inicial, os atacantes criam contas administrativas que não existiam previamente no dispositivo. Em alguns casos, eles chegam a deletar contas legítimas para bloquear a própria equipe de TI da vítima, mantendo persistência exclusiva enquanto avançam lateralmente no ambiente.

Os nomes de conta identificados como suspeitos nessa campanha incluem: adminin, fortiAdmin, forticloud-sync, admin, fgtsecure, pakedge, forticloud-tech, districtadmin, system_config, gttadmin, roadmin, itadmin, Technical_support, adminsslvpn, IT_Manager, my_admin, support_fortinet, fgtsec e forti_support2. Nenhum desses nomes é, isoladamente, prova de comprometimento, mas contas com esses padrões que não foram criadas pela própria equipe merecem investigação imediata. O FBI recomenda comparar a configuração atual com uma configuração conhecida e confiável, e lembra que, em alguns casos, os atacantes podem ter entrado por SSH quando a porta estava aberta no firewall.

O FBI e o USSS alertam que algumas vítimas já ficaram bloqueadas em seus próprios dispositivos Fortinet depois que o atacante deletou ou alterou a senha das contas originais do sistema. Ben Bernstein, da Huntress, descreve o padrão de forma direta: os atacantes “confiantemente alteram senhas de administrador, bloqueiam a equipe de TI real fora de seu próprio equipamento, e entregam as chaves diretamente para grupos de ransomware”. Para ele, quem perdeu o acesso ao próprio firewall não resolve com um patch, e os atacantes contam com o tempo que a vítima vai gastar em reset de fábrica e reconstrução do equipamento. O FBI diz o mesmo de forma mais contida: a recuperação exige mais do que aplicar patch e trocar senha.

A ponte entre o acesso inicial e os ransomwares INC, Lynx e Payload

O que torna o FortiBleed particularmente perigoso não é apenas o volume de credenciais coletadas, mas o que acontece depois. A SOCRadar confirmou uma ligação operacional direta entre o acesso obtido via FortiBleed e o ecossistema de ransomware INC e Lynx, resultando em pelo menos 12 implantações confirmadas e centenas de endpoints criptografados. Separadamente, corretores de acesso inicial usando a mesma cadeia de ataque também forneceram acesso a afiliados do ransomware Payload.

Isso evidencia que a operação é financeiramente motivada e funciona como parte de uma cadeia de suprimento mais ampla do cibercrime, não servindo a uma única marca de ransomware. Um único corretor de acesso inicial, explorando uma única fraqueza em appliances de borda, consegue abastecer múltiplos grupos de ransomware simultaneamente.

Bernstein, da Huntress, destaca um detalhe operacional incomum: os atacantes conseguem logar de primeira tentativa, sem gerar um único alerta de login falho, porque já possuem credenciais válidas. Isso neutraliza boa parte da detecção tradicional baseada em tentativas de força bruta ou falhas repetidas de autenticação.

Como identificar se sua organização foi afetada

Como o vetor de ataque é credencial válida, e não exploração de uma falha de software específica, a detecção depende menos de assinaturas de rede e mais de auditoria de contas e comportamento pós-autenticação. Passos recomendados:

  • Revisar a lista de contas administrativas e locais em todos os appliances FortiGate, comparando com o inventário esperado pela equipe de TI. Qualquer conta não reconhecida, especialmente com nomes semelhantes aos listados acima, deve ser tratada como suspeita.
  • Verificar se há contas administrativas criadas recentemente sem registro de solicitação interna.
  • Revisar logs de autenticação SSL VPN em busca de logins bem-sucedidos vindos de IPs ou geolocalizações incomuns, já que não há padrão de tentativas falhas para detectar nesse ataque.
  • Verificar se há sessões ativas antigas que nunca foram encerradas, já que cookies de sessão roubados são usados para manter acesso persistente sem reautenticação.
  • Checar se credenciais administrativas ou de VPN usadas na organização apareceram em vazamentos anteriores ou em logs de infostealers, já que esse é o ponto de entrada original da campanha.

O alerta também traz endereços IP para cruzar com os logs: 45.154.12.132 como servidor de comando e controle, 154.202.59.169 e 103.27.186.156 como proxies, 45.155.250.158 como relay e 85.11.187.8 ligado ao Hashtopolis, além de uma tabela com 13 endereços vistos entre 18 de junho e 23 de julho fazendo força bruta ou logando com contas comprometidas. O próprio FBI avisa que IP de nuvem muda de dono, então a lista serve para busca retroativa, não para bloqueio às cegas.

Vale lembrar que credenciais vazadas não chegam às mãos de corretores de acesso inicial apenas por falhas no próprio appliance. Phishing direcionado contra administradores de rede é um vetor complementar comum para captura de credenciais que depois alimentam campanhas como o FortiBleed. Para entender como esse tipo de ataque funciona e como reduzir a exposição da equipe técnica, veja o conteúdo sobre spear phishing.

Se qualquer um desses sinais for identificado, o FBI e o USSS recomendam isolar o dispositivo, coletar logs e artefatos para entender o escopo e só então aplicar as contramedidas, para não apagar a evidência de que a investigação precisa.

Como proteger appliances Fortinet e outros dispositivos de borda

As recomendações do FBI e da CISA, reforçadas pela SOCRadar e pela Huntress, formam um conjunto de ações que qualquer organização com FortiGate exposto à internet deveria aplicar:

  • Encerrar todas as sessões ativas de SSL VPN e administrativas, forçando reautenticação de todos os usuários.
  • Redefinir senhas de todas as contas de VPN e administrativas, não apenas das contas suspeitas de comprometimento.
  • Usar PBKDF2 nas senhas de administrador e remover os hashes legados, recurso do FortiOS 7.2.11 em diante, conforme orientação da Fortinet.
  • Impor MFA resistente a phishing em todo acesso remoto, eliminando a dependência exclusiva de senha.
  • Restringir a administração externa: hosts confiáveis é o mínimo, política local-in é melhor, e o ideal é remover a administração pela internet.
  • Revisar as chaves de API REST: remover as desconhecidas e renovar as legítimas, como pede o FBI.
  • Comparar a configuração de firewall e VPN com uma versão conhecida e confiável, atrás de usuários e mudanças não autorizadas.
  • Investigar atividade downstream em vez de confiar apenas em aplicar patches, já que o vetor é credencial e não necessariamente uma falha corrigível via atualização de firmware.

Seker, da SOCRadar, resume a lógica por trás dessas medidas: “credenciais expostas não se tornam inofensivas com o tempo. Se permanecerem válidas, ou se os atacantes já criaram contas persistentes no appliance, elas podem continuar a fornecer um ponto de entrada meses após a atividade original de coleta.” Por isso a orientação é tratar qualquer possível exposição como um cenário de comprometimento ativo, não como um evento encerrado.

Esse caso também reforça por que dispositivos de borda, como firewalls e VPN gateways, exigem uma arquitetura de rede que limite o estrago de um comprometimento único. Segmentação de rede e redução de superfície de exposição externa evitam que o acesso a um único appliance se transforme automaticamente em movimento lateral irrestrito pelo ambiente inteiro. Esse princípio de arquitetura é discutido com mais profundidade na análise sobre resiliência cibernética em ambientes industriais.

Perguntas frequentes

O FortiBleed tem um CVE associado?
Não há identificador de CVE citado pelo FBI, pela SOCRadar ou pela Huntress nas divulgações sobre essa campanha. O que é descrito é uma combinação de credenciais reutilizadas ou vazadas com armazenamento legado de senhas em SHA-256, não uma falha de software isolada e numerada.

Quais versões de FortiOS ou FortiGate são afetadas?
O alerta vale para todo cliente Fortinet com gateway exposto e não lista versões vulneráveis, porque o vetor é credencial, não falha de código. A única versão citada é a do recurso de proteção: forçar PBKDF2 nas contas de administrador é configuração disponível do FortiOS 7.2.11 em diante.

Minha organização pode ter sido afetada sem eu saber?
Sim. Como os atacantes usam credenciais válidas, não há tentativas de login falhas para detectar. A forma mais confiável de verificar é auditar contas administrativas em busca de contas não reconhecidas, revisar sessões ativas antigas e checar se credenciais da organização apareceram em vazamentos anteriores.

O que fazer se eu suspeitar de comprometimento?
Isolar o dispositivo afetado, coletar logs e artefatos para entender o escopo e só então aplicar as contramedidas: redefinir credenciais, encerrar sessões ativas, auditar contas locais e chaves de API. O alerta pede que o incidente seja reportado ao FBI e ao USSS, orientação dirigida a organizações dos Estados Unidos.

Por que meu dispositivo pode ficar bloqueado mesmo depois de eu tentar corrigir o problema?
Porque, em alguns casos, o atacante já alterou a senha ou apagou as contas originais do sistema para manter persistência exclusiva. Segundo o FBI, isso exige remediação além de patch e troca de senha. Para a Huntress, na prática significa reset de fábrica e reconstrução do equipamento.

Facebook
Twitter
WhatsApp