DirtyFrag (CVE-2026-43284) – Bericht zur Lab-Erkennungsübung

Klassifikation: Internes Lab – CyberLAB
Datum: 24. Mai 2026
Plattform: Elastic Stack v9.4.1
Status: Erkennung bestätigt

Inhaltsverzeichnis

• A – Zusammenfassung der Geschäftsleitung
• B – Ausführlicher Ergebnisbericht
  • 1. Zielsetzung und Bedrohungsmodell
  • 2. Hintergrund der Schwachstelle
  • 3. Laborumgebung
  • 4. Phase 1 – Vorbereitung vor der Ausführung
  • 5. Phase 2 – Exploit-Ausführung
  • 6. Phase 3 – Aktivitäten nach der Exploitation
  • 7. Phase 4 – Detection Engineering
  • 8. Erkennungsreferenz
  • 9. Zusammenfassung der wichtigsten Erkenntnisse
  • 10. Referenzen

A – Zusammenfassung der Geschäftsleitung

Was getestet wurde

Eine kontrollierte Exploitation-Übung, die einen Gegner nach dem ersten Zugriff simuliert, der DirtyFrag (CVE-2026-43284), eine Linux-Kernel-Privilegieneskalations-Schwachstelle, einsetzt. Das simulierte Angreiferszenario: ein niedrig privilegierter Benutzer (saskia, uid=1001), der über Phishing-Anmeldedaten erlangt wurde, versucht, auf Root zu eskalieren auf einem internen Linux-Host. Das Labor verwendete eine absichtlich anfällige Ubuntu-Maschine (ubuntu-vuln, Kernel 6.0.0-22-generic), isoliert von Produktionsnetzwerken.

Ergebnis: Exploitation erfolgreich – Erkennung bestätigt

Der Angreifer erlangte vollen Root-Zugriff (uid=0) in der Laborumgebung. Der Elastic Security Erkennungsstack generierte 3 Alarmmeldungen mit hohem Schweregrad (Risikoscore 73) und identifizierte korrekt die Exploitation-Kette. Allerdings erforderte die Erkennung manuelle Anpassungen – die Standardkonfiguration hatte Lücken, die zu verpassten Alarmen geführt hätten.

Fazit: Nicht gepatchte Linux-Hosts mit Kernel <= 6.x sind angreifbar. Wenn ein Angreifer bereits einen niedrig privilegierten Zugang hat, verschafft dieser Exploit ihnen schnell und lautlos vollen Root-Zugriff, ohne dass eine on-disk Spur für Dateiintegritätstools sichtbar ist.

Risikobewertung

Wichtigste Erkenntnisse

1. Standard-auditd-Regeln erzeugen keine Beweise. Ohne explizite Syscall-Regeln für socket, splice und unshare läuft der Exploit lautlos ab – keine Logs, keine Alarme. Die Standard-Bereitstellung des Elastic Agents fügt diese Regeln nicht automatisch hinzu.
2. Erkennung erforderte Regel-Anpassung. Die veröffentlichte Erkennungslogik von Elastic Security Labs verwendete process.parent.pid als Korrelationsschlüssel. In der Praxis erzeugt DirtyFrag Zwischenprozesse, was diese Korrelation aufhebt. Die Lösung – Korrelation über auditd.session – wurde während dieser Übung identifiziert und implementiert.
3. Aktivitäten nach der Exploitation waren umfangreich. Nach Erlangen von Root las der Angreifer /etc/shadow aus, griff auf SSH-Authorized-Keys zu, schrieb einen Persistenz-Marker (/root/pwned.txt) und leitete Netzwerkerkundung über nc ein. All dies geschah innerhalb von 30 Minuten nach dem ersten Zugriff.

Empfehlungen

B – Ausführlicher Ergebnisbericht

1. Zielsetzung und Bedrohungsmodell

Zielsetzung: Validierung der Erkennungsabdeckung für DirtyFrag-Exploitation im Heimlabor-SOC, Identifizierung von Erkennungslücken und Erstellung einer korrigierten Erkennungsregel basierend auf beobachtetem Angreiferverhalten.

Bedrohungsmodell: Simulierter Gegner nach erstem Zugriff mit Phishing-Anmeldedaten für ein niedrig privilegiertes Benutzerkonto (saskia, uid=1001). Ziel: Privilegieneskalation zu Root über DirtyFrag unter Verwendung des xfrm-ESP-Empfangspfads. Die Laborausführung erfolgte über die Proxmox-Konsole – funktional äquivalent zu SSH nach Zugriff.

Es wurden zwei Fähigkeitsstufen des Angreifers betrachtet:

• Vanilla (laut): Exploit ohne Ausweichmaßnahmen ausgeführt
• Evasiv (leise): reduzierte Geräuschentwicklung, bewusste Bereinigung

