Hacker nehmen F5-BIG-IP-APM-Systeme mit einer dateilosen Linux-Web-Shell ins Visier

Bedrohungsakteure kompromittieren offenbar Systeme in Umgebungen mit dem F5 BIG-IP Access Policy Manager und installieren ein Linux-Rootkit, das das Laden von PHP-Dateien manipulieren kann. Das Rootkit injiziert eine Web-Shell direkt in den Arbeitsspeicher. So können Angreifer unauffällig dauerhaften Zugriff aufrechterhalten, ohne eine herkömmliche Web-Shell-Datei auf der Festplatte abzulegen.

Die Aktivitäten wurden am 8. September 2026 gemeldet. Die ersten Berichte nennen jedoch weder den Angriffsvektor noch eine zugehörige Schwachstelle, betroffene Softwareversionen oder die Zahl der kompromittierten Organisationen.

Diese Ungewissheit erschwert die Behebung. Verteidiger können derzeit nicht feststellen, ob die Installation eines bestimmten Updates den Angriffsweg schließt. Das Verhalten nach der Kompromittierung liefert jedoch Ansatzpunkte für sofortige Untersuchungen.

Aus einem Sicherheits-Gateway wird ein Einfallstor für Angreifer

Betroffen ist der F5 BIG-IP Access Policy Manager, der üblicherweise vor sensiblen Unternehmensressourcen eingesetzt wird, um Zugriffsrichtlinien durchzusetzen. Die Kompromittierung eines solchen Systems ist weitreichender als eine Infektion auf einem gewöhnlichen Endgerät.

Ein Angreifer, der eine Appliance zur Zugriffsverwaltung kontrolliert, kann sich eine dauerhafte Position in der Nähe von Authentifizierungsabläufen und geschützten Netzwerkdiensten verschaffen. Je nach Konfiguration und Berechtigungen der Appliance kann sie außerdem als Ausgangspunkt für den Zugriff auf interne Systeme dienen.

Die gemeldete Malware läuft im zugrunde liegenden Linux-Kontext der BIG-IP-Umgebung. Zu ihren wichtigsten dokumentierten Fähigkeiten gehören:

• Das Abfangen des Ladens von PHP-Dateien.
• Das Injizieren einer Web-Shell in den Arbeitsspeicher des Systems.
• Das Vermeiden der Erstellung einer normalen Web-Shell-Datei auf der Festplatte.
• Das Verschleiern schädlicher Aktivitäten mithilfe von Rootkit-Funktionen.

Es wurden keine Belege veröffentlicht, die Datendiebstahl, eine Betriebsunterbrechung, das Abfangen von Zugangsdaten oder eine Ausbreitung in nachgelagerte Netzwerke bestätigen. Diese Folgen bleiben mögliche Auswirkungen und sind keine bestätigten Erkenntnisse.

Auch das Ausmaß ist unbekannt. Es gibt keine veröffentlichte Zahl betroffener Appliances oder Organisationen. Ebenso liegen keine Informationen zu einer geografischen oder branchenspezifischen Auswahl der Ziele vor. Die Betreiber, der Name der Kampagne und der Name der Malware wurden nicht bekannt gegeben.

Wie die im Arbeitsspeicher ausgeführte Web-Shell die Dateiprüfung umgeht

Herkömmliche Web-Shells sind in der Regel serverseitige Skripte, die in einem über das Web erreichbaren Verzeichnis abgelegt werden. Ein Angreifer sendet anschließend speziell präparierte Anfragen an das Skript, um Befehle auszuführen oder andere nicht autorisierte Aktionen durchzuführen.

Bei diesem Vorgehen bleibt eine Datei zurück. Sicherheitstools können sie durch Signaturabgleich, Integritätsüberwachung, verdächtige Dateinamen, Inhaltsprüfungen oder den Vergleich mit einer vertrauenswürdigen Installation erkennen.

Die bei BIG-IP-APM-Systemen gemeldete Technik macht diese Abhängigkeit überflüssig. Statt die schädliche PHP-Komponente als normale Datei zu speichern, fängt das Rootkit das Laden von PHP ab und injiziert die Web-Shell in den Arbeitsspeicher.

