Campanha explorou portas de gerenciamento expostas, credenciais fracas e autenticação de fator único para coletar configurações, acessar VPNs e avançar sobre Active Directory e infraestrutura de backup.
| Componente | Dispositivos FortiGate com interfaces de gerenciamento expostas à internet, ambientes VPN associados, Active Directory e servidores Veeam Backup & Replication acessíveis após intrusão. |
| Vetor | Varredura sistemática de interfaces FortiGate nas portas 443, 8443, 10443 e 4443, seguida de tentativas de autenticação com credenciais comuns ou reutilizadas e ausência de autenticação multifator. |
| Impacto | Mais de 600 dispositivos em 55 países foram comprometidos; em alguns ambientes houve extração de configurações completas, acesso a VPN, comprometimento de Active Directory, coleta de credenciais e tentativa de alcançar infraestrutura de backup. |
| Prioridade | Remover interfaces administrativas da exposição pública, trocar credenciais fracas ou padrão, rotacionar credenciais SSL-VPN, aplicar MFA em administração e VPN, auditar contas administrativas e isolar backups. |
| Artefatos | Infraestrutura exposta continha planos de ataque gerados por IA, configurações de vítimas, código-fonte de ferramentas próprias, modelos Nuclei, dados de coleta BloodHound, ferramenta CHECKER2 e servidor MCP customizado ARXON. |
| IoC | A atividade de varredura foi associada ao endereço 212.11.64[.]250, que também hospedava artefatos da campanha. |
Uma campanha financeiramente motivada, operada por um ator de língua russa com capacidade técnica limitada, comprometeu mais de 600 dispositivos FortiGate distribuídos por 55 países entre 11 de janeiro e 18 de fevereiro de 2026. O diferencial operacional não foi a exploração de uma vulnerabilidade FortiGate específica, mas o uso de serviços comerciais de inteligência artificial generativa para ampliar planejamento, desenvolvimento de ferramentas, geração de comandos e organização de múltiplas intrusões simultâneas. A atividade demonstra que controles básicos ausentes em perímetro, especialmente gerenciamento exposto, credenciais fracas e autenticação de fator único, podem ser transformados em escala operacional quando combinados com automação e assistência de modelos de linguagem.
O acesso inicial se concentrou em interfaces de gerenciamento FortiGate expostas à internet nas portas 443, 8443, 10443 e 4443. Após localizar alvos, o operador tentou autenticação com credenciais comuns ou reutilizadas. Quando o acesso era obtido, a coleta de configurações completas do dispositivo permitia mapear credenciais, topologia de rede, parâmetros de VPN e informações úteis para movimentação posterior. A campanha foi descrita como setorialmente agnóstica: o comportamento observado priorizava volume, exposição e facilidade de acesso, em vez de seleção criteriosa de uma indústria ou organização específica.
A etapa posterior ao comprometimento do FortiGate variava conforme a maturidade defensiva da vítima. Em ambientes com controles mais rígidos, serviços corrigidos, portas fechadas ou ausência de vetores simples, o operador frequentemente abandonava o alvo e migrava para outra organização mais vulnerável. Em ambientes mais frágeis, a intrusão avançava para acesso VPN, reconhecimento interno, avaliação de vulnerabilidades, comprometimento de Active Directory, coleta de credenciais e busca por servidores de backup. Esse padrão é compatível com preparação para operações de ransomware, embora o material analisado sustente apenas as etapas de intrusão, coleta e preparação técnica, não uma implantação confirmada de ransomware.
A cadeia começava com varredura de massa contra interfaces FortiGate publicamente acessíveis. O tráfego de reconhecimento foi associado ao endereço 212.11.64[.]250, com foco em portas comumente usadas para painéis administrativos ou serviços expostos em appliances de borda. A campanha não dependia de exploração observada de falhas FortiGate; o caminho dominante era autenticação bem-sucedida em serviços acessíveis pela internet. Essa distinção é importante para resposta: ambientes totalmente corrigidos ainda podiam estar expostos se mantivessem gerenciamento aberto, senhas reutilizadas ou contas administrativas sem MFA.
Depois da autenticação, o operador extraía configurações completas dos dispositivos. Esse material podia revelar usuários, credenciais armazenadas ou reutilizáveis, objetos de rede, rotas, túneis VPN, endereçamento interno, nomes de sistemas e relações entre segmentos. Em clusters de uma mesma organização, a coleta permitia passar de um appliance comprometido para outros dispositivos pertencentes ao mesmo ambiente, elevando o impacto de um único erro de exposição. A análise da distribuição geográfica indicou clusters comprometidos no Sul da Ásia, América Latina, Caribe, África Ocidental, Norte da Europa e Sudeste Asiático.
Após obter acesso VPN a redes vítimas, o ator implantava uma ferramenta customizada de reconhecimento com versões em Go e Python. O código apresentava sinais compatíveis com desenvolvimento assistido por IA: comentários redundantes que repetiam nomes de funções, arquitetura simples, esforço desproporcional em formatação, análise ingênua de JSON por comparação de strings e camadas de compatibilidade pouco documentadas. Esses sinais não provam sozinhos autoria por IA, mas são consistentes com um operador usando modelos de linguagem para compensar lacunas de engenharia e produzir ferramentas suficientes para automação operacional.
A infraestrutura exposta do operador hospedava mais de 1.400 arquivos em 139 subdiretórios. Entre os artefatos estavam código de exploração de CVEs, arquivos de configuração FortiGate, modelos de varredura Nuclei, ferramentas voltadas à extração de credenciais em Veeam, dados de coleta BloodHound e componentes próprios. Um servidor MCP customizado chamado ARXON processava resultados de varredura e reconhecimento, acionava modelos de linguagem para gerar planos de ataque e integrava scripts voltados a alterações em infraestrutura comprometida. Outro componente, o orquestrador em Go CHECKER2, era usado para varredura paralela de VPN e processamento de alvos.
A superfície primária eram appliances FortiGate com interfaces administrativas ou de gerenciamento acessíveis pela internet. A exposição em si não equivale a comprometimento, mas cria uma condição crítica quando combinada com credenciais fracas, padrão ou reutilizadas. A ausência de autenticação multifator ampliava o risco, porque a barreira entre uma credencial descoberta e o acesso efetivo ao equipamento ficava reduzida a uma única prova de identidade. Em appliances de borda, essa falha é especialmente sensível porque o dispositivo costuma ter visibilidade de túneis, rotas, políticas e integrações com serviços internos.
A superfície secundária surgia depois do acesso VPN. O operador buscava reconhecimento interno, coleta de credenciais e caminhos simples para Active Directory. O contexto inclui tentativa de movimentação lateral por técnicas como pass-the-hash, pass-the-ticket, relay NTLM e execução remota de comandos em hosts Windows, mas comandos específicos e procedimentos operacionais não devem ser reproduzidos. A campanha também direcionava atenção a servidores Veeam Backup & Replication, incluindo ferramentas de coleta de credenciais e programas relacionados a vulnerabilidades conhecidas como CVE-2023-27532 e CVE-2024-40711.
A escolha de alvos indicou oportunismo automatizado. O operador não demonstrou insistência contra ambientes endurecidos; quando encontrava serviços corrigidos, portas fechadas ou ausência de caminhos exploráveis simples, registrava falhas e seguia para outro alvo. Esse comportamento reduz a utilidade de uma leitura baseada apenas em atribuição ou setor e reforça a importância de reduzir exposição externa, credenciais reutilizadas e relações excessivas entre perímetro, VPN, diretório e backup.
- FortiGate com gerenciamento exposto nas portas 443, 8443, 10443 ou 4443.
- Contas administrativas ou SSL-VPN sem MFA e com credenciais comuns, padrão ou reutilizadas.
- Ambientes em que configurações do appliance revelam credenciais, topologia, túneis VPN ou rotas internas.
- Active Directory acessível a partir de VPN comprometida, especialmente com NTLM, hashes e tickets reutilizáveis.
- Servidores Veeam Backup & Replication alcançáveis a partir de segmentos comprometidos.
A investigação defensiva deve começar no perímetro, correlacionando tentativas de autenticação em interfaces FortiGate expostas com origem, horário, conta, resultado e volume. A presença do endereço 212.11.64[.]250 em logs históricos é um sinal relevante, mas não deve ser tratada como único indicador. Como a campanha se baseia em varredura e credenciais, equipes devem procurar padrões de tentativa contra múltiplas contas, autenticações administrativas fora de janela, alterações de configuração após login, exportação de configuração, criação de contas, mudança de políticas e acessos VPN que não correspondem ao comportamento usual dos usuários.
No endpoint e no diretório, a caça deve se concentrar no período posterior a um acesso VPN suspeito. Sinais de reconhecimento interno, execução remota em hosts Windows, enumeração de domínio, coleta BloodHound, autenticações NTLM incomuns e uso de credenciais privilegiadas em hosts fora do padrão são mais úteis do que procurar apenas malware tradicional. A campanha também usou Nuclei para reconhecimento de vulnerabilidades, portanto requisições internas com assinaturas de varredura, sequência rápida de probes HTTP e acesso a múltiplos serviços a partir de um mesmo host recém-conectado por VPN merecem análise.
Em infraestrutura de backup, a telemetria deve incluir autenticações administrativas, consultas anormais a bancos ou repositórios de configuração, acesso de contas que não operam rotinas de backup e execução de ferramentas desconhecidas no servidor. Como backups são alvo frequente em intrusões que precedem extorsão, qualquer correlação entre acesso VPN suspeito, enumeração de Active Directory e atividade em Veeam deve ser tratada como incidente de alta prioridade, mesmo sem evidência de criptografia ou exfiltração confirmada.
- Tentativas de login em FortiGate a partir de 212.11.64[.]250 ou de origens incomuns, especialmente nas portas 443, 8443, 10443 e 4443.
- Exportação ou leitura de configuração FortiGate logo após autenticação administrativa.
- Novas contas administrativas, mudanças de política, alterações em VPN ou conexões administrativas fora do padrão.
- Acesso VPN seguido por reconhecimento interno, varredura Nuclei, enumeração de Active Directory ou coleta BloodHound.
- Autenticações NTLM incomuns, uso de credenciais privilegiadas em hosts não habituais e sinais de pass-the-hash ou pass-the-ticket.
- Atividade anormal em Veeam Backup & Replication, incluindo acesso administrativo inesperado e execução de binários desconhecidos.
A resposta deve priorizar redução imediata de exposição. Interfaces administrativas FortiGate não devem ficar acessíveis diretamente pela internet; quando administração remota for indispensável, o acesso deve ser restrito por VPN corporativa, listas de controle de origem, segmentação e autenticação multifator. A troca de senhas deve abranger contas administrativas, usuários SSL-VPN e credenciais que possam ter sido armazenadas ou inferidas a partir de configurações exportadas. A rotação precisa considerar reutilização: uma senha válida em FortiGate pode também aparecer em serviços internos, contas de domínio ou ferramentas operacionais.
A contenção exige revisar appliances como fonte de confiança. Equipes devem auditar configurações completas, contas locais, políticas, túneis, certificados, chaves, objetos de rede, rotas e logs de alteração. Dispositivos pertencentes ao mesmo cluster ou organização devem ser analisados em conjunto, porque a campanha demonstrou comprometimento em nível organizacional quando múltiplos FortiGate do mesmo ambiente estavam expostos. A ausência de exploração de vulnerabilidade FortiGate observada não elimina a necessidade de atualização; patch management continua essencial para reduzir caminhos alternativos e impedir que o mesmo operador ou outros grupos explorem falhas conhecidas.
Depois do perímetro, a validação deve seguir para identidade e backup. Active Directory precisa ser revisado para uso indevido de contas privilegiadas, delegações arriscadas, sessões suspeitas, artefatos de coleta e autenticações laterais. Servidores Veeam devem ser isolados do acesso geral de rede, com administração limitada, credenciais segregadas, aplicação de correções e revisão de logs. A segmentação entre VPN, diretório, estáções, servidores críticos e backup reduz a chance de uma credencial de borda se transformar em comprometimento amplo. Como a campanha mostrou uso de IA para escalar operações de baixo nível técnico, controles fundamentais bem aplicados continuam sendo a mitigação mais efetiva.
- Remover exposição pública de interfaces de gerenciamento FortiGate e restringir administração a caminhos controlados.
- Aplicar MFA em acesso administrativo e VPN, sem exceções para contas privilegiadas.
- Trocar credenciais padrão, fracas ou reutilizadas e rotacionar usuários SSL-VPN potencialmente expostos.
- Auditar contas administrativas, sessões VPN, alterações de configuração e exportações de configuração em FortiGate.
- Atualizar FortiGate, Veeam Backup & Replication e demais serviços expostos ou alcançáveis a partir da VPN.
- Isolar servidores de backup, limitar administração, revisar permissões e validar capacidade de restauração.
- Investigar Active Directory para sinais de coleta BloodHound, autenticações NTLM anômalas e uso indevido de credenciais privilegiadas.
0 Comentários