DirtyFrag (CVE-2026-43284) - Relatório de Exercício de Detecção em Laboratório

Classificação: Laboratório Interno - CyberLAB
Data: 24 de Maio de 2026
Plataforma: Elastic Stack v9.4.1
Status: Detecção Confirmada

Índice

• A - Resumo Executivo
• B - Relatório Completo de Descobertas
  • 1. Objetivo e Modelo de Ameaça
  • 2. Contexto da Vulnerabilidade
  • 3. Ambiente de Laboratório
  • 4. Fase 1 - Configuração Pré-Execução
  • 5. Fase 2 - Execução do Exploit
  • 6. Fase 3 - Atividade Pós-Exploração
  • 7. Fase 4 - Engenharia de Detecção
  • 8. Referência de Detecção
  • 9. Resumo das Principais Descobertas
  • 10. Referências

A - Resumo Executivo

O Que Foi Testado

Um exercício controlado de exploração simulando um adversário pós-acesso inicial usando DirtyFrag (CVE-2026-43284), uma vulnerabilidade de escalada de privilégios no kernel Linux. O cenário do atacante simulado: um usuário com privilégios baixos (saskia, uid=1001) obtido via credenciais de phishing tenta escalar para root em um host Linux interno. O laboratório utilizou uma máquina Ubuntu deliberadamente vulnerável (ubuntu-vuln, kernel 6.0.0-22-generic) isolada de redes de produção.

Resultado: Exploração Bem-Sucedida - Detecção Confirmada

O atacante alcançou acesso total como root (uid=0) dentro do ambiente de laboratório. A pilha de detecção Elastic Security gerou 3 alertas de ALTA gravidade (pontuação de risco 73) identificando corretamente a cadeia de exploração. No entanto, a detecção exigiu ajuste manual - a configuração padrão tinha lacunas que teriam resultado em alertas perdidos.

Conclusão: Hosts Linux não corrigidos executando kernel <= 6.x estão vulneráveis. Se um atacante já possui um ponto de apoio com privilégios baixos, este exploit concede root total de forma silenciosa e rápida, sem deixar rastros visíveis no disco para ferramentas de integridade de arquivos.

Declaração de Risco

Principais Descobertas

1. Regras padrão do auditd não produzem evidências. Sem regras explícitas de syscall para socket, splice e unshare, o exploit é executado silenciosamente - sem logs, sem alertas. A implantação padrão do Elastic Agent não adiciona essas regras automaticamente.
2. Detecção exigiu ajuste de regra. A lógica de detecção publicada pelo Elastic Security Labs usava process.parent.pid como chave de correlação. Na prática, o DirtyFrag cria processos intermediários (fork), quebrando essa correlação. A correção - correlacionar por auditd.session - foi identificada e implementada durante este exercício.
3. Ações pós-exploração foram extensas. Após obter root, o atacante leu /etc/shadow, acessou chaves autorizadas SSH, escreveu um marcador de persistência (/root/pwned.txt) e iniciou reconhecimento de rede via nc. Tudo ocorreu dentro de 30 minutos após o acesso inicial.

Recomendações

B - Relatório Completo de Descobertas

1. Objetivo e Modelo de Ameaça

Objetivo: Validar a cobertura de detecção para exploração do DirtyFrag no SOC do laboratório doméstico, identificar lacunas de detecção e produzir uma regra de detecção corrigida com base no comportamento observado do atacante.

Modelo de ameaça: Adversário simulado pós-acesso inicial com credenciais de phishing para uma conta de usuário com privilégios baixos (saskia, uid=1001). Objetivo: escalada de privilégios para root via DirtyFrag usando o caminho de recebimento xfrm-ESP. Execução em laboratório realizada via console Proxmox - funcionalmente equivalente a SSH pós-acesso.

Dois níveis de capacidade do atacante foram considerados:

• Vanilla (ruidoso): exploit executado sem nenhuma evasão
• Evasivo (silencioso): ruído reduzido, limpeza deliberada

Este exercício cobriu o nível vanilla.

2. Contexto da Vulnerabilidade

DirtyFrag é o terceiro de uma família de bugs relacionados no kernel Linux que todos abusam da mesma causa raiz:

