Der BeyondTrust RCE ist schlimmer als Sie denken

Kurz zusammengefasst

Eine Pre-Authentication-Remote-Code-Execution-Schwachstelle in den Produkten Remote Support und Privileged Remote Access von BeyondTrust, verfolgt als CVE-2026-1731, wird aktiv in Ransomware-Kampagnen ausgenutzt. Die Schwachstelle erreicht einen CVSS-Score von 9,9 von 10. Kein Login erforderlich. Keine Benutzerinteraktion nötig. Nur eine präparierte Anfrage an eine exponierte Instanz – und ein Angreifer führt bereits OS-Befehle aus.

Der zeitliche Ablauf ist alarmierend. Anomale Aktivitäten wurden am 31. Januar festgestellt. Patches wurden am 2. Februar an Cloud-Kunden ausgeliefert. Die CVE wurde am 6. Februar öffentlich bekannt gemacht. Ein Proof-of-Concept-Exploit tauchte fast unmittelbar danach auf. Bis zum 13. Februar hatte CISA sie in den Known Exploited Vulnerabilities-Katalog aufgenommen und als in Ransomware-Kampagnen eingesetzt markiert – Bundesbehörden erhielten gerade drei Tage Zeit, um zu patchen oder das Produkt nicht mehr zu verwenden. Das Unit-42-Team von Palo Alto hat seitdem die Ausnutzung in den USA, Frankreich, Deutschland, Australien und Kanada bestätigt, wobei VShell- und SparkRAT-Payloads auf kompromittierten Systemen beobachtet wurden.

Rund 16.400 exponierte Instanzen wurden identifiziert. Davon sind ungefähr 8.500 selbst gehostete On-Premise-Deployments, die manuell gepatcht werden müssen. Wenn Sie eine solche Instanz betreiben und noch nicht gepatcht haben: Hören Sie auf, diesen Artikel zu lesen, und erledigen Sie das zuerst.

Warum diese Schwachstelle mehr zählt als das übliche CVE-Rauschen

Tools für Remote-Zugriff und privilegiertes Session-Management sind per Definition die Schlüssel zum Königreich. Sie sind darauf ausgelegt, Personen (und zunehmend auch automatisierten Systemen) Zugang zur internen Infrastruktur zu gewähren. Wenn eines dieser Tools eine Pre-Auth-RCE aufweist, muss der Angreifer keine Zugangsdaten stehlen, niemanden phishen oder mehrere Exploits verketten. Er muss nur eine exponierte Instanz finden.

Es ist auch nicht das erste Mal, dass diese Produkte ins Visier genommen werden. Ende 2024 nutzte eine staatlich geförderte Gruppe ähnliche Schwachstellen, um das US-Finanzministerium zu kompromittieren. Diese Angriffskette umfasste einen Zero-Day kombiniert mit einer SQL-Injection in einer zugrunde liegenden PostgreSQL-Komponente. Das Muster ist eindeutig: Remote-Access-Plattformen sind hochwertige Ziele, und Angreifer kehren immer wieder zu ihnen zurück.

Neu ist diesmal die Geschwindigkeit. Von der Offenlegung bis zur aktiven Ausnutzung vergingen nur Tage. Und die Beteiligung von Ransomware-Akteuren – nicht nur staatlich geförderter Gruppen – bedeutet, dass die Bedrohung breiter ist. Dies ist keine gezielte Spionage. Es ist opportunistisch, automatisiert und auf jeden ausgerichtet, der eine ungepatchte Instanz im Internet betreibt.

Was wir in der Praxis sehen

Bei Penetrationstests für Gaming-Studios und Enterprise-Kunden finden wir regelmäßig Remote-Access-Tools an Stellen, wo sie nicht hingehören. Dem öffentlichen Internet ausgesetzt mit Standardkonfigurationen. Vom internen Monitoring abgeschirmt. Mit Versionen, die ein oder zwei Hauptversionen im Rückstand sind. Das Muster ist immer dasselbe: Das Tool wurde schnell eingerichtet, um ein unmittelbares Zugriffsproblem zu lösen, und niemand hat es danach gehärtet.

Privileged-Access-Management-Tools sind besonders heikel, weil sie oft in eine Governance-Lücke fallen. Das Sicherheitsteam denkt, IT-Ops ist zuständig. IT-Ops denkt, das SaaS des Anbieters regelt alles. Und niemand prüft, ob die selbst gehostete Instanz in der Ecke tatsächlich automatische Updates abonniert hat.

