Da webshell ao root

01Sumário executivo

Em 25 de outubro de 2026, pesquisadores da Dream encontraram artefatos de uma campanha que comprometeu 25 servidores nos Estados Unidos, no Japão, em Taiwan e na Coreia do Sul: 24 firewalls e um servidor interno de gerenciamento de firewalls [1] [6]. Os artefatos incluíam o exploit, listas de alvos, registros de exploração e cerca de 40 scripts de pós-exploração [1] [5]. A Unit 42, da Palo Alto Networks, confirmou de forma independente as ferramentas e os resultados e rastreia a atividade como CL-UNK-1280 [1] [2].

A campanha seguiu um funil: cerca de 19.000 firewalls encontrados no buscador FOFA, cerca de 5.000 que responderam à identificação de versão e 240 alvos filtrados por país e versão vulnerável [1] [6]. A exploração em lote comprometeu 24 firewalls; 22 ficaram "estacionados", com webshell e sem outra ação, e dois foram priorizados [1]. Num deles, o operador abriu um túnel SSH reverso para a rede interna, comprometeu o servidor de gerenciamento com a mesma cadeia menos de 90 minutos depois e partiu para o Active Directory [1].

A CISA incluiu o Fragnesia no catálogo KEV em 28 de outubro, com prazo de 31 de outubro e exigência de triagem forense, e afirmou que a falha "pode ser encadeada com a CVE-2026-109618 e a CVE-2026-109619 para implantar webshells PHP e executar comandos como root" [4] [5].

As ações são três: atualize o PHP e o kernel, ou o firmware dos appliances que os embutem; tire interfaces de gerenciamento da internet; e, em qualquer equipamento que tenha ficado exposto, faça triagem forense antes de reiniciar, porque o reinício apaga a principal evidência da escalada [1] [3] [4].

02Identificação do objeto analisado

03Contexto técnico: Fragnesia e o cache de páginas

3.1O cache de páginas

Quando um programa lê um arquivo, o kernel Linux guarda o conteúdo em memória, no cache de páginas, para que as próximas leituras não precisem ir ao disco [3] [4]. Todo processo que abre o mesmo arquivo vê essa cópia em memória. Se alguém consegue escrever nela, muda o que o sistema enxerga como conteúdo do arquivo, mesmo que o arquivo seja somente leitura e o disco continue intacto [3] [4].

3.2A falha

O Fragnesia foi divulgado em 13 de maio de 2026 por William Bowling, da V12 Security, com prova de conceito pública e correção no kernel [3]. Quando a função skb_try_coalesce() junta fragmentos de pacotes de rede, ela deixa de propagar a marca SKBFL_SHARED_FRAG, que indica páginas compartilhadas com outros subsistemas [3] [4]. Sem a marca, páginas que pertencem ao cache de arquivos passam a ser tratadas como graváveis. O caminho ESP-in-TCP do IPsec então decifra esses fragmentos no lugar, e grava sobre o cache de um arquivo somente leitura os bytes do fluxo de cifra AES-GCM que o atacante escolheu, 192 bytes por vez [3] [4].

A exploração não depende de corrida [3]. Exige acesso local sem privilégio e usa namespaces de usuário e de rede, ligados por padrão na maioria das distribuições, para obter CAP_NET_ADMIN sem privilégio no host; exige também que os módulos ESP estejam disponíveis [3]. A prova de conceito pública reescreve /usr/bin/su em memória [3] [4].

3.3A família Dirty Frag

O Fragnesia pertence à mesma classe do Dirty Frag (CVE-2026-43284 e CVE-2026-43500), que também escreve no cache de páginas pelo caminho XFRM e ESP, com outro ponto de entrada [3] [5]. As correções do Dirty Frag não corrigem o Fragnesia; quem só aplicou aqueles patches continua vulnerável, enquanto quem bloqueou os módulos esp4, esp6 e rxrpc para o Dirty Frag já está protegido [3] [4].

A correção é o commit f84eca581739, "net: skbuff: preserve shared-frag marker during coalescing", integrado em 21 de maio [4]. Ubuntu 20.04 e anteriores com kernel padrão não são afetados, e o Amazon Linux também não, porque não traz o módulo espintcp [3] [4].

04Cadeia de ataque

4.1Linha do tempo

4.2Reconhecimento e seleção

O operador usou o FOFA, um buscador chinês de ativos expostos na internet, para encontrar cerca de 19.000 dispositivos PAN-OS [1]. Um varredor próprio com 200 threads identificou cerca de 5.000 dispositivos ativos e suas versões, e um filtro por país e versão vulnerável reduziu a lista a 240 alvos [1] [6].

