Eine mutmaßlich China-verknüpfte Spionagegruppe nutzte eine kritische Schwachstelle in BeyondTrust Remote Support aus, bevor ein Patch verfügbar war. Auf betroffenen Appliances konnten die Angreifer ihre Rechte ausweiten und Zugangsdaten erreichen, die das Produkt speicherte oder vermittelte. Für Unternehmen heißt das: Aktualisieren ist wichtig – bei möglicherweise exponierten, selbst gehosteten Systemen muss aber zusätzlich geprüft werden, ob sie bereits kompromittiert wurden.
1
12
Was die BeyondTrust-Schwachstelle ermöglichte
CVE-2026-102764 erhielt einen CVSS-4.0-Wert von 9,3. Betroffen waren ungepatchte Versionen von BeyondTrust Remote Support bis einschließlich 26.2.3. Ursache war eine unzureichende Prüfung der Herkunft von Nachrichten in einer internen Komponente. Dadurch konnte ein nicht authentifizierter Angreifer aus der Ferne eine vertrauenswürdige Komponente imitieren und Dateioperationen auf einer Appliance ausführen.
2
3
18
Google und Mandiant berichten, dass die Angreifer die Lücke nutzten, um Zugriff auf Appliances zu erhalten und ihre Rechte bis zur Root-Ebene des Hosts auszuweiten. Diese Kontrolle konnte ihnen Zugang zu Zugangsdaten verschaffen, die das Produkt speicherte oder vermittelte, und als Ausgangspunkt für weitere Aktivitäten im Netzwerk dienen.
1
3
12
Was über die Angreifer bekannt ist
Google und Mandiant ordnen die mutmaßlichen Angriffe der Gruppe Armory Castle zu, die zuvor unter dem Namen UNC5221 geführt wurde.
1 Einige andere Berichte verwenden für die Gruppe auch den Namen Warp Panda. Die hier verfügbaren Quellen belegen jedoch nicht unabhängig, dass CrowdStrike diesen Namen für die Gruppe verwendet.
4
In der Berichterstattung zur Untersuchung werden Sawfly, eine PHP-Webshell, und Bareclaw, ein SOCKS5-Tunneling-Tool, genannt. Diese Werkzeuge passen zum beschriebenen Vorgehen: Zugriff aufrechterhalten und Aktivitäten über die kompromittierte Appliance hinaus ermöglichen.
28
33 Nicht alle Details des Angriffsablaufs sind durch die verfügbaren Belege abgesichert. Behauptungen über bestimmte gestohlene Dateien oder den genauen Weg der Datenabflüsse sollten daher mit Vorsicht betrachtet werden.
Ausnutzung und Patch-Zeitplan
Den Berichten zufolge begann die Ausnutzung Ende August 2026 – noch bevor BeyondTrust die Schwachstelle öffentlich machte. Ein Bericht datiert die ersten Aktivitäten auf den 29. August und nennt dabei eine von BeyondTrust gehostete Instanz sowie eine selbst gehostete Appliance.
1
19
BeyondTrust veröffentlichte den Patch am 8. Oktober und erklärte, die SaaS-Instanzen bis zum 9. Oktober aktualisiert zu haben. Am 15. Oktober machte das Unternehmen CVE-2026-102764 in der Sicherheitsmitteilung BT26-05 öffentlich.
1
7 Für selbst gehostete Remote-Support-Versionen von 24.3.1 bis 26.2.3 ist laut Berichterstattung der Patch BT26-05-RS vorgesehen. Installationen mit älteren Versionen müssen zunächst aktualisiert werden, bevor sich dieser Patch einspielen lässt.
1
Was Unternehmen jetzt tun sollten
- Produkt und Version prüfen. Ermitteln Sie, ob eine selbst gehostete Remote-Support-Appliance mit einer ungepatchten Version bis einschließlich 26.2.3 betrieben wurde. Gehen Sie nicht davon aus, dass eine selbst gehostete Installation automatisch das SaaS-Update erhalten hat.
1
18
- Den passenden Patch einspielen. Folgen Sie den Patch-Hinweisen des Herstellers für die installierte Version. Bei älteren Versionen ist gegebenenfalls zuerst ein Upgrade erforderlich.
1
- Möglicherweise exponierte Appliances auf Kompromittierung untersuchen. Google und Mandiant empfehlen laut Berichten, exponierte selbst gehostete Appliances als potenziell kompromittiert zu behandeln. Grund sind der gemeldete Root-Zugriff, mögliche Zugriffe auf Zugangsdaten und das Risiko weiterer Bewegung im Netzwerk.
12
- Zugangsdaten und verbundene Systeme einbeziehen. Da die Angreifer laut Berichten Zugangsdaten erreichen konnten, die das Produkt verarbeitete, und einen Ausgangspunkt für seitliche Bewegungen im Netzwerk schufen, sollte die Untersuchung auch erreichbare Konten und Systeme umfassen.
3
12
Ein erfolgreicher Patch verhindert die Ausnutzung der bekannten Schwachstelle, belegt aber nicht, dass vor der Aktualisierung kein Zugriff stattgefunden hat. Die verfügbaren Berichte sprechen deshalb dafür, das Schließen der Lücke und die Prüfung auf eine mögliche Kompromittierung als zwei getrennte Aufgaben zu behandeln.
1
12