DirtyFrag (CVE-2026-43284) - Rapport d'exercice de détection en laboratoire

Classification : Laboratoire interne - CyberLAB
Date : 24 mai 2026
Plateforme : Elastic Stack v9.4.1
Statut : Détection confirmée

Table des matières

• A - Résumé exécutif
• B - Rapport d'analyse complet
  • 1. Objectif et modèle de menace
  • 2. Contexte de la vulnérabilité
  • 3. Environnement de laboratoire
  • 4. Phase 1 - Configuration avant exécution
  • 5. Phase 2 - Exécution de l'exploit
  • 6. Phase 3 - Activité post-exploitation
  • 7. Phase 4 - Ingénierie de détection
  • 8. Référence de détection
  • 9. Résumé des principales conclusions
  • 10. Références

A - Résumé exécutif

Ce qui a été testé

Un exercice d'exploitation contrôlé simulant un adversaire après un accès initial utilisant DirtyFrag (CVE-2026-43284), une vulnérabilité d'élévation de privilèges du noyau Linux. Scénario d'attaque simulé : un utilisateur à faibles privilèges (saskia, uid=1001) obtenu via des identifiants phishés tente d'élever ses privilèges à root sur une machine Linux interne. Le laboratoire a utilisé une machine Ubuntu volontairement vulnérable (ubuntu-vuln, noyau 6.0.0-22-generic) isolée des réseaux de production.

Résultat : Exploitation réussie - Détection confirmée

L'attaquant a obtenu un accès root complet (uid=0) dans l'environnement de laboratoire. La pile de détection Elastic Security a généré 3 alertes de sévérité ÉLEVÉE (score de risque 73) identifiant correctement la chaîne d'exploitation. Cependant, la détection a nécessité un réglage manuel - la configuration par défaut présentait des lacunes qui auraient entraîné des alertes manquées.

En résumé : Les machines Linux non patchées exécutant un noyau <= 6.x sont vulnérables. Si un attaquant possède déjà un point d'appui à faibles privilèges, cet exploit lui donne un accès root complet silencieusement et rapidement, sans aucune trace sur le disque visible par les outils d'intégrité des fichiers.

Déclaration de risque

Principales conclusions

1. Les règles auditd par défaut ne produisent aucune preuve. Sans règles d'appel système explicites pour socket, splice et unshare, l'exploit s'exécute silencieusement - aucun journal, aucune alerte. Le déploiement par défaut d'Elastic Agent n'ajoute pas ces règles automatiquement.
2. La détection a nécessité un réglage des règles. La logique de détection publiée par Elastic Security Labs utilisait process.parent.pid comme clé de corrélation. En pratique, DirtyFrag crée des processus intermédiaires, brisant cette corrélation. La correction - corrélation par auditd.session - a été identifiée et implémentée au cours de cet exercice.
3. Les actions post-exploitation étaient étendues. Après avoir obtenu root, l'attaquant a lu /etc/shadow, accédé aux clés autorisées SSH, écrit un marqueur de persistance (/root/pwned.txt) et initié une reconnaissance réseau via nc. Tout cela s'est produit dans les 30 minutes suivant l'accès initial.

Recommandations

B - Rapport d'analyse complet

1. Objectif et modèle de menace

Objectif : Valider la couverture de détection pour l'exploitation de DirtyFrag dans le SOC du laboratoire personnel, identifier les lacunes de détection et produire une règle de détection corrigée fondée sur le comportement observé de l'attaquant.

Modèle de menace : Adversaire simulé après accès initial avec des identifiants phishés pour un compte utilisateur à faibles privilèges (saskia, uid=1001). Objectif : élévation de privilèges vers root via DirtyFrag en utilisant la voie de réception xfrm-ESP. Exécution en laboratoire effectuée via la console Proxmox - fonctionnellement équivalente à un accès SSH postérieur.

Deux niveaux de capacité de l'attaquant ont été considérés :

• Vanille (bruyant) : exploit exécuté sans évasion
• Évasif (silencieux) : bruit réduit, nettoyage délibéré

Cet exercice a couvert le niveau vanille.

2. Contexte de la vulnérabilité

