FortiGate é explorado para obter credenciais de contas de serviço e acesso ao Active Directory

Investigações ligam invasões em appliances FortiGate à extração de configurações, uso de credenciais LDAP, ingresso de estáções não autorizadas no AD e exfiltração de artefatos sensíveis do domínio.

Componente	Appliances FortiGate NGFW usados como ponto de entrada e como fonte de arquivos de configuração com credenciais de contas de serviço LDAP/AD.
Vetor	Exploração de vulnerabilidades conhecidas citadas no contexto, como CVE-2025-59718, CVE-2025-59719 e CVE-2026-24858, ou uso de credenciais fracas e configurações inadequadas.
Impacto	Criação de administrador local, alteração de políticas de firewall, autenticação no Active Directory com credenciais de serviço, ingresso de estáções não autorizadas e exfiltração de NTDS.dit e hive SYSTEM em um dos incidentes.
Prioridade	Revisar appliances FortiGate expostos, validar contas locais e políticas recém-criadas, auditar contas de serviço LDAP/AD e centralizar logs em SIEM com retenção mínima de 14 dias.
Artefatos	Conta local chamada support, ferramentas Pulseway e MeshAgent, malware Java executado por DLL side-loading e caminhos de staging em USOShared foram observados nos casos descritos.
IoCs	Um servidor externo defangado 172.67.196[.]232 recebeu dados pela porta 443 no incidente com exfiltração de NTDS.dit e hive SYSTEM.

Resumo técnico

A campanha descrita envolve o abuso de appliances FortiGate de próxima geração como uma ponte entre a borda de rede e serviços internos de identidade. O ponto crítico não é apenas o acesso ao firewall, mas a posição privilegiada que esse equipamento ocupa em muitas arquiteturas corporativas. Em implantações integradas ao Active Directory ou a LDAP, o appliance pode armazenar credenciais de contas de serviço e informações suficientes para correlacionar usuários, grupos, atributos de diretório e políticas de acesso. Quando esse arquivo de configuração é obtido por um invasor, o firewall deixa de ser somente um dispositivo de perímetro comprometido e passa a expor material útil para avanço dentro do ambiente.

Os casos relatados afetaram ambientes ligados a saúde, governo e provedores de serviços gerenciados. Em um incidente, o acesso ao FortiGate ocorreu em novembro de 2025, com criação de um administrador local chamado support e inclusão de quatro políticas de firewall que permitiam trânsito sem restrições entre zonas. Em fevereiro de 2026, uma fase posterior indicou extração da configuração do appliance e recuperação de credenciais LDAP. Em outro caso, investigado no fim de janeiro de 2026, o comprometimento do firewall foi seguido por implantação de ferramentas de acesso remoto, obtenção de malware a partir de armazenamento em nuvem na AWS e exfiltração de artefatos do domínio para um endereço externo defangado.

Fluxo técnico

O primeiro fluxo observado começa com acesso administrativo ao FortiGate por exploração de falhas conhecidas, credenciais fracas ou configuração inadequada. O contexto cita CVE-2025-59718, CVE-2025-59719 e CVE-2026-24858 como exemplos de vulnerabilidades recentemente divulgadas que poderiam ser usadas contra esses appliances. Depois de obter controle do dispositivo, o operador cria uma conta local com aparência genérica, ajusta políticas de firewall e mantém verificações periódicas de disponibilidade. Esse comportamento é compatível com preservação de acesso inicial, inclusive em cenários nos quais um intermediário prepara o ambiente para repasse a outro grupo criminoso.

A etapa mais sensível ocorre quando o arquivo de configuração do FortiGate é extraído. Esse tipo de arquivo pode conter credenciais criptografadas de contas de serviço vinculadas a LDAP ou AD. No incidente descrito, houve evidência de autenticação no AD com credenciais em texto claro da conta de serviço fortidcagent, o que indica que o arquivo de configuração foi decifrado ou processado pelo invasor para recuperar o segredo operacional. Com a conta válida, o operador autenticou-se no ambiente e ingressou estáções de trabalho não autorizadas no Active Directory, ampliando o grau de presença antes de iniciar varredura de rede. A detecção nesse ponto impediu movimentação lateral adicional.

O segundo fluxo teve progressão mais rápida após o acesso ao firewall. O operador implantou ferramentas legítimas de administração remota, incluindo Pulseway e MeshAgent, em uma sequência que favorece persistência interativa e controle operacional. Em seguida, um malware Java foi baixado de um bucket de armazenamento em nuvem associado à AWS e executado por DLL side-loading. A carga foi usada para coletar e enviar o arquivo NTDS.dit e o hive de registro SYSTEM a um servidor externo pela porta 443. O contexto não confirma uso posterior das credenciais que poderiam ser derivadas desses artefatos, nem confirma implantação de payload final de ransomware.

Superfície afetada

A superfície de risco concentra-se em FortiGate NGFW que mantêm integração com diretórios corporativos, especialmente quando contas de serviço possuem permissões suficientes para consultar atributos de usuários, mapear grupos e apoiar políticas baseadas em função. Esse desenho é comum porque melhora a aplicação de políticas e a velocidade de correlação em alertas de segurança, mas também cria uma dependência crítica: o dispositivo de borda passa a guardar material que pode ser reaproveitado contra o plano de identidade. O risco aumenta quando a administração local permite criação de contas sem validação adequada, quando políticas de firewall são alteradas sem revisão independente e quando logs ficam retidos apenas no próprio appliance.

