Startseite / Sicherheit
Sicherheit

Check Point: Angriffskette endet teils beim ESXi-Wiper

Check Point: Angriffskette endet teils beim ESXi-Wiper
← Alle Beiträge

Unbekannte Angreifer nutzen ungepatchte Check Point Security Gateways, um in Unternehmensnetze einzudringen. Der beobachtete Angriffsweg kombiniert die als PHP2Shell bezeichneten Schwachstellen CVE-2026-109618 und CVE-2026-109619 mit einer lokalen Privilegieneskalation in Gaia OS. Nach dem Root-Zugriff installierten die Täter Webshells und die persistente Backdoor TSGA. In einigen Fällen bewegten sie sich bis zu VMware-ESXi-Systemen weiter und löschten dort Dateien.

Die Kampagne begann nach Angaben von Check Point am 30. Oktober 2026 mit Angriffen auf israelische Organisationen. Am 2. November folgte eine breitere, offenbar opportunistische Welle gegen verschiedene Länder und Branchen. Check Point spricht von aktiver Ausnutzung bei rund zwei Dutzend Kunden. Bei einem Teil der zuerst angegriffenen Organisationen kam es zu destruktiven Aktionen.

Operativ entscheidend ist die Abfolge: Die kritischen PHP-Lücken liefern den nicht authentifizierten Fernzugriff, die Gaia-Lücke hebt den bereits erreichten lokalen Zugriff auf Root-Rechte. Wer nur einen Teil dieser Kette schließt oder ein bereits kompromittiertes Gateway lediglich aktualisiert, hat das eigentliche Problem daher nicht vollständig gelöst.

Zwei Schwachstellen übernehmen unterschiedliche Aufgaben

CVE-2026-109618 und CVE-2026-109619 erreichen nach CVSS 4.0 einen Wert von 9,2. Sie ermöglichen unauthentifizierte Remote Code Execution. In den beobachteten Angriffen richtete sich die Ausnutzung gegen verwundbare Mobile-Access-Portale auf Check Point Security Gateways. PHP schloss die Schwachstellen am 21. Oktober mit den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Check Point stellte am 23. Oktober einen eigenen Hotfix bereit.

Die beobachtete Angriffskette
Die beobachtete Angriffskette1. PHP2ShellUnauthentifizierte Codeausführung am Gateway2. CVE-2026-123039Lokale Rechteausweitung auf Root3. Webshell und TSGAPersistenter und verdeckter Zugang4. Bewegung über SSHZugriff auf VMware ESXi mit vpxuser5. destroy_v6Rekursive Löschung von Dateien
Die Grafik zeigt den Weg von der unauthentifizierten PHP2Shell-Ausnutzung über die lokale Rechteausweitung und TSGA bis zur seitlichen Bewegung auf ESXi und dem Einsatz des Wipers.

Nach dem ersten Zugriff nutzten die Angreifer CVE-2026-123039 im DynamicCLI-Prozess von Gaia OS. Die mit einem CVSS-Wert von 7,8 bewertete Schwachstelle beruht auf einer fehlenden Autorisierungsprüfung. Ein bereits authentifizierter lokaler Benutzer kann durch eine Anfrage an einen Socket beliebige Befehle ausführen und Root-Rechte erlangen.

Für sich genommen ist CVE-2026-123039 also keine aus der Ferne ohne Vorbedingungen ausnutzbare Einstiegslücke. In Verbindung mit PHP2Shell wird diese Einschränkung jedoch weitgehend bedeutungslos: Die erste Schwachstelle schafft die benötigte lokale Codeausführung, die zweite beseitigt die verbleibende Rechtebarriere.

Diese Produkte und Versionen sind betroffen

Betroffen sind Check Point Force Firewalls, Management and Log Servers, Multi-Domain Security Management und Multi-Domain Log Server sowie Maestro Orchestrator. Check Point nennt die Versionsreihen R82.20, R82.10, R82, R81.20, R81.10 und R81.

Für CVE-2026-123039 sind als erste korrigierte Jumbo Hotfix Accumulator Takes dokumentiert: R82.20 Take 14, R82.10 Take 52, R82 Take 132 und R81.20 Take 174. Für die betroffenen Reihen R81.10 und R81 liegen in den bereitgestellten Angaben keine entsprechenden Take-Nummern vor. Betreiber dieser Versionen sollten deshalb den für ihre konkrete Installation vorgesehenen Emergency- beziehungsweise November-Hotfix von Check Point prüfen, statt eine Take-Nummer aus einer anderen Versionsreihe zu übertragen.

Die Korrekturen für PHP2Shell und CVE-2026-123039 sind in die jeweiligen November-Jumbo-Hotfixes eingeflossen. Entscheidend ist damit nicht nur, ob irgendein aktueller Hotfix installiert wurde, sondern ob der konkrete Take beide Teile der Angriffskette abdeckt.