DirtyFrag est le troisième d'une famille de bogues du noyau Linux apparentés qui exploitent tous la même cause racine :

Cause racine : Les chemins d'ajout de datagrammes IPv4/IPv6 ne définissaient pas SKBFL_SHARED_FRAG après que skb_splice_from_iter() ait placé une page du cache de pages dans un tampon de socket (sk_buff). Le chemin d'entrée ESP effectuait ensuite une cryptographie en place sur les pages du cache de pages contrôlées par l'attaquant, les traitant comme des skbs non linéaires ordinaires non clonés.

Primitive d'exploit : Écriture contrôlée de 4 ou 8 octets dans le cache de pages. Déterministe - aucune condition de concurrence requise.

Chaîne d'exploitation :

1. L'attaquant lit le binaire cible (par exemple /usr/bin/su) dans le cache de pages
2. Construit un paquet via splice() de sorte que la page du fichier se trouve dans frag[0] de struct sk_buff
3. Le noyau délivre le paquet au chemin de déchiffrement xfrm-ESP
4. ESP effectue une cryptographie en place - la source et la destination pointent toutes deux vers la page de l'attaquant
5. La cryptographie écrit des octets contrôlés par l'attaquant dans le cache de pages
6. Toutes les lectures ultérieures du fichier - y compris l'execve() du noyau - retournent des octets corrompus

Propriété d'évasion critique : Le fichier sur disque n'est jamais modifié. Les outils de surveillance de l'intégrité des fichiers (AIDE, Tripwire, vérifications de hachage) indiquent tous que le fichier cible est sain.

Distributions vulnérables confirmées : Ubuntu 24.04.4, RHEL 10.1, AlmaLinux 10, openSUSE Tumbleweed, CentOS Stream 10, Fedora 44.

3. Environnement de laboratoire

Télémétrie active au moment de l'exercice :

4. Phase 1 - Configuration avant exécution

4.1 Isolation du laboratoire

Réseau de laboratoire isolé avant l'exercice. Alias de pare-feu Cyber_escape_door confirmé désactivé - empêchant toute portée latérale vers d'autres VLAN ou Internet.

4.2 Vérification de l'hôte victime

Noyau vulnérable et compte à faibles privilèges confirmés sur 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)