Ambientes de provedores de serviços gerenciados exigem atenção adicional porque um appliance comprometido pode representar acesso a redes de clientes ou a segmentos administrativos compartilhados. Em saúde e governo, a criticidade se amplia pela presença de sistemas legados, janelas de manutenção restritas e contas de serviço antigas que frequentemente acumulam permissões. A falta de logs suficientes nos firewalls foi um ponto comum nos casos, impedindo reconstrução precisa do momento e do método de acesso inicial.

• FortiGate NGFW integrado a Active Directory ou LDAP com credenciais de contas de serviço em configuração local.
• Contas locais administrativas recém-criadas, especialmente nomes genéricos como support, quando não houver solicitação formal associada.
• Políticas de firewall novas ou alteradas que liberem trânsito amplo entre zonas internas e externas.
• Domínios AD nos quais estáções desconhecidas foram ingressadas após autenticação por conta de serviço.
• Ambientes com retenção curta de logs no appliance e sem encaminhamento integral para SIEM.

Hunting e telemetria

A investigação defensiva deve começar pelo plano de gerenciamento do FortiGate. Alterações de contas locais, mudanças em políticas, exportações de configuração, autenticações administrativas incomuns e intervalos de acesso repetitivo ao dispositivo são sinais relevantes. Como o contexto indica que os invasores podem apagar rastros locais ou atuar em ambientes com baixa retenção, a ausência de logs no firewall não deve encerrar a investigação. O SIEM, servidores de diretório, controladores de domínio, EDR e registros de ferramentas de administração remota podem preservar parte do encadeamento.

No Active Directory, a prioridade é correlacionar autenticações da conta fortidcagent ou de outras contas de serviço usadas pelo FortiGate com eventos de ingresso de máquinas, consultas incomuns, criação de objetos e acessos fora do padrão. A presença de estáções recém-adicionadas ao domínio por contas que normalmente apenas consultam LDAP é um desvio forte. Para o segundo fluxo, a telemetria de endpoint deve procurar instalação ou execução de Pulseway e MeshAgent fora do inventário aprovado, execução de Java em contexto anômalo, DLL side-loading, acesso a NTDS.dit, leitura do hive SYSTEM e conexões de saída pela porta 443 para infraestrutura não reconhecida.

• Criação da conta local support em FortiGate ou de qualquer administrador local não vinculado a mudança aprovada.
• Quatro ou mais políticas de firewall criadas em sequência com permissão ampla entre zonas.
• Exportação, leitura ou transferência de arquivo de configuração do appliance em horário ou origem incomum.
• Autenticação LDAP/AD com conta de serviço do FortiGate seguida por ingresso de estáções no domínio.
• Execução de Pulseway, MeshAgent ou Java em servidores e estáções onde essas ferramentas não fazem parte do padrão operacional.
• Acesso ao arquivo NTDS.dit e ao hive SYSTEM, seguido de tráfego TLS para destino externo defangado 172.67.196[.]232 pela porta 443.

Mitigação

A resposta deve tratar o FortiGate como ativo de identidade indireto, não apenas como firewall. O primeiro passo é preservar e centralizar logs disponíveis antes de qualquer alteração que possa sobrescrever evidências. Em seguida, administradores devem revisar contas locais, sessões administrativas, políticas criadas desde novembro de 2025 nos ambientes comparáveis ao incidente e qualquer exportação de configuração. Quando houver suspeita de extração do arquivo de configuração, as credenciais de contas LDAP/AD usadas pelo appliance precisam ser rotacionadas, e suas permissões devem ser reduzidas ao mínimo necessário.

A contenção no AD deve incluir validação de computadores ingressados recentemente, remoção ou isolamento de estáções não reconhecidas, revisão de grupos privilegiados e análise de autenticações da conta de serviço em controladores de domínio. Onde NTDS.dit ou SYSTEM foram acessados, a resposta deve assumir risco de tentativa de quebra offline de credenciais, mesmo que o contexto não confirme uso posterior. Isso justifica rotação priorizada de contas privilegiadas, reforço de controles de autenticação e busca por sinais de uso indevido após a janela de coleta.

Para reduzir recorrência, a organização deve aplicar correções de segurança do FortiGate conforme orientação do fornecedor, eliminar credenciais fracas, restringir o plano de gerenciamento a redes administrativas, exigir MFA quando suportado e manter logs do appliance por pelo menos 14 dias com envio integral ao SIEM. A retenção local isolada é insuficiente quando o próprio dispositivo pode ser controlado pelo invasor. O monitoramento deve considerar alterações de configuração, exportações, falhas e sucessos administrativos, além de eventos de integração LDAP, porque a transição entre borda e identidade é o ponto que torna esse tipo de intrusão mais perigoso.

• Rotacionar credenciais LDAP/AD armazenadas ou usadas pelo FortiGate após qualquer suspeita de exportação de configuração.
• Remover contas administrativas locais não autorizadas e revisar políticas de firewall que permitam trânsito irrestrito entre zonas.
• Aplicar atualizações relacionadas às vulnerabilidades citadas quando aplicável ao ambiente e validar exposição do plano de gerenciamento.
• Encaminhar logs do FortiGate para SIEM e manter retenção mínima de 14 dias, com alerta para exclusão ou queda de envio de logs.
• Auditar ingresso recente de estáções no AD por contas de serviço e isolar objetos desconhecidos até conclusão da análise.
• Investigar presença de Pulseway, MeshAgent, Java anômalo, DLL side-loading e acesso a NTDS.dit ou SYSTEM em endpoints e servidores.