Causa raiz: Os caminhos de anexação de datagramas IPv4/IPv6 não definiam SKBFL_SHARED_FRAG após skb_splice_from_iter() plantar uma página do cache de páginas em um buffer de socket (sk_buff). O caminho de entrada ESP então realizava criptografia in-place em páginas do cache de páginas controladas pelo atacante, tratando-as como skbs não lineares comuns não clonadas.

Primitiva do exploit: Escrita controlada de 4 ou 8 bytes no cache de páginas. Determinístico - nenhuma condição de corrida necessária.

Cadeia do exploit:

1. O atacante lê um binário alvo (ex.: /usr/bin/su) no cache de páginas
2. Constrói um pacote via splice() para que a página do arquivo fique em frag[0] de struct sk_buff
3. O kernel entrega o pacote ao caminho de descriptografia xfrm-ESP
4. ESP realiza criptografia in-place - origem e destino apontam para a página do atacante
5. A criptografia escreve bytes controlados pelo atacante no cache de páginas
6. Todas as leituras subsequentes do arquivo - incluindo execve() do kernel - retornam bytes corrompidos

Propriedade crítica de evasão: O arquivo no disco nunca é modificado. Ferramentas de monitoramento de integridade de arquivos (AIDE, Tripwire, verificações de hash) todas reportam o arquivo alvo como limpo.

Distribuições vulneráveis confirmadas: Ubuntu 24.04.4, RHEL 10.1, AlmaLinux 10, openSUSE Tumbleweed, CentOS Stream 10, Fedora 44.

3. Ambiente de Laboratório

Telemetria ativa no momento do exercício:

4. Fase 1 - Configuração Pré-Execução

4.1 Isolamento do Laboratório

Rede do laboratório isolada antes do exercício. Firewall alias Cyber_escape_door confirmado desabilitado - impedindo alcance lateral para outras VLANs ou internet.

4.2 Verificação do Host Vítima

Kernel vulnerável e conta com privilégios baixos confirmados no ubuntu-vuln:``` saskia@ubuntu-vuln:$ uname -r 6.0.0-22-generic saskia@ubuntu-vuln:$ whoami saskia saskia@ubuntu-vuln:~$ id uid=1001(saskia) gid=1001(saskia) groups=1001(saskia),27(sudo),100(users)

![Verificação do kernel e do usuário](https://assets.kitploit.com/production/public/readmes/15419/bd607abf9c63cc6bf7cfd3432bd406c5fcd51b6e29e4585543f80af99218fd92.png)

#### 4.3 Verificação de Integridade da Stack

**Suricata: em execução e capturando (systemctl status)**
![Serviço Suricata ativo e habilitado](https://assets.kitploit.com/production/public/readmes/15419/3bd0f2a2eb3695861aa36f58545b85567d3a8bdeb4e847060e9dbb63391abf9b.png)

**Kibana/Elasticsearch: verde/saudável (verificação de API)**
![Verificação de integridade ELK via curl retornando 302](https://assets.kitploit.com/production/public/readmes/15419/fcd860faf9fbe62adeb94e889ced2a8c4b649f7240b9f7a9eb572a132c56402d.png)

**Snapshots de VM tirados antes de quaisquer alterações**

![Snapshot da VM ELK - elk-VM-snapshot](https://assets.kitploit.com/production/public/readmes/15419/6d7c0af2ac6a6b526e21696f83ecea29e3b5d2a433b00eeaa104746ac87b155c.png)

![Snapshot da VM Suricata - suricata_pre_dirty_frag (24 Maio 2026 11:15:53)](https://assets.kitploit.com/production/public/readmes/15419/679983fc0d92d9b73c3e33439c4a167732eec5685e852ccfe91738e29930f5fa.png)

![Snapshot do Ubuntu-Vuln-Host](https://assets.kitploit.com/production/public/readmes/15419/0c66bce642d8508ac2dddfe5930a84ba3f936fc8507fb96717ced5bc2bd77f8d.png)

#### 4.4 Captura de Rede
tcpdump iniciado no host Suricata (`emp6s19`, comprimento de snapshot 262144 bytes) para captura completa de pacotes do tráfego de `172.66.66.27`.
![cópia de eventos de tráfego do suricata](https://assets.kitploit.com/production/public/readmes/15419/12c4e8bd2f5749a5ff3afda1613fecf69d635fbb87003808d83cc89815430e3c.png)


![tcpdump iniciado no sensor Suricata](https://assets.kitploit.com/production/public/readmes/15419/09e4a4ab1a4f692ee24f168c2094bf159590b9c6bb4ea8a977f0c004687ae341.png)

---

### 5. Fase 2 - Execução do Exploit

#### 5.1 Preparação

Código-fonte do exploit (`exp.c`) do PoC V4bel/dirtyfrag preparado no host vítima.```bash
ubuntu-vuln@ubuntu-vuln:~/dirtyfrag$ ls
exp  exp.c  README.md
ubuntu-vuln@ubuntu-vuln:~/dirtyfrag$ cp exp.c /tmp/exp/