Genau dieses Szenario haben wir bei Cloud-Security-Reviews für Enterprise-Kunden mit Compliance-Anforderungen erlebt. Ein Team deployt ein Remote-Support-Tool für den Anbieterzugang, konfiguriert es einmal und geht weiter. Zwei Jahre später ist es drei Versionen im Rückstand, dem Internet ausgesetzt, und niemand erinnert sich daran, dass es existiert. Das ist die Instanz, die kompromittiert wird.

Die eigentliche Lektion ist architektonischer Natur

Patchen ist natürlich die unmittelbare Lösung. Das tiefere Problem ist aber, dass zu viele Organisationen Management-Plane-Schnittstellen direkt dem Internet aussetzen.

Der Bericht von Unit 42 enthält eine Empfehlung, der ich vollständig zustimme: Defense-in-Depth-Architektur für Remote-Access-Plattformen. Verlassen Sie sich nicht allein auf die Patches des Anbieters. Isolieren Sie diese Tools in interne Management-Netzwerke. Stellen Sie sie hinter ein Zero-Trust-Access-Gateway. Schränken Sie administrative Schnittstellen ein, sodass sie nur von bekannten, kontrollierten Endpunkten erreichbar sind.

Aus unserer Arbeit bei der Konfiguration von Cloudflare und ähnlichen Plattformen für DDoS-Schutz bei großen Reise- und Enterprise-Systemen haben wir gelernt, dass dieselbe Zugangskontrolldisziplin überall gilt. Wenn etwas nicht öffentlich erreichbar sein muss, sollte es das nicht sein. Das gilt für Ihre APIs, Ihre Admin-Panels und ganz besonders für Ihre Remote-Access-Infrastruktur.

Wenn wir Cloud-native Apps für Enterprise-Kunden entwickeln, behandeln wir die Management-Plane von Anfang an als separate Sicherheitszone. Separate Netzwerksegmente, separate Authentifizierung, separates Monitoring. Das bedeutet mehr Aufwand im Voraus. Es bedeutet aber auch, dass eine CVE wie diese zu einer Patching-Übung wird – nicht zu einem Incident-Response-Einsatz.

Was Sie diese Woche tun sollten

Wenn Sie diese spezifischen Produkte verwenden, patchen Sie sofort. Selbst gehosteter Remote Support sollte auf Version 25.3.2 oder höher laufen. Selbst gehosteter Privileged Remote Access sollte auf 25.1.1 oder höher laufen. Wenn Ihre Instanz vor dem 9. Februar internet-exponiert und ungepatcht war, gehen Sie von einer Kompromittierung aus und untersuchen Sie dies. Der Anbieter bittet betroffene Kunden, Severity-1-Tickets zu eröffnen.

Aber auch wenn Sie diese Produkte nicht verwenden, gelten die übergeordneten Handlungsempfehlungen:

Prüfen Sie jedes Remote-Access-Tool in Ihrer Umgebung. Nicht nur die offiziellen. Das Tool, das jemand vor drei Jahren für einen Auftragnehmer eingerichtet hat, zählt ebenfalls. Überprüfen Sie, ob sie dem Internet ausgesetzt sind, ob sie auf aktuellen Versionen laufen und ob jemand die Logs tatsächlich überwacht.

Entfernen Sie Management-Schnittstellen aus dem öffentlichen Internet. Wenn Ihr Remote-Support-Tool, Ihr CI/CD-Dashboard, Ihr Datenbankadmin-Panel oder eine andere Management-Schnittstelle vom offenen Internet erreichbar ist, beheben Sie das. Stellen Sie es hinter ein VPN, ein Zero-Trust-Gateway oder schränken Sie es zumindest per IP auf bekannte Adressbereiche ein.

Behandeln Sie Ihre Remote-Access-Tools so, wie Sie Ihre Produktionsdatenbank behandeln würden. Versionieren Sie sie. Überwachen Sie sie. Nehmen Sie sie in Ihren Sicherheitsprüfungsprozess auf. Lassen Sie sie nicht in eine vergessene Ecke Ihrer Infrastruktur abdriften.

Das Zeitfenster zwischen Offenlegung und Ausnutzung schrumpft immer weiter. Bei dieser CVE war es praktisch null – da die Ausnutzung bereits stattfand, bevor das Advisory überhaupt veröffentlicht wurde. Die einzige zuverlässige Verteidigung gegen eine solche Zeitlinie besteht darin, Ihre exponierte Angriffsfläche zu reduzieren, bevor die nächste CVE erscheint.

Wenn Sie die Bereinigung Ihrer Remote-Access-Infrastruktur oder einen Security-Review Ihrer Cloud-Umgebung schon länger vor sich her schieben, sprechen Sie mit uns. Wir haben diese Arbeit in den Bereichen Gaming, Reise, Gesundheitswesen und Enterprise durchgeführt – und das Gespräch ist immer einfacher, bevor etwas in Flammen aufgeht.