Diese Übung deckte die Vanilla-Stufe ab.

2. Hintergrund der Schwachstelle

DirtyFrag ist der dritte in einer Familie verwandter Linux-Kernel-Fehler, die alle die gleiche Grundursache missbrauchen:

Grundursache: IPv4/IPv6-Datagramm-Anhängepfade setzten SKBFL_SHARED_FRAG nicht, nachdem skb_splice_from_iter() eine Page-Cache-Seite in einen Socket-Puffer (sk_buff) eingefügt hatte. Der ESP-Eingangspfad führte dann In-Place-Kryptografie auf vom Angreifer kontrollierten Page-Cache-Seiten durch und behandelte sie als gewöhnliche ungeklonte nicht-lineare skbs.

Exploit-Primitive: Kontrollierter 4- oder 8-Byte-Schreibzugriff in den Page-Cache. Deterministisch – keine Race-Condition erforderlich.

Exploit-Kette:

1. Der Angreifer liest eine Zielbinärdatei (z. B. /usr/bin/su) in den Page-Cache
2. Konstruiert ein Paket über splice(), sodass die Seite der Datei in frag[0] von struct sk_buff liegt
3. Kernel liefert das Paket an den xfrm-ESP-Entschlüsselungspfad
4. ESP führt In-Place-Kryptografie durch – Quelle und Ziel zeigen beide auf die Seite des Angreifers
5. Kryptografie schreibt vom Angreifer kontrollierte Bytes in den Page-Cache
6. Alle nachfolgenden Lesevorgänge der Datei – einschließlich des Kernel-execve() – geben korrupte Bytes zurück

Kritische Ausweicheigenschaft: Die Datei auf der Festplatte wird nie verändert. Dateiintegritätsüberwachungstools (AIDE, Tripwire, Hash-Prüfungen) melden alle die Zieldatei als sauber.

Bestätigte anfällige Distributionen: Ubuntu 24.04.4, RHEL 10.1, AlmaLinux 10, openSUSE Tumbleweed, CentOS Stream 10, Fedora 44.

3. Laborumgebung

Aktive Telemetrie zum Zeitpunkt der Übung:

4. Phase 1 – Vorbereitung vor der Ausführung

4.1 Lab-Isolation

Lab-Netzwerk vor der Übung isoliert. Firewall-Alias Cyber_escape_door als deaktiviert bestätigt – verhindert seitliche Reichweite zu anderen VLANs oder dem Internet.

4.2 Überprüfung des Zielhosts

Bestätigt anfälligen Kernel und niedrig privilegierten Account auf 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)