4.3Acesso inicial: PHP2Shell

A versão do exploit era própria e não pública, e mirava o mecanismo session.upload_progress do servidor web de gerenciamento do firewall, o appweb [1] [6]. Ela tinha quatro estágios [6]:

1. Requisições multipart construídas para esgotar a memória e moldar o alocador do PHP.
2. Um vazamento de informação expunha, no cabeçalho Set-Cookie, um ponteiro da libphp.so, usado para calcular endereços.
3. Nova pressão de memória criava uma referência obsoleta; uma entrada forjada de tabela de dispersão desviava uma rotina de limpeza para system().
4. O comando rodava como nobody, e a última requisição disparava o Fragnesia.

4.4Escalada: Fragnesia

Com a escrita no cache de páginas, o operador sobrescreveu /etc/pam.d/su para usar pam_permit.so, o módulo PAM que aprova qualquer autenticação, e passou a obter root com su sem senha [1] [4]. O exploit público funciona em kernels anteriores a 13 de maio de 2026 [5]; o sucesso da escalada em 25 equipamentos indica, por inferência, que eles rodavam kernel sem a correção.

4.5Exploração em lote e triagem

Um executor em lote atacava cinco alvos por vez, com 30 minutos de limite por alvo; cada sucesso recebia uma webshell, uma verificação de root com id e uma linha no registro [1]. Foram 24 firewalls com root e webshells PHP de 103 bytes [1] [6]. O operador deixou 22 deles parados e se concentrou em dois, ligados por dados de certificado à mesma organização afiliada ao governo dos EUA [1].

05Pós-exploração e movimento lateral

5.1Persistência e túnel

No firewall priorizado, o operador montou um túnel SSH reverso de oito portas até a sua infraestrutura, com um serviço systemd e um gancho em rc.local que sobrevivem a reinícios e reconectam sozinhos [1]. Os scripts do túnel ficavam em /usr/local/lib/.panops/ [1]. O túnel encaminhava acesso aos controladores de domínio (LDAP, LDAPS e RDP), ao servidor interno de gerenciamento, à infraestrutura de VPN GlobalProtect e a um proxy SOCKS5 [1]. A partir do servidor de gerenciamento, o operador atacou o Active Directory; a tabela 5 separa o que a Dream confirmou do que não pôde determinar [1].

5.2Credenciais e Active Directory

O operador também coletou do sistema de arquivos dos firewalls as chaves de replicação de alta disponibilidade, as chaves privadas TLS e as chaves de autenticação do dispositivo; o provedor SAML estava configurado com validate-idp-certificate: no [1].

06Atribuição e o papel da inteligência artificial

Os indícios de origem são prompts em chinês, carimbos de tempo em UTC+8, acesso ao FOFA com chaves de API e os modelos DeepSeek e Kimi configurados na infraestrutura do operador [1] [6]. A Dream não atribui a operação a um ator nomeado [1] [6].

Na infraestrutura de ataque havia ferramentas de IA: a plataforma ofensiva aiscan, configurada com DeepSeek e Kimi, e o Claude Code [1]. A Dream considera provável que a pós-exploração tenha sido assistida por IA, pela consistência dos scripts, mas declara não ter evidência direta de que IA escreveu o exploit ou os scripts e não descreve a operação como autônoma [1] [6]. A ferramenta de túnel iox, de origem chinesa, completava o conjunto [1].

07Detecção

A ordem vai do mais barato e abrangente ao mais caro e específico: rede, registros web, arquivos no equipamento e, por fim, identidade.

7.1Rede

Procure sessões SSH de saída persistentes a partir de firewalls e portas encaminhadas para LDAP, RDP e serviços de gerenciamento internos [1]. Um firewall não tem motivo para abrir SSH de saída para a internet.

7.2Registros web

Revise os registros da interface de gerenciamento em busca de rajadas de POST multipart com nomes de arquivo muito grandes e campos de progresso de sessão, e de valores anormais de Set-Cookie [1]. Os sinais detalhados do PHP2Shell estão na seção 7 do relatório PHP2Shell.

7.3Arquivos no equipamento

As verificações abaixo cobrem os artefatos documentados pela Dream [1] [4]. Rode antes de qualquer reinício:

# Webshell da campanha e PHP inesperado em diretorios publicos
ls -la /unauth/php/change_password.php
find / -xdev -name '*.php' -newermt '2026-10-08' 2>/dev/null

# PAM reescrito em memoria: compare o que o sistema le
# com o que esta no disco (o cache some no reinicio)
grep -n pam_permit /etc/pam.d/su