Vom Sicherheitsgateway bis zum Virtualisierungshost

Nach der Rechteausweitung hinterlegten die Täter PHP-Webshells, die Befehle ausführen und Dateien hochladen können. Anschließend installierten sie TSGA unter dem Namen slot_CPconfigdaemon. Die auf Check Point zugeschnittene Linux-Backdoor ermöglicht verschlüsselten Fernzugriff, den Diebstahl von Konfigurationen und Persistenz über Backups oder Snapshots. Sie kann außerdem Prozesse manipulieren und binäre Firewall-Protokolle verändern.

Zu TSGA gehört die Komponente TSProxy. Sie wird in ausgewählte Prozesse des Appliances eingeschleust und fängt Netzwerkfunktionen ab. Speziell markierte Verbindungen der Angreifer lassen sich dadurch über vorhandene Dienste abwickeln, während gewöhnlicher Datenverkehr weiterläuft. Das erschwert nicht nur die Erkennung, sondern schwächt auch den Beweiswert der Protokolle auf dem kompromittierten Gateway.

Für die interne Erkundung kam der Scanner gogo zum Einsatz. In einigen Fällen meldeten sich die Angreifer anschließend per SSH mit dem Dienstkonto vpxuser an einem VMware-ESXi-Host an. Dort platzierten sie den Linux-Wiper destroy_v6. Die Schadsoftware durchläuft Zielverzeichnisse rekursiv, versucht Dateien mit Nullen zu überschreiben und löscht sie unabhängig von ihrer Endung. Zusätzlich legte sie in bearbeiteten Verzeichnissen eine politisch formulierte Datei namens DREAM_ANNEXATION.txt ab.

Nach einer möglichen Kompromittierung reicht Patchen nicht

Betreiber sollten zunächst feststellen, ob eines der genannten Produkte in einer betroffenen Version läuft und ob die Hotfixes für beide PHP2Shell-CVEs sowie CVE-2026-123039 tatsächlich installiert sind. Besondere Priorität haben aus dem Internet erreichbare Mobile-Access-Portale und Systeme, die seit Ende Oktober ungepatcht betrieben wurden.

War ein Gateway während des Angriffsfensters verwundbar, ist ein nachträgliches Update kein Nachweis für ein sauberes System. Zu prüfen sind Webshells, der Prozess beziehungsweise Dateiname slot_CPconfigdaemon, ungewöhnliche SSH-Verbindungen ins interne Netz und Zugriffe mit Dienstkonten wie vpxuser. Wegen der möglichen Protokollmanipulation sollten Ermittlungen nicht ausschließlich auf den lokalen Logs des Gateways beruhen. Externe Netzwerk-, Authentifizierungs-, Hypervisor- und Managementprotokolle sind für die Rekonstruktion wichtiger.

Bei Hinweisen auf eine Kompromittierung sollten betroffene Appliances isoliert und forensisch untersucht werden. Zugangsdaten, die auf dem Gateway gespeichert waren oder für seitliche Bewegungen verwendet worden sein könnten, müssen als potenziell offengelegt behandelt werden. Auch Backups und Snapshots verdienen eine gesonderte Prüfung, weil TSGA ausdrücklich auf Persistenz in diesen Wiederherstellungspfaden ausgelegt ist.

Die politische Notiz beweist keine Urheberschaft

TSGA und TSProxy ähneln Komponenten des PhiliKit-Werkzeugkastens, den ESET im Juni 2026 der China-nahen Spionagegruppe Armory Castle, ehemals UNC5221, zugeordnet hatte. Auch verwendete LightNode-Infrastruktur und die zeitliche Verteilung der Scans liefern Anhaltspunkte in diese Richtung.

Check Point hält die Belege dennoch nicht für ausreichend. Der Einsatz eines Wipers, die anfängliche Konzentration auf Israel und die Bezugnahme auf den israelisch-palästinensischen Konflikt passen nicht eindeutig zu einer klassischen Spionageoperation. Möglich sind eine vollständige Operation derselben Gruppe, der Verkauf des Erstzugangs, eine False-Flag-Kampagne oder destruktive Aktionen als Ablenkung.

Für Betreiber ändert diese offene Attribution wenig. Die konkrete Gefahr liegt nicht im Namen der Gruppe, sondern in einem bereits erreichten Root-Zugriff auf einer zentralen Netzkomponente. Ein kompromittiertes Gateway kontrolliert nicht nur Verkehr: Es enthält Konfigurationen und Zugangspfade, kann interne Systeme erkunden und liefert den Ausgangspunkt für Angriffe auf die Virtualisierungsinfrastruktur. Genau deshalb endet die Bereinigung nicht mit dem Neustart nach einem Hotfix.

J

Über den Autor

Jens Könnig

Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?

Alle Artikel von Jens Könnig →