Eine kritische Sicherheitslücke in BeyondTrust Remote Support wird seit Ende August 2026 aktiv für Spionageangriffe ausgenutzt. Die Schwachstelle trägt die Kennung CVE-2026-102764, erreicht nach CVSS 4.0 einen Wert von 9,3 und erlaubt einem entfernten Angreifer ohne Anmeldung, Dateien auf einer verwundbaren Appliance zu manipulieren oder hochzuladen. Das ist besonders brisant, weil Remote-Support-Systeme bewusst tief in Unternehmensnetze reichen und häufig Zugangsdaten, administrative Sitzungen sowie Verbindungen zu vielen Endgeräten bündeln.
BeyondTrust hat die Lücke am 15. Oktober öffentlich gemacht. Für SaaS-Kunden wurde die Korrektur bereits zentral eingespielt. Betreiber selbst gehosteter Instanzen müssen dagegen prüfen, ob der Patch BT26-05-RS tatsächlich installiert ist. Betroffen sind laut Hersteller alle Remote-Support-Versionen bis einschließlich 26.2.3. Systeme vor Version 24.3.1 müssen zunächst auf eine unterstützte Version aktualisiert werden, bevor sich der Fix einspielen lässt.
Warum diese Lücke über einen normalen Patch-Hinweis hinausgeht
Die technische Ursache liegt laut BeyondTrust in einer unzureichenden Herkunftsprüfung innerhalb einer internen Messaging-Komponente. Unter passenden Bedingungen kann ein Angreifer dadurch Dateioperationen auf der Appliance auslösen. Entscheidend ist jedoch nicht nur das theoretische Schadenspotenzial: Mandiant hat die Ausnutzung bereits während eines Incident-Response-Einsatzes beobachtet und ordnet die Kampagne der mutmaßlich mit China verbundenen Spionagegruppe ARMORY CASTLE zu, die zuvor als UNC5221 geführt wurde.
Die Angreifer nutzten die Schwachstelle als Zero-Day, also bevor ein öffentlicher Patch und eine CVE-Beschreibung verfügbar waren. Nach dem ersten Zugriff installierten sie die neue PHP-Webshell SAWFLY und den ebenfalls neu dokumentierten SOCKS5-Tunneler BARECLAW. Damit schufen sie dauerhaften Fernzugriff, verschleierten ihre Kommunikation und konnten die kompromittierte Appliance als Sprungbrett in interne Netze einsetzen.
Besonders schwer wiegt der Zugriff auf die Vertrauensbeziehungen des Systems. Mandiant beobachtete Versuche, Zugangsdaten direkt aus dem BeyondTrust-eigenen Secrets-Speicher auszulesen. Außerdem missbrauchte der Akteur administrative Sitzungen, änderte Berechtigungen und griff über reguläre Remote-Support-Funktionen auf nachgelagerte Endpunkte zu. Ein kompromittiertes Gateway ist damit nicht bloß ein einzelner infizierter Server, sondern potenziell der Ausgangspunkt für Credential-Diebstahl, Datenabfluss und laterale Bewegung.
Patchen ist notwendig, aber allein nicht ausreichend
Wer eine selbst gehostete Remote-Support-Appliance betreibt, sollte BT26-05-RS sofort installieren oder den erfolgreichen automatischen Einbau ausdrücklich verifizieren. Der Patch schließt die Schwachstelle, beseitigt aber keine bereits vorhandene Kompromittierung. Eine Appliance, die während des bekannten Angriffsfensters verwundbar und aus dem Internet erreichbar war, sollte deshalb bis zum Abschluss einer Untersuchung als potenziell kompromittiert gelten.
Diese Unterscheidung ist für den Betrieb zentral. Ein grüner Patch-Status beantwortet nur die Frage, ob neue Exploit-Versuche noch funktionieren. Er beantwortet nicht, ob ein Angreifer bereits eine Webshell, Root-Persistenz, manipulierte Konfigurationen oder gestohlene Zugangsdaten hinterlassen hat. Mandiant berichtet ausdrücklich von gelöschten System-, Webserver- und Anwendungsprotokollen. Fehlende lokale Spuren sind deshalb kein belastbarer Entlastungsbeweis.
Prioritäten für Betreiber
- Version und Patchstatus erfassen: Alle Remote-Support-Appliances inventarisieren und BT26-05-RS auf jeder Instanz bestätigen. Bei Versionen vor 24.3.1 zuerst auf einen unterstützten Stand wechseln.
- Exposition bewerten: Festhalten, seit wann die Appliance öffentlich erreichbar war und welche administrativen Oberflächen aus dem Internet zugänglich waren. Firewall-, Reverse-Proxy- und WAF-Protokolle außerhalb der Appliance sichern.
- Verdachtsfälle forensisch erhalten: Vor Neustart oder Änderungen bei virtuellen Appliances Snapshot, Arbeitsspeicher und Datenträger sichern. Bei Hardware-Appliances den Hersteller-Support für die Beweissicherung einbeziehen.
- Zugänge kontrolliert rotieren: Erst patchen oder sauber neu aufsetzen, dann administrative Konten, API-Secrets, SAML-Schlüssel, Verzeichnisdienst-, Vault-, ITSM- und Integrationszugänge in sinnvoller Abhängigkeit rotieren.
- Konfigurationen vergleichen: Änderungen an Benutzern, Rollen, Jump Items, Jumpoints, API-Konten, Security Providern und Syslog-Zielen gegen einen bekannten guten Stand und gegen Change-Tickets prüfen.
Worauf Monitoring und Incident Response jetzt achten sollten
Die Kampagne zeigt, warum Telemetrie nicht ausschließlich auf dem zu schützenden Edge-System liegen darf. Ein Angreifer mit Root-Rechten kann lokale Protokolle verändern oder löschen. Syslog sollte daher verschlüsselt an ein separates, gegen Manipulation geschütztes System weitergeleitet werden. Zusätzlich liefern Perimeter-Firewalls, DNS, Reverse Proxies, WAFs und zentrale Identity-Systeme unabhängige Signale.
Für die Suche sind mehrere Beobachtungen relevant: ungewöhnliche PHP-Pfade, WebSocket-Upgrades außerhalb des erwarteten Support-Verkehrs, administrative Logins zu atypischen Zeiten oder aus VPN- und Hosting-Netzen, plötzlich erhöhte Jump-Item-Rechte, neue API-Konten sowie unerklärliche Lücken in der Logweiterleitung. Die von Mandiant genannten Dateien mangoapi.php und ingredi_ws sind konkrete Indikatoren, reichen für eine Entwarnung aber nicht aus. Werkzeuge und Dateinamen lassen sich ändern; das Verhalten bleibt aussagekräftiger.
Auch aus Monitoring-Sicht lohnt ein Blick auf die Abhängigkeiten. Neben der Erreichbarkeit der Appliance sollten Teams Zertifikatsänderungen, ausgehende Verbindungen, ungewöhnliche Bandbreite, fehlende Heartbeats und Änderungen an erwarteten Dienstpfaden überwachen. Status- und Uptime-Monitoring erkennen keine Webshell automatisch, können aber abrupte Neustarts, Isolationsmaßnahmen oder Dienstunterbrechungen mit dem Incident-Zeitstrahl verbinden. Gute Alarmierung sollte dabei nicht nur einen Fehler melden, sondern Verantwortliche, Runbook und Eskalationsweg eindeutig zuordnen.
Lehre für privilegierte Edge-Systeme
Remote-Support-, VPN- und Access-Appliances sind attraktive Ziele, weil sie Internet-Exposition mit weitreichendem Vertrauen kombinieren. Genau deshalb müssen sie wie kritische Identitäts- und Sicherheitsinfrastruktur behandelt werden: minimale öffentliche Angriffsfläche, restriktiver Managementzugang, phishing-resistente Mehrfaktor-Authentifizierung, getrennte Service-Konten, eingeschränkter ausgehender Verkehr und zentral gespeicherte Auditdaten.
Für BeyondTrust Remote Support empfiehlt Mandiant unter anderem, administrative Oberflächen auf vertrauenswürdige Netze zu begrenzen, den ausgehenden Verkehr standardmäßig zu sperren und lokale Konten bis auf einen überwachten Notfallzugang zu vermeiden. Wird eine Kompromittierung bestätigt oder kann sie nicht zuverlässig ausgeschlossen werden, ist ein Neuaufbau aus einem sauberen, vollständig gepatchten Image sicherer als der Versuch, ein System mit möglicher Root-Persistenz zu bereinigen.
Der Fall ist damit mehr als eine weitere CVE-Meldung. Er zeigt eine vollständige Angriffskette vom Zero-Day über Privilegienausweitung und Zugangsdatenzugriff bis zur lateralen Bewegung. Betreiber sollten die Veröffentlichung als Incident-Response-Auslöser verstehen: patchen, Exposition rekonstruieren, Beweise sichern, Zugänge nach der Bereinigung rotieren und die Überwachung privilegierter Gateways dauerhaft verbessern.
Bildquelle: Google Threat Intelligence Group / Mandiant, „ARMORY CASTLE Exploits BeyondTrust“, Abbildung der Angriffskette.
Quellen
- BeyondTrust Security Advisory BT26-05 zu CVE-2026-102764, 15. Oktober 2026
- Google Threat Intelligence Group und Mandiant: „ARMORY CASTLE Exploits BeyondTrust“, 15. Oktober 2026
- BleepingComputer: „BeyondTrust patches zero-day exploited in attacks since August“, 16. Oktober 2026