Dadurch entsteht eine Lücke zwischen dem, was das System auf der Festplatte zu enthalten scheint, und dem, was es zur Laufzeit ausführt. Ein Dateisystem-Scan kann melden, dass keine unbekannte PHP-Datei vorhanden ist, während die schädliche Web-Shell-Logik weiterhin im Arbeitsspeicher aktiv bleibt.

Das Rootkit sorgt für eine weitere Verschleierungsebene. Rootkits sind darauf ausgelegt, die normale Sichtbarkeit des Betriebssystems auf Prozesse, Dateien, Netzwerkaktivitäten oder andere Ressourcen zu beeinträchtigen. Die genauen in dieser Kampagne verwendeten Mechanismen zur Verschleierung wurden nicht veröffentlicht. Verteidiger sollten daher nicht davon ausgehen, dass die standardmäßige administrative Ausgabe ein vollständiges Bild einer betroffenen Appliance liefert.

Ebenso ist nicht bekannt, wie die Persistenz einen Neustart übersteht, wie die Angreifer mit der injizierten Shell kommunizieren oder welcher Mechanismus zum Laden von PHP abgefangen wird. Es wurden keine Command-and-Control-Infrastruktur, Dateinamen, Prozessnamen, Netzwerkindikatoren, kryptografischen Hashes oder Erkennungssignaturen veröffentlicht.

Versionen, Schwachstellen und Angriffsweg bleiben unbekannt

Die betroffene Produktfamilie ist F5 BIG-IP, konkret Umgebungen mit Access Policy Manager. Die genauen BIG-IP-Releases und Appliance-Modelle wurden nicht genannt.

Den Kompromittierungen wurde keine CVE zugeordnet. Daher ist unbekannt, ob die Angreifer eine ungepatchte Softwareschwachstelle ausnutzten, gestohlene Administratorkonten verwendeten, eine exponierte Verwaltungsschnittstelle missbrauchten oder über einen anderen Weg Zugang erlangten.

Diese Unterscheidung ist für die Eindämmung entscheidend. Ein Softwareupdate kann eine Schwachstelle beseitigen, entfernt ein Rootkit jedoch nicht unbedingt von einem bereits kompromittierten Gerät. Umgekehrt würde allein die Änderung von Zugangsdaten eine unbekannte ausnutzbare Schwachstelle nicht schließen.

Ebenso wurden keine behobene Version, kein Hersteller-Patch und kein bestätigter Workaround veröffentlicht, die sich ausdrücklich auf diese Aktivitäten beziehen. Unternehmen sollten weiterhin alle relevanten Sicherheitsupdates und Härtungsempfehlungen von F5 umsetzen. Sie sollten die routinemäßige Aktualisierung jedoch nicht als Beleg dafür werten, dass eine Appliance sauber ist.

Da keine Schwachstellenkennung vorliegt, kann die Aktivität keinem Eintrag im Katalog der bekannten ausgenutzten Schwachstellen der US Cybersecurity and Infrastructure Security Agency zugeordnet werden. Für diesen Vorfall gibt es folglich weder ein veröffentlichtes KEV-Aufnahmedatum noch eine damit verbundene Frist zur Behebung.

Die Erkennung muss über das Dateisystem hinausgehen

Herkömmliche dateibasierte Malware-Scans reichen bei dieser Bedrohung nicht aus. Verteidiger sollten Protokolle der Appliance, Netzwerk-Telemetrie, Laufzeitprüfungen, Konfigurationsanalysen und – sofern verfügbar – eine forensische Untersuchung des Arbeitsspeichers kombinieren.

Zu den Untersuchungsschwerpunkten gehören:

1. Administrativen Zugriff überprüfen. Untersuchen Sie die Verwaltungs- und Systemprotokolle von BIG-IP auf nicht erklärte Anmeldungen, die Nutzung von Berechtigungen, Konfigurationsänderungen, neu angelegte Konten oder Zugriffe aus unerwarteten Quellen.

