In-the-Wild: Waffenisierte Ketten, Honeypot-Telemetrie und echte Angriffsanalysen
In-the-Wild: Waffenisierte Ketten, Honeypot-Telemetrie und echte Angriffsanalysen
<time datetime="2026-10-23">Geprüft am 23. Oktober 2026</time>
Innerhalb von 48 Stunden nach Veröffentlichung von CVE-2026-109618 und CVE-2026-109619 wurden automatisierte Scans und erste Waffenierungsversuche beobachtet. Dieser Artikel fasst Telemetrie aus Honeypots in Frankfurt und Silicon Valley zusammen und analysiert, welche Abkürzungen Angreifer genommen haben. IP-Adressen und Domains sind maskiert. Die Daten dienen der Verteidigung und der Verbesserung von Erkennungsregeln.
1. Reale Angriffssequenz
T+0s [ Aufklärung ] nicht-randomisierte Scans: /index.php, /login,
/.env, /wp-login.php
└─ Ziel ist der Multipart-Parser, der vor dem Routing läuft
T+3s [ Grooming ] 12–30 kleine Multipart-POSTs
└─ ZMM-Bins ausrichten, PHP_SESSION_UPLOAD_PROGRESS senden
T+8s [ Trigger ] Session-Reset erzwingen, Fake-zval überschreiben
└─ ein bis zwei Worker-SIGSEGV, äußerlich wie 502/504
T+12s [ Ausführung ] sh -c "curl ... | sh" unter www-data
└─ anschließend ausgehende C2-Verbindung
T+20s [ Etablierung ] Webshell oder Reverse Shell, Rechteausweitung
Die meisten beobachteten Requests blieben unter 500 Byte. Auffällig war, dass User-Agent-Strings oft von echten Browsern kopiert wurden, während TLS-Fingerabdrücke und Header-Reihenfolge die Automatisierung verrieten. Für die Erkennung ist die Kombination aus kleinem Body, wiederholtem Multipart und Worker-Absturz deutlich aussagekräftiger als der User-Agent.
2. Drei Abkürzungen der Angreifer
2.1 Kurze Bursts gegen Concurrency-Jitter
Damit zwei Requests im selben Worker landen, muss das Timing stimmen. Angreifer senden daher 12 bis 30 Requests innerhalb weniger Sekunden. Das erhöht die Wahrscheinlichkeit der Worker-Wiederverwendung erheblich.
# Burst-Erkennung
sudo awk '{print $1}' /var/log/nginx/access.log | \
sort | uniq -c | sort -rn | head -20
2.2 Vorberechnete Offset-Tabellen
Viele Versuche zielten auf Ubuntu 22.04/24.04, Debian 12 und die offiziellen php:8.2/8.3-fpm-Images. Deren libc- und PHP-Builds sind öffentlich bekannt; Angreifer berechnen die Offsets vorab und überspringen die Informationsleck-Phase.
docker run --rm php:8.3-fpm sh -c 'ldd --version | head -1'
docker run --rm php:8.3-fpm php -i | grep -E 'Build Date|Configure Command'
2.3 Kompression ohne Leerzeichen
Shell-Befehle werden mit $IFS oder ${IFS} statt Leerzeichen formatiert, um einfache String-Signaturen zu umgehen.
grep -E '\$\{?IFS\}?|base64 -d|/dev/tcp/|curl.*\|.*sh' /var/log/nginx/access.log
Diese Technik ist nicht neu, aber wirkungsvoll gegen Regelwerke, die auf exakte Befehlsfolgen prüfen.
3. Typische Fallstricke der Incident-Analyse
Fallstrick 1: Normale Nginx-Logs enthalten nichts Verdächtiges
Die Requests sehen wie gewöhnliche POSTs aus; Statuscodes sind 200, 404 oder 413. Der Body wird standardmäßig nicht protokolliert, und die Kompromittierung erfolgt vor dem Benutzercode. Deshalb braucht es Body-Mirroring für ausgewählte Pfade, FPM-Slow-Logs und Worker-Neustart-Events.
location ~ \.php$ {
mirror /mirror;
mirror_request_body on;
}
location = /mirror {
internal;
proxy_pass http://127.0.0.1:9001$request_uri;
}
Body-Mirroring kann personenbezogene Daten und Zugangsdaten erfassen. Prüfen Sie Datenschutz, Aufbewahrungsfristen und Zugriffsrechte, bevor Sie es aktivieren.
Fallstrick 2: Nur auf Egress-Firewalls vertrauen
Angreifer nutzen DNS-Tunneling, HTTPS-C2 und legitime Cloud-Speicher. Egress-Filter sind notwendig, aber nicht ausreichend. Die Prozessausführung selbst muss beobachtet werden – etwa mit Falco oder Tetragon.
Fallstrick 3: Worker-Neustarts als normale Störung abtun
FPM startet abgestürzte Worker automatisch neu. Ohne Monitoring fällt das nicht auf. Setzen Sie emergency_restart_threshold, aktivieren Sie Core-Dumps kontrolliert und nehmen Sie die Neustartrate in das Alerting auf.
emergency_restart_threshold = 5
emergency_restart_interval = 1m
sudo systemctl edit php8.3-fpm
# [Service]
# LimitCORE=infinity
Core-Dumps können sensible Daten enthalten. Verschlüsseln Sie sie und beschränken Sie den Zugriff auf das Incident-Response-Team.
4. Telemetrie-Metriken und Angriffsökonomie
Für die Bewertung der Bedrohungslage sind nicht nur einzelne Requests interessant, sondern Verteilungen. In den Honeypots wurden folgende Muster sichtbar: Die mediane Body-Größe lag bei 412 Byte, das 95-Perzentil bei 690 Byte. Die Zahl der Requests pro Quelle und Minute erreichte Spitzenwerte von 38 während der ersten Scan-Welle und flachte danach auf 4 bis 7 ab. Die Zielpfade waren zu 61 Prozent generische Pfade wie /index.php und /, zu 22 Prozent Login- und Admin-Oberflächen und zu 17 Prozent zufällig gewählte, oft nicht existierende Pfade.
Diese Verteilung ist für die Kalibrierung von Regeln nützlich. Ein Schwellwert, der auf dem 95-Perzentil des Normalverkehrs basiert, erzeugt weniger Fehlalarme als ein fester Wert. Gleichzeitig zeigt die breite Streuung der Zielpfade, dass Whitelisting einzelner URLs nicht ausreicht. Sinnvoller ist die Kombination aus Content-Type, Feldname und Body-Größe, ergänzt um die Korrelation mit Worker-Ereignissen.
Die Angriffsökonomie erklärt die Geschwindigkeit der Welle. Ein automatisierter Scanner benötigt nur eine Liste erreichbarer Hosts und ein bekanntes Offsetset. Die Kosten pro Ziel liegen im Cent-Bereich; der potenzielle Ertrag – Zugriff auf Datenbanken, Kreditkartendaten oder Rechenressourcen – ist um Größenordnungen höher. Deshalb ist damit zu rechnen, dass die Welle nicht abreißt, sondern sich auf weitere Regionen und Hosting-Anbieter ausdehnt. Wer seine PHP-Laufzeiten nicht inventarisiert hat, wird von der zweiten Welle überrascht.
Für das Reporting empfiehlt sich eine einfache Ampel: Systeme mit gepatchter Version und deaktiviertem Callback sind grün, Systeme mit Patch aber ohne Deaktivierung gelb, Systeme ohne Patch und ohne Mitigation rot. Diese Klassifikation ist technisch nicht perfekt, aber sie macht Priorisierung im Management sichtbar und verhindert, dass einzelne Server vergessen werden.
5. Betreiber-FAQ
F1: Können Cloudflare oder Edge-CDN diese Angriffe stoppen? Teilweise. Edge-WAFs helfen bei bekannten Signaturen und Rate-Limits, sind aber gegen 450-Byte-Multipart-Payloads und Kodierungsvarianten strukturell im Nachteil. Sie kaufen Zeit; die dauerhafte Lösung ist der PHP-Patch.
F2: Wie prüfe ich schnell, ob ein Server kompromittiert wurde?
php -v
dpkg -l | grep -E '^ii\s+php' || rpm -qa | grep -i '^php'
find /var/www /tmp /dev/shm -type f -mtime -2 -perm -u+x -ls 2>/dev/null
ps -eo pid,user,cmd | awk '$2=="www-data"||$2=="nginx"'
ss -tpn | grep -E 'www-data|php-fpm'
F3: Wie übertrage ich Honeypot-Telemetrie auf meine Umgebung? Übernehmen Sie die Struktur der Requests – Pfad, Body-Größe, Feldname, Burst-Intervall – und übersetzen Sie sie in Suricata- und Falco-Regeln. Starten Sie im Alert-Modus, messen Sie Fehlalarme und schalten Sie erst dann auf Blockieren.
F4: Was ist nach einer erfolgreichen Kompromittierung zuerst zu tun?
Worker oder Container isolieren, Speicherabbild sichern, Session-Store und Anmeldedaten rotieren, session.upload_progress.enabled=Off setzen und auf eine gepatchte Version aktualisieren. Anschließend Egress-Logs und DNS-Abfragen für die Reichweitenanalyse auswerten.
6. Bewertung der Bedrohungslage
Die beobachteten Ketten sind weniger „raffinierte Zero-Days“ als vielmehr automatisierte Varianten bekannter Speicherkorruptionsmuster. Die Kosten für den Angreifer sind niedrig, der potenzielle Gewinn hoch – deshalb beginnen Scans oft innerhalb von Stunden nach der Veröffentlichung. Betreiber sollten die Priorität nicht an der Komplexität des Exploits festmachen, sondern an der Exposition: Jeder nicht gepatchte PHP-Worker mit aktivem Upload-Progress-Callback ist ein potenzielles Ziel.
Hinzu kommt ein struktureller Effekt: Weil die Schwachstelle im Kern liegt, hilft es nicht, nur die eigene Anwendung zu härten. Frameworks, Content-Management-Systeme und selbstgeschriebene APIs teilen dieselbe Engine. Ein Patch-Window von mehreren Wochen ist deshalb kein rein internes Risiko, sondern ein Risiko für alle Mandanten und Kunden, die auf derselben Laufzeit betrieben werden. Wer Hosting anbietet, sollte den Patchstand pro vHost nachweisen können.
Zusätzlich sollten Betreiber die Ergebnisse dieser Nachweise in einem zentralen Dashboard zusammenführen und quartalsweise überprüfen. Für das Patch-Management bedeutet das, PHP-Laufzeiten als eigene Asset-Klasse zu behandeln. Für das Monitoring bedeutet es, Netzwerk-, Runtime- und Kernel-Signale zu korrelieren. Und für die Incident-Response bedeutet es, Core-Dumps, Logs und Session-Daten frühzeitig zu sichern, bevor automatisierte Neustarts die Spuren verwischen.
7. Fazit
- Die Kompromittierung erfolgt vor dem Anwendungscode; klassische Access-Logs genügen nicht.
- Angreifer nutzen Bursts, vorberechnete Offsets und Shell-Kompression.
- Worker-Neustarts sind ein unterschätztes Signal.
- Patch auf 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 und Deaktivierung des Callbacks bleiben die wirksamsten Maßnahmen.
Honeypot-Daten werden ausschließlich für Verteidigungsforschung verwendet. Angreiferinfrastruktur wird nicht offengelegt.