DirtyFrag (CVE-2026-43284) - Informe del Ejercicio de Detección en Laboratorio

Clasificación: Laboratorio Interno - CyberLAB
Fecha: 24 de mayo de 2026
Plataforma: Elastic Stack v9.4.1
Estado: Detección Confirmada

Índice de Contenidos

• A - Resumen Ejecutivo
• B - Informe Completo de Hallazgos
  • 1. Objetivo y Modelo de Amenaza
  • 2. Antecedentes de la Vulnerabilidad
  • 3. Entorno de Laboratorio
  • 4. Fase 1 - Configuración Previa a la Ejecución
  • 5. Fase 2 - Ejecución del Exploit
  • 6. Fase 3 - Actividad Posterior a la Explotación
  • 7. Fase 4 - Ingeniería de Detección
  • 8. Referencia de Detección
  • 9. Resumen de Hallazgos Clave
  • 10. Referencias

A - Resumen Ejecutivo

Lo Que Se Probó

Un ejercicio controlado de explotación simulando un adversario posterior al acceso inicial utilizando DirtyFrag (CVE-2026-43284), una vulnerabilidad de escalada de privilegios del kernel de Linux. El escenario simulado del atacante: un usuario con pocos privilegios (saskia, uid=1001) obtenido mediante credenciales phishing intenta escalar a root en un host Linux interno. El laboratorio utilizó una máquina Ubuntu deliberadamente vulnerable (ubuntu-vuln, kernel 6.0.0-22-generic) aislada de las redes de producción.

Resultado: Explotación Exitosa - Detección Confirmada

El atacante obtuvo acceso completo como root (uid=0) dentro del entorno del laboratorio. La pila de detección de Elastic Security generó 3 alertas de ALTA gravedad (puntuación de riesgo 73) identificando correctamente la cadena de explotación. Sin embargo, la detección requirió ajustes manuales: la configuración predeterminada tenía carencias que habrían resultado en alertas omitidas.

Conclusión: Los hosts Linux sin parches que ejecutan kernel <= 6.x son vulnerables. Si un atacante ya tiene un punto de apoyo con pocos privilegios, este exploit les otorga root completo de forma silenciosa y rápida, sin dejar rastro en disco visible para las herramientas de integridad de archivos.

Declaración de Riesgo

Hallazgos Clave

1. Las reglas predeterminadas de auditd no producen evidencia. Sin reglas explícitas de syscall para socket, splice y unshare, el exploit se ejecuta silenciosamente: sin registros, sin alertas. La implementación predeterminada de Elastic Agent no añade estas reglas automáticamente.
2. La detección requirió ajuste de reglas. La lógica de detección publicada por Elastic Security Labs usaba process.parent.pid como clave de correlación. En la práctica, DirtyFrag bifurca procesos intermedios, rompiendo esa correlación. La solución —correlacionar por auditd.session— fue identificada e implementada durante este ejercicio.
3. Las acciones posteriores a la explotación fueron extensas. Después de obtener root, el atacante leyó /etc/shadow, accedió a las claves autorizadas de SSH, escribió un marcador de persistencia (/root/pwned.txt) e inició reconocimiento de red mediante nc. Todo ocurrió dentro de los 30 minutos posteriores al acceso inicial.

Recomendaciones

B - Informe Completo de Hallazgos

1. Objetivo y Modelo de Amenaza

Objetivo: Validar la cobertura de detección para la explotación de DirtyFrag en el SOC del laboratorio local, identificar brechas de detección y producir una regla de detección corregida basada en el comportamiento real observado del atacante.

Modelo de amenaza: Adversario simulado posterior al acceso inicial con credenciales phishing para una cuenta de usuario con pocos privilegios (saskia, uid=1001). Objetivo: escalada de privilegios a root mediante DirtyFrag usando la ruta de recepción xfrm-ESP. La ejecución en el laboratorio se realizó mediante consola de Proxmox, funcionalmente equivalente a SSH posterior al acceso.

Se consideraron dos niveles de capacidad del atacante:

• Vanilla (ruidoso): explotación ejecutada sin evasión
• Evasivo (silencioso): ruido reducido, limpieza deliberada

Este ejercicio cubrió el nivel vanilla.

2. Antecedentes de la Vulnerabilidad