![Vérification du noyau et de l'utilisateur](https://assets.kitploit.com/production/public/readmes/15419/bd607abf9c63cc6bf7cfd3432bd406c5fcd51b6e29e4585543f80af99218fd92.png)

#### 4.3 Vérification de l'état de la pile

**Suricata : en cours d'exécution et capture (systemctl status)**
![Service Suricata actif et activé](https://assets.kitploit.com/production/public/readmes/15419/3bd0f2a2eb3695861aa36f58545b85567d3a8bdeb4e847060e9dbb63391abf9b.png)

**Kibana/Elasticsearch : vert/bon état (vérification API)**
![Vérification de l'état ELK via curl retournant 302](https://assets.kitploit.com/production/public/readmes/15419/fcd860faf9fbe62adeb94e889ced2a8c4b649f7240b9f7a9eb572a132c56402d.png)

**Instantanés de VM pris avant toute modification**

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

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

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

#### 4.4 Capture réseau
tcpdump démarré sur l'hôte Suricata (`emp6s19`, longueur d'instantané 262144 octets) pour la capture complète des paquets du trafic `172.66.66.27`.
![Copie des événements de trafic Suricata](https://assets.kitploit.com/production/public/readmes/15419/12c4e8bd2f5749a5ff3afda1613fecf69d635fbb87003808d83cc89815430e3c.png)

![tcpdump démarré sur le capteur Suricata](https://assets.kitploit.com/production/public/readmes/15419/09e4a4ab1a4f692ee24f168c2094bf159590b9c6bb4ea8a977f0c004687ae341.png)

---

### 5. Phase 2 - Exécution de l'exploit

#### 5.1 Préparation

Code source de l'exploit (`exp.c`) du PoC V4bel/dirtyfrag placé sur l'hôte victime.```bash
ubuntu-vuln@ubuntu-vuln:~/dirtyfrag$ ls
exp  exp.c  README.md
ubuntu-vuln@ubuntu-vuln:~/dirtyfrag$ cp exp.c /tmp/exp/

Le terminal de droite montre la copie préparée visible pour l'utilisateur saskia.

5.2 Compilation

Compilé en tant que root via sudo gcc (l'utilisateur saskia est dans 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 exécutable, x86-64, lié dynamiquement.

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

#### 5.3 Exécution - Obtention du Root

Exploit exécuté en tant que `saskia` (uid=1001). Le processus (`clean_frag`, pid=4326) a ouvert des sockets `AF_RXRPC` et `AF_ALG`, puis a appelé `splice()` pour placer la page du cache de pages dans le tampon réseau. Le chiffrement en place sur le chemin ESP a écrit des octets contrôlés par l'attaquant dans le cache de pages. Un processus fils (pid=4327) a appelé `unshare` avec `a0=50000000` (CLONE_NEWUSER | CLONE_NEWNET) pour obtenir des capacités limitées à l'espace de noms.```
saskia@ubuntu-vuln:~$ /tmp/exp/clean_frag
...
root@ubuntu-vuln:~# id
uid=0(root) gid=0(root) groups=0(root)
root@ubuntu-vuln:~# ls

Full root shell obtained at 12:22 CEST (10:22 UTC), 24 May 2026.

Auditd syscall sequence captured (UTC):

All events share auditd.session=2.

6. Phase 3 - Activité post-exploitation

Toutes les actions effectuées en tant que root sur ubuntu-vuln à partir d'environ 12:22 CEST.

6.1 Marqueur de persistance```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

![Marqueur de persistance écrit dans /root/pwned.txt](https://assets.kitploit.com/production/public/readmes/15419/a4c9f7d5eaf9f165aa382692c89c6e98c50884858bae6929aec9251bb09ba06e.png)

#### 6.2 Accès aux identifiants```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[...]

Fichier shadow et clés autorisées SSH consultés. Dans une compromission réelle, cela permet le cassage de mots de passe hors ligne et un accès persistant par backdoor SSH.

6.3 Reconnaissance réseau```bash

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

Port scan de la passerelle du laboratoire (`172.66.66.1`, ports 100-8000) exécuté depuis le contexte root à 12:51 CEST. Cela démontre une capacité de mouvement latéral et de cartographie réseau à partir d'une session escaladée.

![Network scan from root - nc against gateway](https://assets.kitploit.com/production/public/readmes/15419/350b4904ab94e991640582b63d0bc61c679c754fdce22b856bb92ab177a02ef5.png)

#### 6.4 Visibilité réseau Suricata

Suricata a capturé **105 événements** associés à `172.66.66.27` pendant la fenêtre d'exercice (88 mdns, 17 flow). Au moment où la capture d'écran a été prise (pendant le scan nc vers ~12:53 CEST), 29 événements étaient visibles dans le tableau de bord.

L'exploit DirtyFrag lui-même est interne au noyau et ne produit aucune signature réseau - la primitive d'escalade ne génère aucun trafic anormal sur le fil. Suricata a été utilisé pour collecter des pcaps du trafic post-exploitation et des tentatives d'énumération plutôt que pour détecter l'exploit lui-même.

| Type d'événement | Nombre |
| ---------- | ----- |
| mdns | 88 |
| flow | 17 |
| **Total** | **105** |

Les événements flow se regroupent autour de la fenêtre de scan de port nc (10:50-11:10 UTC / 12:50-13:10 CEST).

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

---

### 7. Phase 4 - Ingénierie de détection

#### 7.1 Règles de détection déployées

Deux règles de séquence EQL ont été créées dans le moteur de détection Kibana, basées sur l'article d'Elastic Security Labs.

**Règle 1 - Socket AF_RXRPC ou AF_ALG avec Splice suivi d'une exécution (n'a pas déclenché - voir l'écart ci-dessous)**```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

Règle 2 - Manipulation de l'espace de noms suivie d'une escalade de privilèges (déclenché après correction)```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 Écart de détection initial - Couverture manquante des appels système

La règle 1 n'a retourné aucun résultat. La configuration par défaut d'auditd sur `ubuntu-vuln` a capturé : `write`, `bpf`, `openat`, `unshare` uniquement.

Manquants : `socket`, `splice`, `bind` - les primitives d'exploitation principales.

**Remédiation :** Ajouté à `/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 nouveaux événements auditd sont arrivés dans Elasticsearch en quelques secondes après l'exécution de l'exploit.

7.3 Écart de corrélation EQL - Fragmentation de l'arborescence des processus

Bien que les événements aient été capturés, la règle 2 n'a renvoyé aucune correspondance.

Cause racine - arborescence réelle des processus (depuis Elasticsearch) :

La règle d'origine corrélait par process.parent.pid. L'événement unshare avait ppid=4326, mais le shell root avait un parent différent - DirtyFrag effectue un fork de processus intermédiaires, brisant la corrélation.

Correctif : Corréler par auditd.session. Tous les événements de la chaîne d'exploitation partageaient session=2, reliant correctement la séquence quelle que soit la profondeur de fork.

7.4 Résultat de l'alerte

3 alertes de sévérité ÉLEVÉE, score de risque 73, dans Kibana Security - Alertes à 2026-05-24T10:25:57Z UTC (12:25:57 CEST).

• Règle : DirtyFrag - Manipulation de Namespace suivie d'une escalade de privilèges
• Sévérité : Haute
• Score de risque : 73
• Hôte : ubuntu-vuln

8. Référence de détection

Correspondance MITRE ATT&CK

Valeurs clés des appels système

Requêtes de référence KQL

Tous les événements auditd liés à dirtyfrag :```kql data_stream.dataset: "auditd_manager.auditd" and auditd.summary.how: dirtyfrag

**Namespace manipulation by non-root:**```kql
data_stream.dataset: "auditd_manager.auditd" and auditd.data.syscall: "unshare" and auditd.data.a0: "50000000"

Activité root post-élévation dans la même session :```kql data_stream.dataset: "auditd_manager.auditd" and user.id: "0" and auditd.session: "2"

**Tous les événements auditd pendant la fenêtre d'exploitation :**```kql
data_stream.dataset: "auditd_manager.auditd" and @timestamp >= "2026-05-24T10:20:00Z" and @timestamp <= "2026-05-24T10:30:00Z"

Socket et splice syscalls depuis le processus d'exploit :```kql data_stream.dataset: "auditd_manager.auditd" and auditd.summary.how: "/tmp/exp/clean_frag"

### 9. Résumé des conclusions clés

| # | Constat | Gravité | Corrigé |
| - | ------- | -------- | ---------- |
| 1 | Les règles auditd par défaut manquent `socket`, `splice`, `unshare` - aucune preuve sans règles explicites | Critique | Oui - règles personnalisées déployées dans `/etc/audit/rules.d/dirtyfrag.rules` |
| 2 | La corrélation EQL par `process.parent.pid` échoue pour les chaînes d'exploitation bifurquées | Élevée | Oui - changé en `auditd.session` |
| 3 | La surveillance de l'intégrité des fichiers aveugle à DirtyFrag - les fichiers sur disque inchangés tout au long | Élevée | Aucune correction dans le périmètre - corriger le noyau est la solution |
| 4 | Post-exploitation : fichier shadow, clés SSH et reconnaissance réseau tous exécutés en tant que root avant toute réponse basée sur les alertes | Élevée | Détecté via les logs auditd ; aucune règle dédiée déclenchée pour l'accès aux identifiants ou la phase de reconnaissance |

---

### 10. Références

- Elastic Security Labs: [Copy Fail et DirtyFrag : Bugs de pages Linux dans la nature](https://www.elastic.co/security-labs/copy-fail-dirtyfrag-linux-page-bugs-in-the-wild)
- PoC public : [V4bel/dirtyfrag sur GitHub](https://github.com/V4bel/dirtyfrag)
- MITRE ATT&CK : [T1068 - Exploitation pour l'élévation de privilèges](https://attack.mitre.org/techniques/T1068/)
- MITRE ATT&CK : [TA0004 - Élévation de privilèges](https://attack.mitre.org/tactics/TA0004/)
- MITRE ATT&CK : [T1003.008 - /etc/passwd et /etc/shadow](https://attack.mitre.org/techniques/T1003/008/)