PivotC2 & CVE-2025-25249

01Sumário executivo

Este relatório perfila a exploração ativa de CVE-2025-25249, um estouro de buffer baseado em heap no daemon cw_acd do FortiOS e do FortiSwitchManager, e o implante que ela entrega, chamado PivotC2. A falha foi divulgada e corrigida pela Fortinet em 13 de janeiro de 2026 [2] [3]. A exploração na prática foi identificada pela unidade de pesquisa da SOCRadar e remonta a pelo menos julho de 2026, seguindo em curso [1].

A exploração não exige autenticação, não exige interação de usuário e alcança o equipamento por um único pacote UDP na porta 5246, usada pelo protocolo CAPWAP para gerenciar pontos de acesso sem fio [1] [2]. O implante entregue em seguida roda sobre o Node.js que já acompanha o FortiOS, ou seja, o operador não precisa gravar binário novo no aparelho.

A campanha não é um teste de laboratório: a lista de alvos recuperada com o atacante soma mais de 30.000 endereços IP de FortiGate, dos quais 178 foram confirmadamente explorados e infectados, com concentração nos Estados Unidos, seguidos de Chile, Colômbia e Reino Unido [1]. Em 9 de setembro de 2026 a CISA incluiu a falha no catálogo de vulnerabilidades exploradas conhecidas, com prazo de correção em 12 de setembro de 2026 e exigência de triagem forense [4].

As recomendações estão organizadas em duas frentes que não se substituem. A seção 10 trata de caça, porque o equipamento já corrigido pode continuar infectado. A seção 11 trata de correção, redução de exposição e rotação de credenciais, nessa ordem, porque a rotação é a única medida que endereça o dano já consumado.

02Identificação do objeto analisado

03A falha: estouro de heap no daemon cw_acd

O CAPWAP (Control and Provisioning of Wireless Access Points) é o protocolo que a Fortinet usa para que um FortiGate gerencie centralmente pontos de acesso sem fio. O daemon cw_acd escuta o tráfego de controle desse protocolo na porta UDP 5246 [1]. O ponto que torna a falha grave não é a sofisticação da corrupção de memória, mas a exposição: esse serviço fica ativo em interfaces que tenham o serviço fabric habilitado, inclusive as voltadas para a internet, e responde antes de qualquer autenticação.

A Fortinet publicou o aviso e as correções em 13 de janeiro de 2026. As versões afetadas e as versões corrigidas são as seguintes [2] [6]:

04Cadeia de exploração

4.1A ferramenta de exploração

O ataque começa por um binário chamado fortirun.bin, um ELF Linux x86-64 auto-extraível de dois estágios [1]. Ao rodar, ele descomprime da própria seção .rodata um bloco em ZStandard que desempacota 18 artefatos, entre eles um interpretador CPython completo e um segundo binário interno, também chamado fortirun.bin. Esse binário interno carrega dois módulos Python compilados, fortipwn.py e fortirun.py. Scripts em Bash e Python envolvem tudo isso num laço de tentativas repetidas, recebendo como argumentos o IP do FortiGate alvo, a porta CAPWAP, o IP e a porta do ouvinte do atacante, tempos limite e a carga final codificada em Base64 [1].

4.2Da descoberta à execução de código

O módulo fortipwn.py executa a exploração propriamente dita, em quatro passos encadeados [1]:

Identificação e derrota do ASLR

O exploit envia pacotes CAPWAP Discovery Request com endereço MAC aleatório. A resposta do controlador devolve os campos hw_rev e sw_ver, por exemplo FGT60F-v7.4-build2731, consultados numa tabela interna de compatibilidade. Como a mesma resposta vaza ponteiros de memória vivos, o exploit calcula em tempo de execução as bases image_base e data_rw_base, ou seja, a aleatorização de endereços (ASLR) deixa de proteger.

Preparação do heap

O daemon usa uma piscina de memória pré-alocada chamada free_list_mp2, uma lista duplamente encadeada de blocos de tamanho fixo. O exploit envia em laço mensagens CAPWAP Add Station com 56 bytes do caractere A, forçando alocações de 72 bytes que preenchem as lacunas da piscina até que o buffer controlado pelo atacante fique imediatamente antes do nó alvo.

Estouro e corrupção