DirtyFrag es la tercera de una familia de errores relacionados del kernel de Linux que todos abusan de la misma causa raíz:

Causa raíz: Las rutas de anexado de datagramas IPv4/IPv6 no establecían SKBFL_SHARED_FRAG después de que skb_splice_from_iter() colocara una página de la caché de páginas en un búfer de socket (sk_buff). Luego, la ruta de entrada de ESP realizaba criptografía in situ en páginas de la caché de páginas controladas por el atacante, tratándolas como skbs no lineales normales no clonados.

Primitiva del exploit: Escritura controlada de 4 u 8 bytes en la caché de páginas. Determinista: no se requiere condición de carrera.

Cadena del exploit:

1. El atacante lee un binario objetivo (ej. /usr/bin/su) en la caché de páginas
2. Construye un paquete mediante splice() para que la página del archivo se ubique en frag[0] de struct sk_buff
3. El kernel entrega el paquete a la ruta de descifrado xfrm-ESP
4. ESP realiza criptografía in situ: tanto el origen como el destino apuntan a la página del atacante
5. La criptografía escriba bytes controlados por el atacante en la caché de páginas
6. Todas las lecturas posteriores del archivo —incluyendo execve() del kernel— devuelven bytes corruptos

Propiedad crítica de evasión: El archivo en disco nunca se modifica. Las herramientas de monitoreo de integridad de archivos (AIDE, Tripwire, verificaciones hash) todas reportan el archivo objetivo como limpio.

Distribuciones vulnerables confirmadas: Ubuntu 24.04.4, RHEL 10.1, AlmaLinux 10, openSUSE Tumbleweed, CentOS Stream 10, Fedora 44.

3. Entorno de Laboratorio

Telemetría activa durante el ejercicio:

4. Fase 1 - Configuración Previa a la Ejecución

4.1 Aislamiento del Laboratorio

Red del laboratorio aislada antes del ejercicio. El alias de firewall Cyber_escape_door confirmado como deshabilitado, impidiendo el alcance lateral a otras VLANs o internet.

4.2 Verificación del Host Víctima

Kernel vulnerable y cuenta con pocos privilegios confirmados en 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)