![Kernel- und Benutzer-Überprüfung](https://assets.kitploit.com/production/public/readmes/15419/bd607abf9c63cc6bf7cfd3432bd406c5fcd51b6e29e4585543f80af99218fd92.png)

#### 4.3 Stack Health Check

**Suricata: läuft und erfasst (systemctl status)**
![Suricata-Dienst aktiv und aktiviert](https://assets.kitploit.com/production/public/readmes/15419/3bd0f2a2eb3695861aa36f58545b85567d3a8bdeb4e847060e9dbb63391abf9b.png)

**Kibana/Elasticsearch: grün/gesund (API-Überprüfung)**
![ELK-Health-Check via curl mit Rückgabe 302](https://assets.kitploit.com/production/public/readmes/15419/fcd860faf9fbe62adeb94e889ced2a8c4b649f7240b9f7a9eb572a132c56402d.png)

**VM-Snapshots vor jeglichen Änderungen erstellt**

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

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

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

#### 4.4 Netzwerk-Erfassung
tcpdump auf Suricata-Host gestartet (`emp6s19`, Snapshot-Länge 262144 Bytes) zur vollständigen Paketerfassung des Verkehrs von `172.66.66.27`.
![Kopie der suricata-Verkehrsereignisse](https://assets.kitploit.com/production/public/readmes/15419/12c4e8bd2f5749a5ff3afda1613fecf69d635fbb87003808d83cc89815430e3c.png)

![tcpdump auf Suricata-Sensor gestartet](https://assets.kitploit.com/production/public/readmes/15419/09e4a4ab1a4f692ee24f168c2094bf159590b9c6bb4ea8a977f0c004687ae341.png)

---

### 5. Phase 2 – Exploit-Ausführung

#### 5.1 Staging

Exploit-Quellcode (`exp.c`) aus dem V4bel/dirtyfrag PoC auf dem Opfer-Host bereitgestellt.```bash
ubuntu-vuln@ubuntu-vuln:~/dirtyfrag$ ls
exp  exp.c  README.md
ubuntu-vuln@ubuntu-vuln:~/dirtyfrag$ cp exp.c /tmp/exp/

Das rechte Terminal zeigt die bereitgestellte Kopie, die für Benutzer saskia sichtbar ist.

5.2 Kompilierung

Kompiliert als root mit sudo gcc (Benutzer saskia ist in 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 kompiliert - clean_frag Binärdatei bereit](https://assets.kitploit.com/production/public/readmes/15419/0449b71e0aa5ab6acc1483dc1109e40a59108fe2fb1c438413daa05e3e8c4f3c.png)

#### 5.3 Ausführung - Root erlangt

Exploit ausgeführt als `saskia` (uid=1001). Der Prozess (`clean_frag`, pid=4326) öffnete `AF_RXRPC`- und `AF_ALG`-Sockets und rief dann `splice()` auf, um die Page-Cache-Seite in den Netzwerkpuffer zu pflanzen. Die In-Place-Verschlüsselung auf dem ESP-Pfad schrieb vom Angreifer kontrollierte Bytes in den Page-Cache. Ein Kindprozess (pid=4327) rief `unshare` mit `a0=50000000` (CLONE_NEWUSER | CLONE_NEWNET) auf, um namespace-begrenzte Capabilities zu erlangen.```
saskia@ubuntu-vuln:~$ /tmp/exp/clean_frag
...
root@ubuntu-vuln:~# id
uid=0(root) gid=0(root) groups=0(root)
root@ubuntu-vuln:~# ls

Vollständige Root-Shell erlangt um 12:22 MESZ (10:22 UTC), 24. Mai 2026.

Erfasste Auditd-Syscall-Sequenz (UTC):

Alle Ereignisse teilen sich auditd.session=2.

6. Phase 3 – Aktivitäten nach der Ausnutzung

Alle Aktionen als root auf ubuntu-vuln ab etwa 12:22 MESZ ausgeführt.

6.1 Persistenzmarker```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

![Persistenzmarker geschrieben in /root/pwned.txt](https://assets.kitploit.com/production/public/readmes/15419/a4c9f7d5eaf9f165aa382692c89c6e98c50884858bae6929aec9251bb09ba06e.png)

#### 6.2 Zugriff auf Anmeldeinformationen```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[...]

Shadow-Datei und SSH-authorisierte Schlüssel abgerufen. Im Falle einer echten Kompromittierung ermöglicht dies Offline-Passwort-Cracking und dauerhaften SSH-Backdoor-Zugriff.

6.3 Netzwerk-Erkundung```bash

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

Portscan des Lab-Gateways (`172.66.66.1`, Ports 100-8000), ausgeführt aus dem Root-Kontext um 12:51 MESZ. Dies demonstriert die Fähigkeit zur lateralen Bewegung und Netzwerkkartierung von einer eskalierten Sitzung aus.

![Netzwerkscan von Root - nc gegen Gateway](https://assets.kitploit.com/production/public/readmes/15419/350b4904ab94e991640582b63d0bc61c679c754fdce22b856bb92ab177a02ef5.png)

#### 6.4 Suricata-Netzwerksichtbarkeit

Suricata erfasste **105 Ereignisse** im Zusammenhang mit `172.66.66.27` während des Übungszeitraums (88 mdns, 17 flow). Zum Zeitpunkt der Aufnahme des Screenshots (während des nc-Scans um ~12:53 MESZ) waren 29 Ereignisse im Dashboard sichtbar.

Der DirtyFrag-Exploit selbst ist kernel-intern und erzeugt keine Netzwerksignatur – die Eskalationsprimitive generiert keinen anomalen Datenverkehr auf der Leitung. Suricata wurde eingesetzt, um PCAPs des Post-Exploitation-Traffics und von Aufklärungsversuchen zu sammeln, anstatt den Exploit selbst zu erkennen.

| Ereignistyp | Anzahl |
| ----------- | ------ |
| mdns | 88 |
| flow | 17 |
| **Gesamt** | **105** |

Die Flow-Ereignisse häufen sich um das nc-Portscan-Fenster (10:50-11:10 UTC / 12:50-13:10 MESZ).

![Suricata-Ereignisse für 172.66.66.27](https://assets.kitploit.com/production/public/readmes/15419/de8249b1c4230a57841799e7806ca97796db4de2321a57c0891f043d842c54b0.png)

---

### 7. Phase 4 - Detection Engineering

#### 7.1 Bereitgestellte Erkennungsregeln

Es wurden zwei EQL-Sequenzregeln in der Kibana-Detection-Engine basierend auf dem Artikel von Elastic Security Labs erstellt.

**Regel 1 - AF_RXRPC oder AF_ALG Socket mit Splice gefolgt von Execution** (hat nicht ausgelöst - siehe Lücke unten)```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

Regel 2 - Namespace-Manipulation gefolgt von Privilege-Eskalation (nach Fix ausgelöst)```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 Erkennungslücke initial - Fehlende Syscall-Abdeckung

Regel 1 lieferte null Ergebnisse. Die Standard-Auditd-Konfiguration auf `ubuntu-vuln` erfasste nur: `write`, `bpf`, `openat`, `unshare`.

Fehlend: `socket`, `splice`, `bind` - die zentralen Exploit-Primitiven.

**Abhilfe:** Hinzugefügt zu `/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 neue auditd-Ereignisse landeten innerhalb von Sekunden nach der Exploit-Ausführung in Elasticsearch.

7.3 EQL-Korrelationslücke - Fragmentierung des Prozessbaums

Obwohl Ereignisse erfasst wurden, lieferte Regel 2 0 Treffer.

Grundursache - tatsächlicher Prozessbaum (aus Elasticsearch):

Die ursprüngliche Regel korrelierte anhand von process.parent.pid. Das unshare-Ereignis hatte ppid=4326, aber die Root-Shell hatte einen anderen Elternprozess – DirtyFrag forkt Zwischenprozesse, was die Korrelation unterbricht.

Behebung: Korrelation anhand von auditd.session. Alle Ereignisse in der Exploit-Kette teilten session=2, was die Sequenz unabhängig von der Fork-Tiefe korrekt verknüpft.

7.4 Alarm-Ergebnis

3 Alarme mit hohem Schweregrad, Risikoscore 73, in Kibana Security – Alarme um 2026-05-24T10:25:57Z UTC (12:25:57 MESZ).

• Regel: DirtyFrag - Namespace Manipulation Followed by Privilege Escalation
• Schweregrad: Hoch
• Risikoscore: 73
• Host: ubuntu-vuln

8. Erkennungsreferenz

MITRE ATT&CK-Zuordnung

Wichtige Syscall-Werte

KQL-Referenzabfragen

Alle dirtyfrag-bezogenen auditd-Ereignisse:```kql data_stream.dataset: "auditd_manager.auditd" and auditd.summary.how: dirtyfrag

**Namespace-Manipulation durch Nicht-Root:**```kql
data_stream.dataset: "auditd_manager.auditd" and auditd.data.syscall: "unshare" and auditd.data.a0: "50000000"

Root-Aktivität nach Eskalation in derselben Sitzung:```kql data_stream.dataset: "auditd_manager.auditd" and user.id: "0" and auditd.session: "2"

**Alle auditd-Ereignisse während des Exploit-Fensters:**```kql
data_stream.dataset: "auditd_manager.auditd" and @timestamp >= "2026-05-24T10:20:00Z" and @timestamp <= "2026-05-24T10:30:00Z"

Socket- und Splice-Systemaufrufe vom Exploit-Prozess:```kql data_stream.dataset: "auditd_manager.auditd" and auditd.summary.how: "/tmp/exp/clean_frag"

---

### 9. Zusammenfassung der wichtigsten Erkenntnisse

| # | Erkenntnis | Schweregrad | Behoben |
| - | ---------- | ----------- | ------- |
| 1 | Standard-auditd-Regeln übersehen `socket`, `splice`, `unshare` – keine Beweise ohne explizite Regeln | Kritisch | Ja – benutzerdefinierte Regeln in `/etc/audit/rules.d/dirtyfrag.rules` bereitgestellt |
| 2 | EQL-Korrelation mittels `process.parent.pid` schlägt bei gegabelten Exploit-Ketten fehl | Hoch | Ja – geändert auf `auditd.session` |
| 3 | Dateiintegritätsüberwachung blind gegenüber DirtyFrag – Dateien auf der Festplatte bleiben während des gesamten Vorgangs unverändert | Hoch | Keine Behebung im Rahmen – Kernel-Patch ist die Lösung |
| 4 | Post-Exploitation: shadow-Datei, SSH-Schlüssel und Netzwerkerkundung – alles als root ausgeführt, bevor eine alarmgesteuerte Reaktion erfolgte | Hoch | Erkannt über auditd-Protokolle; keine spezielle Regel für Zugriff auf Anmeldedaten oder Aufklärungsphase ausgelöst |

---

### 10. Referenzen

- Elastic Security Labs: [Copy Fail und DirtyFrag: Linux-Seitenfehler in freier Wildbahn](https://www.elastic.co/security-labs/copy-fail-dirtyfrag-linux-page-bugs-in-the-wild)
- Öffentlicher PoC: [V4bel/dirtyfrag auf GitHub](https://github.com/V4bel/dirtyfrag)
- MITRE ATT&CK: [T1068 – Ausnutzung zur Rechteausweitung](https://attack.mitre.org/techniques/T1068/)
- MITRE ATT&CK: [TA0004 – Rechteausweitung](https://attack.mitre.org/tactics/TA0004/)
- MITRE ATT&CK: [T1003.008 – /etc/passwd und /etc/shadow](https://attack.mitre.org/techniques/T1003/008/)