A campanha que trancou administradores fora do próprio firewall não usa nenhuma falha de software

A cadeia, do começo ao que é vendido no fim

A descrição do aviso e do levantamento da SOCRadar monta uma operação industrial, em seis etapas, sem nenhuma delas dependendo de software quebrado.

1. Varredura da internet em busca de portais de SSL VPN de FortiGate expostos.
2. Tentativa de autenticação com credencial recolhida em vazamentos anteriores da Fortinet e em registro de ladrão de informação, por preenchimento de credencial e pulverização de senha.
3. Quebra de hash exfiltrado fora do aparelho, em cluster distribuído de GPU, com Hashcat para o cálculo e Hashtopolis para repartir o trabalho. O que facilita essa etapa é o armazenamento legado de senha em SHA-256 no FortiOS.
4. Filtragem de honeypot, mapeamento das organizações e ordenação dos alvos por receita e estrutura de rede. É triagem comercial, não técnica.
5. Entrada com credencial verificada, enumeração do Active Directory e pulverização de senha contra conta privilegiada.
6. Venda da configuração de VPN que funciona e da lista de alvos para quem opera a etapa seguinte.

A terceira etapa é a que merece atenção de quem administra FortiGate antigo. Hash quebrado fora do aparelho significa que a senha vazada em junho pode estar sendo convertida em acesso hoje. O aviso recomenda confirmar que a credencial administrativa do FortiOS usa PBKDF2 e expurgar hash legado, disponível a partir da versão 7.2.11. Isso não é endurecimento opcional: é remover o insumo que alimenta o cluster de GPU do atacante.

O bloqueio administrativo, e por que ele é diferente

Na maioria dos incidentes de borda, o pior caso é o atacante manter persistência. Aqui o pior caso é a vítima perder o controle. Criar conta de administrador é persistência comum, catalogada no ATT&CK. Apagar a conta legítima e trocar a senha é remoção de acesso, uma técnica de impacto, e quando ela recai sobre o firewall de perímetro o efeito é invertido: a ferramenta de contenção passa a estar do lado de quem invadiu.

John Strand, da Black Hills Information Security, resumiu o que mais o preocupa no caso, e não é o bloqueio: é o atacante que quer viver em silêncio dentro da organização pelo máximo de tempo possível. O bloqueio é o barulho. A credencial válida guardada em inventário por meses é o problema.

Esse detalhe tem consequência prática imediata. Aparelho comprometido meses atrás continua na lista do operador. Quem trocou senha em junho, quando o vazamento apareceu, e não auditou conta administrativa, chave de API e porta SSH, provavelmente ainda tem o visitante.

O que procurar hoje

A caça aqui é de inventário, não de assinatura. Três frentes, em ordem de retorno:

• Conta administrativa que você não reconhece. O aviso e o levantamento listam nomes repetidos pela campanha, entre eles adminin, forticloud-tech, gttadmin, Technical_support, my_admin, forti_support2, fgtsecure e variações de fortiAdmin e IT_Manager. Qualquer conta fora da lista oficial da sua operação é indício forte, e o nome parecido com suporte é o truque mais antigo do repertório.
• Chave de API REST configurada. É o item que sobrevive à troca de senha e o que mais gente esquece de enumerar. Listar, comparar com o que a operação realmente usa e revogar o resto.
• SSH exposto no firewall. O aviso trata essa porta como vetor silencioso. Em parque montado por integrador, ela costuma estar aberta porque alguém precisou dela em uma madrugada de 2019.

No lado de rede, o levantamento registra sinalização por HTTPS nas portas 4332 e 4432 e uma lista de cerca de 13 endereços usados em junho e julho para força bruta e autenticação bem-sucedida, além de endereços de comando e controle, proxy e do próprio Hashtopolis. Vale a ressalva que a própria SOCRadar faz: endereço de nuvem é reatribuído, então conferir contra a telemetria atual antes de bloquear.

Por que isso pega mais forte na América Latina

FortiGate é, de longe, o firewall mais vendido na faixa média do mercado brasileiro e dos vizinhos. Está em escritório de advocacia, rede de farmácia, indústria de autopeças, prefeitura, cooperativa, clínica. O padrão de instalação nessa faixa tem três características que combinam mal com esta campanha específica.

A primeira é que o aparelho foi instalado e configurado por integrador, e a senha de administração ficou com ele. Em muitos casos é a mesma senha em vários clientes. A segunda é que o SSL VPN está aberto para a internet porque é assim que o pessoal trabalha de casa, e o segundo fator foi considerado atrito. A terceira é que ninguém mantém lista nominal de contas administrativas do firewall, então não existe referência contra a qual comparar.

Junte as três e você tem exatamente o alvo que a etapa de triagem da campanha procura: credencial reaproveitável, porta aberta e nenhuma linha de base. A ordenação por receita que o aviso descreve significa que empresa média e lucrativa é alvo preferencial, não sobra.

Há um agravante contratual. Quando o integrador detém a credencial administrativa, o cliente não consegue nem auditar nem revogar sozinho. E se a credencial do integrador vazou, o comprometimento chega a todos os clientes dele de uma vez. Essa é a conversa a ter nesta semana, e ela é sobre contrato, não sobre firewall.

O plano de dez dias

• Listar toda conta administrativa de todo FortiGate e comparar com a lista nominal da operação. Se a lista nominal não existir, criar nessa hora é metade do trabalho feito.
• Enumerar e revogar chave de API REST não reconhecida, antes de qualquer troca de senha. Na ordem inversa, você avisa o atacante e não tira o acesso dele.
• Encerrar sessão administrativa e de VPN ativa, e só então redefinir credencial de administração e de VPN em tudo que está voltado para a internet.
• Verificar a versão do FortiOS e confirmar PBKDF2 no armazenamento de senha administrativa. Em versão anterior à 7.2.11, planejar a atualização como medida de credencial, não de correção de falha.
• Exigir segundo fator resistente a phishing no acesso remoto e na administração. É a única medida da lista que derruba a eficácia da campanha inteira, porque credencial válida deixa de ser suficiente.
• Fechar a administração externa e o SSH do aparelho. Se a operação depende de acesso remoto do integrador, que seja por faixa fixa e com registro.
• Testar o caminho de recuperação fora de banda: acesso por console serial, credencial de emergência guardada fora do ambiente, procedimento escrito. Esta campanha é o cenário em que isso é usado.
• Revisar registro de firewall, VPN, autenticação e controlador de domínio em busca de autenticação bem-sucedida de origem estranha e de enumeração de Active Directory. O aviso pede especificamente essa correlação, porque é onde a venda de acesso aparece como movimentação lateral.

A parte que ninguém gosta de registrar

Uma campanha sem CVE não entra no catálogo de falhas exploradas, não gera prazo regulatório, não aparece em relatório de varredura de vulnerabilidade e não fecha com uma linha de atualização. Ela não cabe no processo de gestão de vulnerabilidade que a maioria das empresas construiu. Cabe no processo de gestão de identidade, que na borda de rede costuma não existir.

O FortiBleed veio a público em junho, quando um pesquisador achou um conjunto de nomes de usuário e senhas em texto claro da Fortinet. Quatro meses depois, duas agências federais americanas publicam aviso dizendo que a varredura continua, com credencial já obtida, e que organizações estão sendo trancadas fora dos próprios aparelhos. Entre o vazamento e o aviso havia uma janela de quatro meses para trocar credencial e auditar conta. Os 86.644 aparelhos são a medida de quantos não usaram essa janela.