PoisonedRefresh: Linux-Rootkit kompromittiert F5 BIG-IP APM Webtop
SophosLabs hat im September 2026 das Linux-Rootkit PoisonedRefresh untersucht, das F5 BIG-IP APM Webtop-Umgebungen kompromittiert. Die Erkennung läuft unter Linux/Agnt-IC. Das Rootkit injiziert eine PHP-Webshell ausschließlich im Arbeitsspeicher, während die Dateien auf der Festplatte unverändert bleiben. Presseberichte verknüpfen die Kampagne mit CVE-2025-53521, einer unauthentifizierten RCE-Lücke in BIG-IP APM.
SophosLabs hat im September 2026 ein neuartiges Linux-Rootkit mit dem Namen PoisonedRefresh analysiert, das gezielt F5 BIG-IP APM Webtop-Umgebungen kompromittiert. Die Erkennung läuft unter der Signatur Linux/Agnt-IC. Betroffen sind laut Berichten die Branches 15.1.x, 16.1.x, 17.1.x und 17.5.x, während die Versionen 15.1.10.8, 16.1.6.1, 17.1.3 und 17.5.1.3 bereits gepatcht sind. Der Angriffspfad wird in Presseberichten mit CVE-2025-53521 in Verbindung gebracht, einer unauthentifizierten Remote-Code-Execution-Lücke in BIG-IP APM bei gebundener Access Policy. Ein direkter Nachweis dieser Verknüpfung im offiziellen F5-Advisory wurde von uns nicht eingesehen, weshalb dieser Zusammenhang ausdrücklich als laut Berichten gekennzeichnet wird. Gesichert ist hingegen die technische Analyse von SophosLabs zum Rootkit selbst. Angesichts der unauthentifizierten Ausnutzbarkeit und der aktiven Kampagne besteht dringender Handlungsbedarf für Betreiber von BIG-IP APM Systemen mit Internetexposition.
Das Besondere an PoisonedRefresh ist die rein speicherresidente Arbeitsweise. Das Rootkit injiziert eine PHP-Webshell ausschließlich im Arbeitsspeicher in die Dateien apm_css.php3, full_wt.php3 und webtop_popup_css.php3, ohne dass sich die Dateien auf der Festplatte verändern. Klassische Integritätsprüfungen, die nur Datei-Hashes auf Platte vergleichen, laufen damit ins Leere. Als erste Prüfung sollten Administratoren den Arbeitsspeicher laufender Apache-Worker-Prozesse mit dem Inhalt der genannten Dateien auf der Platte vergleichen, nach dem UNIX-Socket /run/bigtlog.pipe suchen und ungewöhnliche HTTP-201-Antworten vom Typ text/css im Zugriffsprotokoll prüfen. Sofortmaßnahmen umfassen die Sicherung flüchtiger Beweise vor einem Neustart, die Einspielung der gepatchten Versionen und die Minimierung der Internetexposition der Managementoberfläche.
Was ist PoisonedRefresh
PoisonedRefresh ist ein Linux-Rootkit, das speziell auf die Webtop-Komponente von F5 BIG-IP Access Policy Manager zugeschnitten ist. Der Name spielt auf die manipulierten CSS- und Webtop-Popup-Dateien an, die im laufenden Betrieb refresh-artig neu bestückt werden. SophosLabs stufte die Bedrohung als technisch anspruchsvoll ein, da sie tief in den PHP-Interpreter des Apache-Webservers eingreift, statt einfach eine zusätzliche Datei auf der Platte abzulegen. Die Erkennungssignatur lautet Linux/Agnt-IC. Eine konkrete Akteurszuordnung liegt bislang nicht vor und wird in diesem Artikel bewusst nicht vorgenommen.
Technische Funktionsweise der Webshell
Die injizierte PHP-Webshell arbeitet nach einem klaren Schema. Sie liest den Rohkörper eingehender HTTP-Anfragen über php://input aus und erwartet dort ein Magic-Präfix mit dem Wert BSOHAzPB. Liegt dieses Präfix vor, entschlüsselt die Webshell den nachfolgenden Payload und führt ihn über die PHP-Funktion eval() aus. Die Antwort an den Angreifer erfolgt mit dem HTTP-Statuscode 201 und dem Content-Type text/css, wodurch sich die Kommunikation optisch in den normalen Webtop-Datenverkehr einfügt und in oberflächlichen Log-Analysen kaum auffällt. Diese Tarnung als harmlose CSS-Antwort ist eines der zentralen Erkennungsmerkmale, auf das Sicherheitsteams gezielt achten sollten.
Der zusätzliche UNIX-Socket als Hintertür
Neben der PHP-Webshell legt das Rootkit einen zusätzlichen UNIX-Socket unter dem Pfad /run/bigtlog.pipe an. Nach erfolgreicher Prüfung eines Tokens startet dieser Socket eine Bash-Shell unter /bin/bash und stellt damit einen zweiten, von der Webshell unabhängigen Zugriffsweg bereit. Selbst wenn die PHP-Webshell entdeckt und entfernt würde, könnte ein Angreifer über diesen Socket weiterhin Systemzugriff erlangen, sofern der Socket selbst unentdeckt bleibt. Die Existenz dieses Sockets sollte bei jeder forensischen Untersuchung explizit geprüft werden.
Persistenzmechanismus und Manipulation des Speicherschutzes
PoisonedRefresh hookt die Funktion apr_dso_load und wartet darauf, dass die PHP-Laufzeitbibliothek libphp geladen wird. Sobald dieser Ladevorgang erfolgt, manipuliert das Rootkit temporär den Speicherschutz sowie interne PHP-Funktionsaufrufe, um die eigene Webshell-Logik in den laufenden Prozess einzuschleusen, ohne Dateien auf der Platte zu verändern. Der zugehörige Installer infiziert dabei die Datei /usr/sbin/httpd, nutzt den Pfad /mnt/tm_install zur dauerhaften Persistenz und verändert zudem die SELinux-Konfiguration, um die eigenen Aktivitäten vor Sicherheitsrichtlinien abzuschirmen. Wichtig für die Praxis: Ein einfacher Dienstneustart reicht allein nicht verlässlich aus, um das Rootkit vollständig zu entfernen, da die Persistenzkomponenten außerhalb des reinen Laufzeitspeichers verankert sind.
Bezug zu CVE-2025-53521
Mehrere Presseberichte, darunter Analysen von BleepingComputer, CybersecurityNews, GBHackers und Arctic Wolf, stellen einen Zusammenhang zwischen der PoisonedRefresh-Kampagne und der Sicherheitslücke CVE-2025-53521 her. Diese Lücke ermöglicht eine unauthentifizierte Remote-Code-Execution in BIG-IP APM, sofern eine Access Policy gebunden ist. Da wir das originale F5-Advisory zu dieser CVE nicht direkt einsehen konnten, stufen wir die Verbindung ausdrücklich als laut Berichten ein und nicht als eigenständig verifizierten Fakt. Betroffen sind demnach die Branches 15.1.x, 16.1.x, 17.1.x und 17.5.x, wobei die Versionen 15.1.10.8, 16.1.6.1, 17.1.3 und 17.5.1.3 die entsprechenden Fixes enthalten sollen.
Betroffene Versionen im Überblick
Die folgende Tabelle fasst die laut Berichten betroffenen Branches sowie die jeweils gepatchten Versionsstände zusammen. Administratoren sollten ihre eigene Umgebung gegen diese Liste abgleichen und bei Unsicherheit den offiziellen Support-Kanal von F5 konsultieren.
| Branch | Betroffen laut Berichten | Gepatchte Version | Empfehlung |
|---|---|---|---|
| 15.1.x | Ja | 15.1.10.8 | Sofort aktualisieren |
| 16.1.x | Ja | 16.1.6.1 | Sofort aktualisieren |
| 17.1.x | Ja | 17.1.3 | Sofort aktualisieren |
| 17.5.x | Ja | 17.5.1.3 | Sofort aktualisieren |
Erste Prüfschritte für Administratoren
Wer BIG-IP APM mit Webtop-Funktion betreibt, sollte die folgenden Schritte zeitnah durchgehen, um eine Kompromittierung durch PoisonedRefresh auszuschließen oder zu bestätigen:
- Aktuelle Softwareversion mit den oben genannten Branches und Patch-Ständen abgleichen
- Arbeitsspeicher laufender Apache-Worker mit dem Inhalt von apm_css.php3, full_wt.php3 und webtop_popup_css.php3 auf der Platte vergleichen
- Existenz des UNIX-Sockets /run/bigtlog.pipe prüfen
- HTTP-Zugriffsprotokolle auf ungewöhnliche 201-Antworten vom Typ text/css durchsuchen
- Eingehende Anfragen mit dem Magic-Präfix BSOHAzPB im Rohkörper identifizieren
- Datei /usr/sbin/httpd auf Manipulation untersuchen
- Pfad /mnt/tm_install auf unbekannte Persistenzartefakte prüfen
- SELinux-Konfiguration auf unerwartete Änderungen kontrollieren
- Sample mit dem SHA-256-Hash 26bd5b0722d1dbab5db749a063c49bc8638653ac2addfead7a9cb3d6d57bccc9 als Referenz für Scans nutzen
- F5 Compromise Assessment und Remediation Guidance konsultieren, bevor Systeme neu gestartet werden
- Flüchtige Beweise sichern, da ein Neustart speicherresidente Artefakte unwiderruflich löscht
- Internetexposition der Managementoberfläche und der APM Webtop-URL minimieren
Warum ein Neustart allein nicht ausreicht
Ein häufiger Reflex nach dem Verdacht auf eine Kompromittierung ist der schlichte Neustart des betroffenen Dienstes oder Systems. Bei PoisonedRefresh greift dieser Ansatz jedoch zu kurz. Zwar würde ein Neustart die rein speicherresidente Webshell-Injektion in den laufenden Apache-Prozess entfernen, doch der Installer hat bereits die Datei /usr/sbin/httpd infiziert, Persistenz über /mnt/tm_install verankert und die SELinux-Konfiguration verändert. Nach einem Neustart könnte sich das Rootkit somit erneut im Arbeitsspeicher einnisten, ohne dass die zugrunde liegende Infektion beseitigt wurde. Aus diesem Grund empfiehlt sich vor jeder Bereinigungsmaßnahme die Sicherung flüchtiger Beweise sowie der Einsatz der von F5 bereitgestellten Compromise Assessment und Remediation Guidance, um eine vollständige Bereinigung sicherzustellen.
Passende Anleitungen auf S-EDV
- F5 und Nginx: Außerplanmäßige kritische Lücken im Juni 2026
- Arch AUR: Community-Pakete mit Infostealer- und Rootkit-Malware