![Verificación del kernel y del usuario](https://assets.kitploit.com/production/public/readmes/15419/bd607abf9c63cc6bf7cfd3432bd406c5fcd51b6e29e4585543f80af99218fd92.png)

#### 4.3 Comprobación de salud de la pila

**Suricata: ejecutándose y capturando (systemctl status)**
![Servicio Suricata activo y habilitado](https://assets.kitploit.com/production/public/readmes/15419/3bd0f2a2eb3695861aa36f58545b85567d3a8bdeb4e847060e9dbb63391abf9b.png)

**Kibana/Elasticsearch: verde/saludable (comprobación de API)**
![Comprobación de salud de ELK mediante curl que devuelve 302](https://assets.kitploit.com/production/public/readmes/15419/fcd860faf9fbe62adeb94e889ced2a8c4b649f7240b9f7a9eb572a132c56402d.png)

**Capturas de instantáneas de VM tomadas antes de cualquier cambio**

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

![Instantánea de VM de Suricata - suricata_pre_dirty_frag (24 de mayo de 2026 11:15:53)](https://assets.kitploit.com/production/public/readmes/15419/679983fc0d92d9b73c3e33439c4a167732eec5685e852ccfe91738e29930f5fa.png)

![Instantánea de Ubuntu-Vuln-Host](https://assets.kitploit.com/production/public/readmes/15419/0c66bce642d8508ac2dddfe5930a84ba3f936fc8507fb96717ced5bc2bd77f8d.png)

#### 4.4 Captura de red
tcpdump iniciado en el host Suricata (`emp6s19`, longitud de instantánea 262144 bytes) para la captura completa de paquetes del tráfico de `172.66.66.27`.
![copia de eventos de tráfico de suricata](https://assets.kitploit.com/production/public/readmes/15419/12c4e8bd2f5749a5ff3afda1613fecf69d635fbb87003808d83cc89815430e3c.png)

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

---

### 5. Fase 2 - Ejecución del Exploit

#### 5.1 Preparación

Código fuente del exploit (`exp.c`) de V4bel/dirtyfrag PoC preparado en el host víctima.```bash
ubuntu-vuln@ubuntu-vuln:~/dirtyfrag$ ls
exp  exp.c  README.md
ubuntu-vuln@ubuntu-vuln:~/dirtyfrag$ cp exp.c /tmp/exp/

La terminal derecha muestra la copia preparada visible para el usuario saskia.

5.2 Compilación

Compilado como root mediante sudo gcc (el usuario saskia está en sudoers):``` 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 executable, x86-64, dynamically linked.

![Exploit compilado - binario clean_frag listo](https://assets.kitploit.com/production/public/readmes/15419/0449b71e0aa5ab6acc1483dc1109e40a59108fe2fb1c438413daa05e3e8c4f3c.png)

#### 5.3 Ejecución - Root obtenido

El exploit se ejecutó como `saskia` (uid=1001). El proceso (`clean_frag`, pid=4326) abrió sockets `AF_RXRPC` y `AF_ALG`, luego llamó a `splice()` para plantar la página de caché en el búfer de red. La criptografía in-situ en la ruta ESP escribió bytes controlados por el atacante en la caché de páginas. Un proceso hijo (pid=4327) llamó a `unshare` con `a0=50000000` (CLONE_NEWUSER | CLONE_NEWNET) para obtener capacidades con alcance de espacio de nombres.```
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 root completa obtenida a las 12:22 CEST (10:22 UTC), 24 de mayo de 2026.

Secuencia de llamadas al sistema registrada por auditd (UTC):

Todos los eventos comparten auditd.session=2.

6. Fase 3 - Actividad posterior a la explotación

Todas las acciones realizadas como root en ubuntu-vuln desde las ~12:22 CEST en adelante.

6.1 Marcador de persistencia```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 persistencia escrito en /root/pwned.txt](https://assets.kitploit.com/production/public/readmes/15419/a4c9f7d5eaf9f165aa382692c89c6e98c50884858bae6929aec9251bb09ba06e.png)

#### 6.2 Acceso a Credenciales```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[...]

Archivo shadow y claves autorizadas SSH accedidas. En un compromiso real, esto permite el descifrado de contraseñas fuera de línea y el acceso persistente mediante backdoor SSH.

6.3 Reconocimiento de Red```bash

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

Escaneo de puertos de la puerta de enlace del laboratorio (`172.66.66.1`, puertos 100-8000) ejecutado desde contexto root a las 12:51 CEST. Esto demuestra capacidad de movimiento lateral y mapeo de red desde una sesión escalada.

![Escaneo de red desde root - nc contra la puerta de enlace](https://assets.kitploit.com/production/public/readmes/15419/350b4904ab94e991640582b63d0bc61c679c754fdce22b856bb92ab177a02ef5.png)

#### 6.4 Visibilidad de Red de Suricata

Suricata capturó **105 eventos** asociados a `172.66.66.27` durante la ventana del ejercicio (88 mdns, 17 flow). En el momento en que se tomó la captura de pantalla (durante el escaneo nc a las ~12:53 CEST), 29 eventos eran visibles en el tablero.

La explotación DirtyFrag en sí misma es interna al kernel y no produce firma de red; la primitiva de escalada no genera tráfico anómalo en la red. Se utilizó Suricata para recolectar pcaps del tráfico posterior a la explotación y los intentos de enumeración, en lugar de detectar la explotación en sí.

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

Los eventos flow se agrupan alrededor de la ventana de escaneo de puertos nc (10:50-11:10 UTC / 12:50-13:10 CEST).

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

---

### 7. Fase 4 - Ingeniería de Detección

#### 7.1 Reglas de Detección Desplegadas

Se crearon dos reglas de secuencia EQL en el Motor de Detección de Kibana basadas en el artículo de Elastic Security Labs.

**Regla 1 - AF_RXRPC or AF_ALG Socket with Splice Followed by Execution** (no se disparó - ver brecha a continuación)```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

Regla 2 - Manipulación de Namespace seguida de Escalada de Privilegios (activado después de la corrección)```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 Brecha de Detección Inicial - Cobertura de Syscall Faltante

La Regla 1 devolvió cero resultados. La configuración predeterminada de auditd en `ubuntu-vuln` capturó: `write`, `bpf`, `openat`, `unshare` únicamente.

Faltantes: `socket`, `splice`, `bind` - las primitivas centrales del exploit.

**Corrección:** Agregado a `/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 nuevos eventos de auditd llegaron a Elasticsearch en segundos después de la ejecución del exploit.

7.3 Brecha de Correlación EQL - Fragmentación del Árbol de Procesos

A pesar de que se capturaron eventos, la Regla 2 devolvió 0 coincidencias.

Causa raíz - árbol de procesos real (desde Elasticsearch):

La regla original correlacionaba por process.parent.pid. El evento unshare tenía ppid=4326, pero el shell root tenía un padre diferente - DirtyFrag bifurca procesos intermedios, rompiendo la correlación.

Solución: Correlacionar por auditd.session. Todos los eventos en la cadena de exploit compartían session=2, enlazando correctamente la secuencia independientemente de la profundidad de la bifurcación.

7.4 Resultado de Alerta

3 alertas de ALTA gravedad, puntuación de riesgo 73, en Kibana Security - Alertas a las 2026-05-24T10:25:57Z UTC (12:25:57 CEST).

• Regla: DirtyFrag - Namespace Manipulation Followed by Privilege Escalation
• Gravedad: Alta
• Puntuación de riesgo: 73
• Host: ubuntu-vuln

8. Referencia de Detección

Mapeo MITRE ATT&CK

Valores Clave de Syscall

Consultas de Referencia KQL

Todos los eventos de auditd relacionados con dirtyfrag:```kql data_stream.dataset: "auditd_manager.auditd" and auditd.summary.how: dirtyfrag

**Manipulación de espacios de nombres por parte de un usuario no root:**```kql
data_stream.dataset: "auditd_manager.auditd" and auditd.data.syscall: "unshare" and auditd.data.a0: "50000000"

Actividad de root posterior a la escalada en la misma sesión:```kql data_stream.dataset: "auditd_manager.auditd" and user.id: "0" and auditd.session: "2"

**Todos los eventos de auditd durante la ventana de exploit:**```kql
data_stream.dataset: "auditd_manager.auditd" and @timestamp >= "2026-05-24T10:20:00Z" and @timestamp <= "2026-05-24T10:30:00Z"

Llamadas al sistema Socket y splice desde el proceso de explotación:```kql data_stream.dataset: "auditd_manager.auditd" and auditd.summary.how: "/tmp/exp/clean_frag"

---

### 9. Resumen de Hallazgos Clave

| # | Hallazgo | Severidad | Remedida |
| - | ------- | -------- | ---------- |
| 1 | Las reglas predeterminadas de auditd omiten `socket`, `splice`, `unshare` - sin evidencia sin reglas explícitas | Crítica | Sí - se desplegaron reglas personalizadas en `/etc/audit/rules.d/dirtyfrag.rules` |
| 2 | La correlación EQL por `process.parent.pid` falla para cadenas de exploits bifurcados | Alta | Sí - cambiado a `auditd.session` |
| 3 | El monitoreo de integridad de archivos es ciego a DirtyFrag - los archivos en disco permanecen sin cambios | Alta | No hay remediación dentro del alcance - parchear el kernel es la solución |
| 4 | Post-explotación: archivo shadow, claves SSH y reconocimiento de red ejecutados como root antes de cualquier respuesta basada en alertas | Alta | Detectado mediante logs de auditd; no se activó ninguna regla dedicada para acceso a credenciales o fase de reconocimiento |

---

### 10. Referencias

- Elastic Security Labs: [Copy Fail y DirtyFrag: Errores de Página de Linux en la Naturaleza](https://www.elastic.co/security-labs/copy-fail-dirtyfrag-linux-page-bugs-in-the-wild)
- PoC público: [V4bel/dirtyfrag en GitHub](https://github.com/V4bel/dirtyfrag)
- MITRE ATT&CK: [T1068 - Explotación para Elevación de Privilegios](https://attack.mitre.org/techniques/T1068/)
- MITRE ATT&CK: [TA0004 - Elevación de Privilegios](https://attack.mitre.org/tactics/TA0004/)
- MITRE ATT&CK: [T1003.008 - /etc/passwd y /etc/shadow](https://attack.mitre.org/techniques/T1003/008/)