5.2 Compilação

Compilado como root via sudo gcc (o usuário saskia está no sudoers):

Terminal à direita mostra a cópia preparada visível para o usuário saskia.``` saskia@ubuntu-vuln:$ sudo gcc -o /tmp/exp/clean_frag /tmp/exp/exp.c saskia@ubuntu-vuln:$ ls -la /tmp/exp/ -rwxr-xr-x 1 root root 62320 May 24 12:18 clean_frag -rw-rw-r-- 1 ubuntu-vuln ubuntu-vuln 67803 May 24 12:13 exp.c saskia@ubuntu-vuln:~$ id uid=1001(saskia) gid=1001(saskia) groups=1001(saskia),27(sudo),100(users)

Binary: ELF 64-bit LSB executável, x86-64, linked dinamicamente.

![Exploit compiled - clean_frag binary ready](https://assets.kitploit.com/production/public/readmes/15419/0449b71e0aa5ab6acc1483dc1109e40a59108fe2fb1c438413daa05e3e8c4f3c.png)

#### 5.3 Execução - Root Obtido

Exploit executado como `saskia` (uid=1001). O processo (`clean_frag`, pid=4326) abriu sockets `AF_RXRPC` e `AF_ALG`, depois chamou `splice()` para plantar a página do cache de páginas no buffer de rede. A criptografia in-place no caminho ESP escreveu bytes controlados pelo atacante no cache de páginas. Um processo filho (pid=4327) chamou `unshare` com `a0=50000000` (CLONE_NEWUSER | CLONE_NEWNET) para obter capacidades com escopo de namespace.```
saskia@ubuntu-vuln:~$ /tmp/exp/clean_frag
...
root@ubuntu-vuln:~# id
uid=0(root) gid=0(root) groups=0(root)
root@ubuntu-vuln:~# ls

Shell completo obtido às 12:22 CEST (10:22 UTC), 24 de maio de 2026.

Sequência de syscalls do auditd capturada (UTC):

Todos os eventos compartilham auditd.session=2.

6. Fase 3 - Atividade Pós-Exploração

Todas as ações executadas como root em ubuntu-vuln a partir de ~12:22 CEST.

6.1 Marcador de Persistência```bash

root@ubuntu-vuln:# echo "Dirty Frag PoC executed at $(date)" > /root/pwned.txt root@ubuntu-vuln:# cat /root/pwned.txt Dirty Frag PoC executed at Sun May 24 12:28:05 PM CEST 2026

![Marcador de persistência escrito em /root/pwned.txt](https://assets.kitploit.com/production/public/readmes/15419/a4c9f7d5eaf9f165aa382692c89c6e98c50884858bae6929aec9251bb09ba06e.png)

#### 6.2 Acesso a Credenciais```bash
root@ubuntu-vuln:~# cat /etc/shadow | head -2
root:*:19823:0:99999:7:::
daemon:*:19823:0:99999:7:::
root@ubuntu-vuln:~# cat /home/ubuntu-vuln/.ssh/authorized_keys
ssh-ed25519 AAAA[...]

Ficheiro shadow e chaves autorizadas SSH acedidos. Num compromisso real, isto permite a quebra de palavras-passe offline e acesso persistente de backdoor SSH.