Uma mensagem CAPWAP Image Data declara nos campos me_type e me_sz um tamanho menor do que o realmente escrito. O daemon copia o excedente, e 16 bytes passam do fim do buffer de 56 bytes, sobrescrevendo os ponteiros fd e bk do nó vizinho.

Escrita arbitrária e desvio do fluxo

Com os dois ponteiros sob controle, a operação de desencadeamento da lista vira uma primitiva de escrita em endereço arbitrário, no estilo safe unlink. Como a proteção W^X impede injetar código no heap, o exploit encadeia um gadget ARM64 terminado em br x16 para desviar a execução até execvp.

4.3Do shell reverso ao implante

A chamada sequestrada de execvp abre um shell reverso em Node.js, que já existe no plano de gerência do FortiOS, e por isso nada precisa ser instalado no aparelho [1]. O módulo fortirun.py então injeta a carga Base64 diretamente no REPL interativo do Node (node -i), acrescenta um marcador de conclusão formado por __FORTIPWN_DONE__ mais 16 caracteres hexadecimais aleatórios, e lê a saída até encontrar esse marcador.

A carga injetada é um estágio intermediário de uma linha só, que se comporta assim [1]:

• baixa o próximo estágio de hxxps[://]146[.]103[.]99[.]177:8443/0c5b76709523;
• decodifica os blocos recebidos em Base64;
• decifra cada byte por XOR com a chave pivot;
• grava o resultado em /tmp/.i.js;
• executa esse arquivo como processo de segundo plano, que sobrevive ao término do processo Node original.

05PivotC2: arquitetura e protocolo

O PivotC2 adota a arquitetura clássica de shell reverso: o cliente é quem sempre inicia a conexão de saída para o servidor de comando e controle, contornando qualquer regra de entrada do firewall [1]. Toda a comunicação viaja por um único soquete TLS, sobre o qual um protocolo binário leve multiplexa canais nomeados, numa estrutura que lembra o modelo de canais do SSH.

Cada quadro começa com um inteiro de 4 bytes sem sinal em ordem big-endian, indicando o tamanho total da carga, seguido de 1 byte de tipo de mensagem e da carga em si. Todos os tipos, exceto CHANNEL_DATA, carregam um objeto JSON em UTF-8. O CHANNEL_DATA antepõe 4 bytes de identificador de canal a dados binários crus [1].

5.1Tipos de mensagem

5.2Resiliência da sessão

O cliente é escrito para não morrer. Um manipulador global de uncaughtException engole erros inesperados, e a queda da conexão TLS aciona um laço de reconexão com recuo exponencial e variação aleatória [1]. Por padrão o cliente envia um HEARTBEAT a cada 30 segundos, ajustável pelo comando sleep. Do outro lado, o servidor varre as sessões a cada 15 segundos e encerra as que ficam 90 segundos sem sinal.

06Capacidades no dispositivo comprometido

6.1Comandos aceitos pelo cliente

Operações curtas rodam de forma síncrona e devolvem um resultado em Base64. Operações longas ou interativas abrem um canal dedicado. Os comandos recuperados são estes [1]:

6.2Canais

Sobre a mesma conexão TLS trafegam canais independentes e bidirecionais, cada um com identificador de 32 bits [1]:

6.3O firewall como ponto de pivô

O nome da ferramenta descreve a intenção. Quando o operador sobe um proxy SOCKS5 no servidor de C2, cada conexão recebida vira um canal direct e o cliente executa net.connect na rede interna da vítima [1]. Ferramentas comuns de linha de comando passam a enxergar a rede protegida como se estivessem dentro dela, sem sobrecarga adicional de tunelamento e sem qualquer regra de entrada nova no firewall.

O console do operador oferece, além dos comandos do cliente, controle de serviços de rede [1]:

07Coleta de configuração e decifragem de credenciais

Esta é a capacidade que define a campanha. Combinando o comando harvest no cliente com o comando creds no console, o operador despeja num diretório de coleta os arquivos que guardam a configuração e o segredo do aparelho [1]. Os arquivos coletados são estes:

7.1Os dois esquemas de decifragem

Comentários no código apontam para um módulo fortidecrypt.js, não recuperado, que identifica e decifra os campos ENC por dois caminhos distintos [1]:

AES-256-CBC com chave fixa embutida no código

Os campos cifrados assim carregam um rastro conhecido, Yf267vE@, que serve de gatilho para a detecção automática. Esse caminho decifra sem nenhum acesso ao segredo do aparelho, e a técnica já era pública antes desta campanha [5].

AES-128-GCM com chave derivada do arquivo do aparelho

Os campos sem aquele rastro caem neste segundo caminho, que exige ter coletado também o fsv_sync.dat.

08Modo automático: pós-exploração sem operador

O servidor de C2 aceita uma opção de modo automático. Ligada, cada nova conexão de vítima dispara sozinha um encadeamento de cinco etapas, sem nenhuma intervenção humana [1].

Registro

O aperto de mão HELLO registra a telemetria da vítima.

Coleta

Os comandos harvest e creds recolhem a configuração global, a do VDOM e o arquivo fsv_sync.dat.

Decifragem

O servidor decifra as credenciais armazenadas.

Extração de topologia

Um módulo forticonfig.js extrai as redes internas do arquivo de interfaces.

Varredura

Varreduras em segundo plano batem nas portas 22, 80, 389, 443, 445, 902, 1433, 3389 e 5432, tanto nas sub-redes recém-descobertas quanto em faixas internas predefinidas.

As faixas internas fixas usadas na varredura automática são estas [1]:

• 10.0.0.0/24 e 10.0.1.0/24;
• 172.16.0.0/24;
• 192.168.0.0/24 e 192.168.1.0/24.

09Alcance da campanha e perfil do operador

A análise dos arquivos do atacante revelou uma lista de mais de 30.000 endereços IP de FortiGate como alvos, dos quais 178 foram confirmados como explorados e infectados com PivotC2 [1]. Cada sessão de vítima registrava metadados da infecção, incluindo identificador de sessão, nome do equipamento, arquitetura, versão do Node.js, endereço e porta da vítima e tempo desde a infecção. A distribuição geográfica mostra maior concentração nos Estados Unidos, seguidos de Chile, Colômbia e Reino Unido.

Em dois alvos nos Estados Unidos o comprometimento passou do firewall. A fonte descreve o ciclo completo: exploração da falha, implante do PivotC2, abertura de túneis internos, descoberta de hosts, extração de credenciais de navegador, movimentação lateral e exfiltração de dados [1]. As saídas das ferramentas recuperadas mostram uso intenso de assistentes de inteligência artificial em várias etapas da intrusão, inclusive na geração automática dos relatórios de saída de comando. O próprio implante traz comentários e instruções de uso detalhados, o que sustenta a avaliação de que a inteligência artificial participou do desenvolvimento.

As ferramentas adicionais recuperadas dessas duas intrusões são estas [1]:

10Detecção

A caça vai do mais barato e abrangente para o mais caro e específico. As três primeiras vias não exigem tocar no equipamento suspeito, o que importa quando o equipamento suspeito é o próprio firewall de borda.

10.1Superfície exposta

Antes de caçar infecção, inventarie exposição. Levante quais interfaces externas têm o serviço fabric habilitado e se há tráfego chegando às portas de controle CAPWAP.

# em cada interface externa, confira se "fabric" aparece na lista
show system interface | grep -f allowaccess

# escuta por trafego CAPWAP de controle chegando na borda
diagnose sniffer packet any 'udp port 5246' 4 20

10.2Registros de fluxo e proxy

O implante mantém uma conexão TLS de saída persistente a partir do próprio firewall. Procure no NetFlow ou nos registros de sessão qualquer conexão originada no endereço de gerência do FortiGate para as portas 8443 ou 9443 de destinos externos.

index=netflow src_ip IN (lista_de_firewalls)
| search dest_port IN (8443, 9443)
| stats count, sum(bytes) AS total BY src_ip, dest_ip, dest_port
| sort - total

CommonSecurityLog
| where DestinationIP in ("146.103.99.177", "46.151.29.58")
     or (SourceIP in (FirewallMgmtIPs) and DestinationPort in (8443, 9443))
| summarize Sessoes=count(), Bytes=sum(SentBytes) by SourceIP, DestinationIP
| order by Sessoes desc

10.3IDS e IPS

Duas regras cobrem lados diferentes do problema: a primeira vê a tentativa de exploração, a segunda vê o download do estágio.

# 1. Descoberta CAPWAP vinda de fora da rede, precursora da exploracao
alert udp $EXTERNAL_NET any -> $HOME_NET 5246 (
  msg:"CIBERLAB CAPWAP CONTROL EXTERNO POSSIVEL CVE-2025-25249";
  classtype:attempted-admin; priority:1;
  sid:9000101; rev:2;
)

# 2. Download do estagio PivotC2 pelo caminho derivado do hash do cliente
alert http $HOME_NET any -> $EXTERNAL_NET any (
  msg:"CIBERLAB PIVOTC2 DOWNLOAD DE ESTAGIO";
  http.uri; content:"/0c5b76709523"; startswith;
  classtype:trojan-activity; priority:1;
  sid:9000102; rev:2;
)

10.4Regra Sigma para a exposição CAPWAP

A regra abaixo expressa, de forma portável para o backend de SIEM da instituição, a chegada de tráfego CAPWAP de controle a partir de fora da rede, que é o precursor observável da exploração antes de qualquer implante.

title: Trafego CAPWAP de controle vindo da internet para FortiGate
id: 4e9d2f70-6a1c-4b83-9e52-1d8c7a06b4f9
status: experimental
description: >
  O daemon cw_acd escuta CAPWAP Control em UDP 5246 e e explorado por
  CVE-2025-25249 sem autenticacao. Trafego para essa porta a partir de
  origem externa, na interface de borda, e o precursor da exploracao e nao
  deveria existir num plano de gerencia corretamente fechado.
references:
  - https://socradar.io/blog/cve-2025-25249-pivotc2-fortigate-rat/
  - https://fortiguard.fortinet.com/psirt/FG-IR-25-084
author: CiberLab, Ciencia Embarcada
date: 2026/09/09
tags:
  - attack.initial-access
  - attack.t1190
logsource:
  category: firewall
detection:
  capwap_externo:
    dst_port: 5246
    protocol: udp
    direction: inbound
  origem_externa:
    src_ip|cidr:
      - '0.0.0.0/0'
  origem_interna:
    src_ip|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: capwap_externo and origem_externa and not origem_interna
falsepositives:
  - Controlador CAPWAP legitimo gerenciando APs por WAN, se existir: aliste
    o endereco do controlador em origem_interna
level: high

10.5Regra YARA para o cliente PivotC2

Aplicável a captura de rede decifrada, a amostras recuperadas do próprio appliance ou ao conteúdo de /tmp/.i.js, e não a uma varredura de disco de estação Windows, pelo motivo da seção 12.3. A regra combina os marcadores de protocolo e as cadeias operacionais que a fonte documenta no cliente.

rule PivotC2_Node_Client
{
    meta:
        description = "Cliente PivotC2 em JavaScript, implante de CVE-2025-25249"
        author      = "CiberLab, Ciencia Embarcada"
        date        = "2026-09-09"
        reference   = "https://socradar.io/blog/cve-2025-25249-pivotc2-fortigate-rat/"
        confidence  = "derivada de OSINT, sem validacao contra amostra"
        tlp         = "TLP:CLEAR"

    strings:
        // Marcador de conclusao injetado pelo exploit no REPL do Node [1]
        $done   = "__FORTIPWN_DONE__" ascii

        // Artefato do estagio em disco [1]
        $drop   = "/tmp/.i.js" ascii

        // Nomes de tipo de mensagem do protocolo proprio [1]
        $p1     = "HELLO_ACK" ascii
        $p2     = "CHANNEL_OPEN_ACK" ascii
        $p3     = "TASK_RESULT" ascii

        // Comandos e canais caracteristicos [1]
        $c1     = "harvest" ascii
        $c2     = "stop_listen" ascii
        $c3     = "fsv_sync.dat" ascii

        // Chave XOR do estagio intermediario [1]
        $xor    = "pivot" ascii

    condition:
        // O marcador do exploit sozinho ja e forte; senao, exige um conjunto
        // de indicadores de protocolo e operacao para evitar falso positivo
        $done
        or ($drop and 2 of ($p*))
        or (3 of ($p*, $c*) and $xor)
}

10.6Inspeção do equipamento

Havendo suspeita, inspecione o FortiGate pela linha de comando do FortiOS [1]:

# sessoes ativas para os enderecos de C2 conhecidos
diagnose sys session filter daddr 146.103.99.177
diagnose sys session list
diagnose sys session filter daddr 46.151.29.58
diagnose sys session list

# artefato do implante em disco
fnsysctl ls -la /tmp/.i.js
fnsysctl ls -la /tmp/

# execucao suspeita de Node.js
diagnose sys process list | grep node

11Mitigação e resposta

11.1Contenção imediata

• Feche a porta na borda, antes de qualquer outra coisa, porque é a única ação que interrompe novas explorações em minutos. Remova o serviço fabric das interfaces externas ou aplique uma política local-in descartando UDP de entrada nas portas 5246 a 5249 [1] [3].
• Isole o equipamento suspeito do restante da rede de gerência caso a seção 10 tenha encontrado indício, mantendo os registros para triagem.
• Bloqueie os endereços de C2 listados na seção 12 na saída, e busque retroativamente conexões passadas para eles.

11.2Erradicação

• Atualize para as versões corrigidas da tabela da seção 03.
• Reconstrua o aparelho a partir de estado sabidamente íntegro sempre que houver artefato confirmado. Corrigir fecha a via de entrada, mas não remove implante já em execução nem devolve as credenciais já coletadas.
• Gire todas as credenciais guardadas na configuração, sem exceção: senhas administrativas, contas de SSL-VPN, segredos de vínculo LDAP, chaves de rede sem fio e chaves pré-compartilhadas de IPsec [1].

11.3Avaliação de alcance

Trate o firewall como ponto de pivô, não como destino final. Procure na rede interna as marcas descritas na seção 09: alterações de registro que reabilitam RDP, relés de SSH reverso, acesso a credenciais salvas em navegador e transferências de saída para armazenamento em nuvem. As faixas da seção 08 indicam onde a varredura automática bateu primeiro.

11.4Prevenção estrutural

11.5Mapeamento MITRE ATT&CK

As técnicas abaixo foram conferidas uma a uma em attack.mitre.org, e os nomes reproduzem o oficial de cada página. A primeira tabela cobre do desenvolvimento de capacidade à evasão de defesas:

A segunda tabela cobre descoberta, movimentação lateral e coleta:

A terceira tabela cobre comando e controle e exfiltração:

12Indicadores de comprometimento

Todos os indicadores abaixo vêm da fonte primária [1], porque não houve análise local. As URLs e endereços aparecem desarmados de propósito, e não devem ser transformados em link clicável.

12.1Rede

12.2Artefatos em disco e em memória

12.3Hashes do exploit e dos estágios

13Limitações da análise

• Não houve detonação nem análise de amostra. Esta equipe não obteve o fortirun.bin nem o cliente PivotC2. Todo o conteúdo técnico vem das referências, e nenhuma afirmação aqui equivale a observação própria.
• As regras Suricata, Sigma e YARA das seções 10.3 a 10.5 são derivadas, não validadas. Foram escritas a partir dos indicadores e do comportamento descritos na fonte, sem execução do exploit nem teste contra o cliente. A regra YARA, em particular, nunca foi aplicada a uma amostra real do PivotC2, e a condição de múltiplos indicadores existe para reduzir o risco de alerta por um único nome comum.
• O módulo fortidecrypt.js, que faz a decifragem das credenciais, não foi recuperado pela fonte primária. Sua existência e comportamento são inferidos de comentários no código, e o detalhe do esquema AES-256-CBC vem de pesquisa independente anterior [5], não desta campanha.
• A versão recuperada do implante é a 0.2.3, descrita pela fonte como fase inicial de desenvolvimento [1]. Capacidades presentes em versões mais recentes, e indicadores gerados por elas, estão fora deste relatório.
• O número de 178 dispositivos infectados vem dos arquivos recuperados com o atacante e representa o que aqueles arquivos registravam, não um censo da campanha. O total real é igual ou maior.
• Nenhuma vítima brasileira foi citada pela fonte. Isso não é evidência de ausência, apenas ausência de evidência na amostra analisada.
• A pontuação CVSS aparece com três valores diferentes entre as fontes consultadas. A divergência está registrada na seção 02 e não foi resolvida, apenas atribuída.
• O aviso da Fortinet [3] não pôde ser lido diretamente, porque o portal exige verificação interativa de navegador. As versões afetadas foram conferidas no NVD [2] e as versões corrigidas em fonte de terceiro [6].
• A atribuição a operador de língua russa é da fonte primária. Este relatório não a confirma nem nomeia grupo.