# Persistencia do tunel
ls -la /usr/local/lib/.panops/
systemctl list-unit-files --state=enabled
cat /etc/rc.local

Qualquer entrada pam_permit em /etc/pam.d/su é sinal de alerta [1]. Como o Fragnesia altera só o cache, o arquivo pode parecer normal depois de um reinício ou de uma limpeza do cache; registre o conteúdo lido antes [4].

7.4Identidade

Revise os registros do firewall e do servidor de gerenciamento em busca de grande volume de consultas LDAP e de falhas de login em muitas contas, padrão de pulverização [1]. No Active Directory, procure usuários e contas de máquina criados a partir de 24 de outubro.

7.5Regra Sigma para o PAM

title: Configuracao PAM do su apontando para pam_permit
id: 9b1e4c77-2f3a-4d58-8e06-6a2c5d0f13b4
status: experimental
description: Alteracao de /etc/pam.d/su usada na escalada do Fragnesia
    (CVE-2026-46300) apos o PHP2Shell
author: CiberLab (Ciência Embarcada)
references:
    - https://dreamgroup.com/blog/chained-php2shell-exploit-roots-25-servers
logsource:
    product: linux
    category: file_event
detection:
    selection:
        TargetFilename: '/etc/pam.d/su'
    condition: selection
falsepositives:
    - Atualizacao legitima de pacotes PAM
level: high
tags:
    - attack.persistence
    - attack.t1556.003
    - cve.2026-46300

Esta regra só vê alterações gravadas pelo caminho normal de arquivos. A escrita do Fragnesia no cache de páginas não passa por esse caminho e pode não gerar o evento; trate a regra como cobertura para variantes que gravem em disco, e não como detecção do Fragnesia [3] [4].

08Mitigação e resposta a incidentes

8.1Contenção

Tire da internet as interfaces de gerenciamento do PAN-OS e os portais GlobalProtect onde for possível, e restrinja o acesso de gerenciamento a IPs internos confiáveis [1] [2]. Bloqueie SSH de saída a partir dos firewalls.

8.2Erradicação

Aplique as versões corrigidas do PAN-OS para o seu ramo, conforme o aviso do fabricante, que interrompem a cadeia observada [2]. Em servidores Linux comuns, atualize o PHP e o kernel; se o kernel não puder ser atualizado já, bloqueie os módulos esp4, esp6 e rxrpc, o que pode quebrar IPsec ou AFS no host [3]:

rmmod esp4 esp6 rxrpc
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
  > /etc/modprobe.d/dirtyfrag.conf

Trate o servidor de gerenciamento e todo firewall com webshell como comprometidos, e reconstrua a partir de imagens confiáveis [1].

8.3Avaliação de alcance e identidade

1. Gire a senha da conta de serviço LDAP, a chave mestra do dispositivo e todos os certificados e chaves de alta disponibilidade guardados nos equipamentos afetados [1].
2. Audite o Active Directory em busca de contas de usuário e de máquina não autorizadas, sobretudo de máquina [1].
3. Defina ms-DS-MachineAccountQuota como 0 e aplique política de bloqueio de conta [1].
4. Ligue a validação do certificado do provedor de identidade SAML e revise o Keycloak quanto a desvio de autenticação [1].

8.4Mapeamento de técnicas MITRE ATT&CK

IDs e nomes conferidos na base oficial do MITRE ATT&CK for Enterprise [8]; o mapeamento é do CiberLab, a partir das evidências descritas em [1]:

09Indicadores de comprometimento

A Dream não publicou IPs, domínios ou hashes e remete os indicadores de rede à Unit 42, que também não os lista publicamente [1] [2]. Os indicadores abaixo são caminhos de arquivo, artefatos e comportamentos documentados:

10Limitações da análise

1. Ausência de detonação: o CiberLab não analisou os artefatos recuperados nem executou os exploits. Toda a descrição da campanha vem da Dream [1], com confirmação da Unit 42 [2].
2. Sem indicadores de rede públicos: nenhuma fonte acessível publicou IPs, domínios ou hashes. A tabela 7 não serve como lista de bloqueio.
3. Divergência sobre o fabricante: uma cobertura registrou o nome do fabricante retido [6]; a pesquisa atualizada nomeia o PAN-OS [1], e este relatório a segue.
4. Resultado no Active Directory em aberto: a Dream não sabe se a pulverização, a criação de contas e a extração SAML tiveram sucesso [1].
5. Regras e comandos derivados: a regra Sigma e os comandos da seção 7 não foram testados em appliance.
6. Mapeamento ATT&CK próprio: a tabela 6 é leitura do CiberLab, e não da fonte.