2. Das Ausführungsverhalten von PHP überprüfen. Achten Sie auf ungewöhnliche Anfragen, unerwartete Muster beim Laden von PHP, Ausführungspfade, die keiner Datei auf der Festplatte entsprechen, sowie Abweichungen zwischen den bereitgestellten Anwendungsinhalten und dem beobachteten Verhalten zur Laufzeit.

3. Aktivitäten im Arbeitsspeicher analysieren. Untersuchen Sie anomale Prozesse und geladene Komponenten. Da die Web-Shell Berichten zufolge in den Arbeitsspeicher injiziert wird, können flüchtige Daten entscheidend dafür sein, festzustellen, ob die Appliance kompromittiert wurde.

4. Netzwerkverbindungen untersuchen. Identifizieren Sie unerwarteten ausgehenden Datenverkehr, dauerhafte Sitzungen, unbekannte Ziele und Verbindungen, die nicht zur vorgesehenen Funktion der Appliance passen.

5. Nach dem Verhalten einer Web-Shell suchen, nicht nur nach Web-Shell-Dateien. Verdächtige Befehlsausführungen oder Anfragemuster können in Protokollen oder Netzwerkdaten sichtbar bleiben, selbst wenn kein schädliches Skript auf der Festplatte vorhanden ist.

6. Die Systemintegrität überprüfen. Vergleichen Sie die Konfiguration und den Softwarestatus der Appliance mithilfe freigegebener administrativer oder forensischer Verfahren von F5 mit vertrauenswürdigen Referenzwerten.

Das Fehlen veröffentlichter Indikatoren bedeutet, dass diese Prüfungen eine Verhaltensanalyse statt eines einfachen Abgleichs mit Hashes oder IP-Adressen erfordern. Ein unauffälliger Festplatten-Scan allein sollte die Untersuchung nicht beenden.

Bei Verdacht betroffene Appliances unter Beweissicherung isolieren

Organisationen, die glaubwürdige Anzeichen einer Kompromittierung feststellen, sollten das betroffene BIG-IP-System isolieren und dabei Protokolle sowie flüchtige Daten aus dem Arbeitsspeicher sichern. Ein sofortiger Neuaufbau oder Neustart kann die Beweismittel verändern, die zum Verständnis des Rootkits und seiner im Arbeitsspeicher befindlichen Payload benötigt werden.

Incident-Response-Teams sollten feststellen, wann der unbefugte Zugriff begann, welche Konten mit der Appliance interagierten und mit welchen internen oder externen Systemen sie kommunizierte. Die Untersuchung sollte über das BIG-IP-Gerät hinausgehen, da ein kompromittiertes Zugangs-Gateway möglicherweise für den Zugriff auf geschützte Infrastruktur verwendet wurde.

Zugangsdaten, die auf dem betroffenen System zugänglich waren oder über dieses verwendet wurden, sollten nach der Eindämmung geändert werden. Privilegierte Konten, Zugangsdaten für Automatisierung und Dienstkonten sowie administrative Zugangswege verdienen dabei besondere Aufmerksamkeit.

Die Wiederherstellung des Vertrauens kann mehr erfordern als das Löschen verdächtiger Dateien – insbesondere dann, wenn gar keine solchen Dateien vorhanden sind. Organisationen sollten vom Hersteller unterstützte Verfahren zur Wiederherstellung und Integritätsprüfung nutzen und verifizieren, dass schädliche Laufzeitänderungen die Behebung nicht überstehen oder danach wiederkehren können.

Solange keine Informationen zu F5-Versionen, einer anfänglichen Zugriffsmethode und validierten Korrekturen vorliegen, stehen Verteidiger vor zwei getrennten Aufgaben: Sie müssen die Angriffsfläche durch aktuelle Sicherheitsupdates verringern und feststellen, ob Angreifer bereits in den eingesetzten Appliances aktiv sind. Die zweite Aufgabe lässt sich nicht allein durch Patching lösen.