Mitigando ataques massivos de credenciais

O FortiBleed não é um novo ataque isolado, é a fase operacional madura de uma cadeia de exploração que já vinha sendo construída desde fevereiro. A campanha agora opera em ciclo fechado: spraying → extração de configurações com credenciais armazenadas → cracking offline → reinjeção na lista de senhas. Isso explica por que, em 19 de junho, foram encontrados 74 mil conjuntos de credenciais de VPN expostos em um servidor comprometido: não são apenas senhas roubadas, mas o *produto bruto* da etapa de extração e cracking, pronto para ser reutilizado em novas rodadas.

A escalada de privilégios local citada no relatório da Unit 42 tem raiz direta na CVE-2026-35616, explorada desde 1º de junho no FortiClient EMS, uma falha que permite manipular configurações sem autenticação e injetar comandos via fortitray.exe. Ela serve como porta de entrada para extrair credenciais armazenadas em arquivos de configuração, mesmo quando o acesso inicial é limitado. O IAB do Exploit[.]in não está vendendo 'acesso', mas sim o *resultado processado*: credenciais decifradas, domínios identificados, permissões mapeadas, dados prontos para pivô em redes corporativas.

Em fevereiro, o ator usava IA generativa para escalar ataques manuais contra 600 FortiGate. Em abril, a Operação Storming Tide já mostrava coordenação entre grupos e uso de múltiplas técnicas de intrusão em perímetro. Em 1º de junho, a exploração da CVE-2026-35616 permitiu automação massiva de extração. Agora, em 22 de junho, o FortiBleed opera como infraestrutura autônoma: o próprio ciclo de cracking alimenta o spraying, e os logs de sucesso após falhas em massa deixaram de ser sinal de tentativa, viraram indicador de comprometimento confirmado. O que era tático virou operacional.

Essa campanha ignora a ideia de 'ataque pontual'. Ela transforma cada dispositivo exposto em fonte contínua de credenciais válidas, e cada credencial válida vira vetor para mais dispositivos. O risco não está só no FortiGate ou no MSSQL exposto; está na rede interna que esses acessos admin permitem alcançar. Empresas que adotaram ZTNA com jump boxes estão protegidas não porque bloqueiam o ataque, mas porque removem o alvo: sem interface de gestão na internet, não há onde aplicar o spraying. A exigência de MFA não é uma camada extra, é o único obstáculo que impede a conversão de uma senha roubada em acesso administrativo real.