6.3 Reconhecimento de Rede```bash

root@ubuntu-vuln:~# nc -vz 172.66.66.1 100-8000

Varredura de portas do gateway do laboratório (`172.66.66.1`, portas 100-8000) executada a partir do contexto root às 12:51 CEST. Isso demonstra capacidade de movimentação lateral e mapeamento de rede a partir de uma sessão com privilégios elevados.

![Varredura de rede a partir do root - nc contra o gateway](https://assets.kitploit.com/production/public/readmes/15419/350b4904ab94e991640582b63d0bc61c679c754fdce22b856bb92ab177a02ef5.png)

#### 6.4 Visibilidade de Rede do Suricata

O Suricata capturou **105 eventos** associados a `172.66.66.27` durante a janela do exercício (88 mdns, 17 flow). No momento em que a captura de tela foi tirada (durante a varredura nc por volta das 12:53 CEST), 29 eventos estavam visíveis no painel.

O próprio exploit DirtyFrag é interno ao kernel e não produz assinatura de rede - a primitiva de escalada não gera tráfego anômalo na rede. O Suricata foi utilizado para coletar pcaps de tráfego pós-exploração e tentativas de enumeração, em vez de detectar o exploit em si.

| Tipo de Evento | Contagem |
| ---------- | ----- |
| mdns | 88 |
| flow | 17 |
| **Total** | **105** |

Os eventos de flow se agrupam em torno da janela de varredura de portas nc (10:50-11:10 UTC / 12:50-13:10 CEST).

![Eventos do Suricata para 172.66.66.27](https://assets.kitploit.com/production/public/readmes/15419/de8249b1c4230a57841799e7806ca97796db4de2321a57c0891f043d842c54b0.png)

---

### 7. Fase 4 - Engenharia de Detecção

#### 7.1 Regras de Detecção Implantadas

Duas regras de sequência EQL foram criadas no Mecanismo de Detecção do Kibana com base no artigo do Elastic Security Labs.

**Regra 1 - Socket AF_RXRPC ou AF_ALG com Splice Seguido de Execução** (não disparou - veja a lacuna abaixo)```eql
sequence with maxspan=60s
  [any where host.os.type == "linux" and
   (
    (event.category == "process" and auditd.data.syscall == "socket"
     and auditd.data.a0 in ("26", "21")) or
    (event.category == "process" and auditd.data.syscall == "splice") or
    (event.category == "network" and event.action == "bound-socket"
     and data_stream.dataset == "auditd_manager.auditd"
     and auditd.data.socket.family == "38")
   )
   and user.id != "0"] by process.pid, host.id, user.id with runs=10
  [process where host.os.type == "linux" and event.action == "executed" and
   (
     (user.effective.id == "0" and user.id != "0") or
     (process.name in ("bash", "sh", "zsh", "dash", "fish", "ksh", "busybox")
      and process.args in ("-c", "--command", "-ic", "-ci", "-cl", "-lc",
                            "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh"))
    )] by process.parent.pid, host.id, user.id

Regra 2 - Manipulação de Namespace Seguida de Escalação de Privilégios (acionado após correção)```eql sequence by host.id, auditd.session with maxspan=30s [process where host.os.type == "linux" and auditd.data.syscall == "unshare" and auditd.data.a0 in ("10000000", "50000000", "70000000", "10020000", "50020000", "70020000") and user.id != "0" and user.id != null] [process where host.os.type == "linux" and user.id == "0" and user.id != null and (process.name in ("bash", "sh", "zsh", "dash", "fish", "ksh", "su", "sudo", "pkexec", "busybox", "mksh") or process.name like ("python*", "perl*", "ruby*", "php*", "lua*"))]

#### 7.2 Lacuna de Detecção Inicial - Cobertura de Syscall Faltante

A Regra 1 retornou zero resultados. A configuração padrão do auditd em `ubuntu-vuln` capturou apenas: `write`, `bpf`, `openat`, `unshare`.

Faltando: `socket`, `splice`, `bind` - as primitivas principais do exploit.

**Remediação:** Adicionado em `/etc/audit/rules.d/dirtyfrag.rules`:```
-a always,exit -F arch=b64 -S socket -k socket_syscall
-a always,exit -F arch=b32 -S socketcall -k socket_syscall
-a always,exit -F arch=b64 -S splice -k splice-syscall
-a always,exit -F arch=b32 -S splice -k splice-syscall
-a always,exit -F arch=b64 -S unshare -k unshare-syscall
-a always,exit -F arch=b32 -S unshare -k unshare-syscall

272 novos eventos auditd chegaram ao Elasticsearch segundos após a execução do exploit.

7.3 Lacuna de Correlação EQL - Fragmentação da Árvore de Processos

Apesar dos eventos serem capturados, a Regra 2 retornou 0 correspondências.

Causa raiz - árvore de processos real (do Elasticsearch):

A regra original correlacionava por process.parent.pid. O evento unshare tinha ppid=4326, mas o shell root tinha um pai diferente - DirtyFrag cria processos intermediários, quebrando a correlação.

Correção: Correlacionar por auditd.session. Todos os eventos na cadeia do exploit compartilhavam session=2, vinculando corretamente a sequência independentemente da profundidade dos forks.

7.4 Resultado do Alerta

3 alertas de alta severidade, pontuação de risco 73, no Kibana Security - Alertas em 2026-05-24T10:25:57Z UTC (12:25:57 CEST).

• Regra: DirtyFrag - Manipulação de Namespace Seguida de Escalação de Privilégios
• Severidade: Alta
• Pontuação de risco: 73
• Host: ubuntu-vuln

8. Referência de Detecção

Mapeamento MITRE ATT&CK

Valores Chave de Syscall

Consultas de Referência KQL

Todos os eventos auditd relacionados ao dirtyfrag:```kql data_stream.dataset: "auditd_manager.auditd" and auditd.summary.how: dirtyfrag

**Manipulação de namespace por não-root:**```kql
data_stream.dataset: "auditd_manager.auditd" and auditd.data.syscall: "unshare" and auditd.data.a0: "50000000"

Atividade de root pós-escalada na mesma sessão:```kql data_stream.dataset: "auditd_manager.auditd" and user.id: "0" and auditd.session: "2"

**Todos os eventos do auditd durante a janela de exploração:**```kql
data_stream.dataset: "auditd_manager.auditd" and @timestamp >= "2026-05-24T10:20:00Z" and @timestamp <= "2026-05-24T10:30:00Z"

Syscalls de socket e splice do processo de exploit:```kql data_stream.dataset: "auditd_manager.auditd" and auditd.summary.how: "/tmp/exp/clean_frag"

---

### 9. Resumo das Principais Descobertas

| # | Descoberta | Severidade | Remediado |
| - | ------- | -------- | ---------- |
| 1 | As regras padrão do auditd não capturam `socket`, `splice`, `unshare` - nenhuma evidência sem regras explícitas | Crítico | Sim - regras personalizadas implantadas em `/etc/audit/rules.d/dirtyfrag.rules` |
| 2 | A correlação EQL por `process.parent.pid` falha para cadeias de exploração bifurcadas | Alta | Sim - alterado para `auditd.session` |
| 3 | Monitoramento de integridade de arquivos cego para DirtyFrag - arquivos em disco inalterados durante todo o processo | Alta | Nenhuma remediação no escopo - corrigir o kernel é a solução |
| 4 | Pós-exploração: arquivo shadow, chaves SSH e reconhecimento de rede todos executados como root antes de qualquer resposta baseada em alerta | Alta | Detectado via logs do auditd; nenhuma regra dedicada foi acionada para acesso a credenciais ou fase de reconhecimento |

---

### 10. Referências

- Elastic Security Labs: [Copy Fail e DirtyFrag: Erros de Página do Linux na Natureza](https://www.elastic.co/security-labs/copy-fail-dirtyfrag-linux-page-bugs-in-the-wild)
- Prova de Conceito Pública: [V4bel/dirtyfrag no GitHub](https://github.com/V4bel/dirtyfrag)
- MITRE ATT&CK: [T1068 - Exploração para Escalação de Privilégio](https://attack.mitre.org/techniques/T1068/)
- MITRE ATT&CK: [TA0004 - Escalação de Privilégio](https://attack.mitre.org/tactics/TA0004/)
- MITRE ATT&CK: [T1003.008 - /etc/passwd e /etc/shadow](https://attack.mitre.org/techniques/T1003/008/)