BeyondTrust Remote Support: Kritische Sicherheitslücke wird ausgenutzt – warum Patchen allein nicht reicht

Worum es geht

BeyondTrust Remote Support, früher unter dem Namen Bomgar bekannt, ist eine Fernwartungslösung für IT-Abteilungen und Dienstleister. Techniker verbinden sich darüber auf Rechner und Server, oft mit hinterlegten Zugangsdaten. Das macht die Appliance zu einem besonders lohnenden Ziel: Wer sie kontrolliert, kommt potenziell an viele Systeme dahinter.

Am 15. Oktober 2026 hat BeyondTrust die Advisory BT26-05 veröffentlicht. Die Lücke CVE-2026-102764 steckt laut Hersteller in einer internen Nachrichtenkomponente, die die Herkunft eingehender Nachrichten nicht ausreichend prüft. Unter bestimmten Bedingungen lassen sich so Dateioperationen auf der Appliance ausführen. BeyondTrust bewertet die Lücke mit CVSS v4.0 9.3 (kritisch), eine Anmeldung ist laut Bewertung nicht nötig. Technische Details hält der Hersteller bewusst zurück.

Wer betroffen ist

Selbst betriebene Appliances müssen laut Advisory manuell gepatcht werden, wenn sie in der Verwaltungsoberfläche nicht für automatische Updates eingetragen sind. Ich würde mich nicht darauf verlassen, dass das automatisch passiert ist, sondern die installierte Version und den Patchstand selbst nachsehen.

Was bisher bekannt ist

BeyondTrust hat in einem Blogbeitrag eine Zeitlinie veröffentlicht. Demnach wurde die Lücke am 29. August 2026 bei zwei Kunden ausgenutzt: bei einer von BeyondTrust gehosteten Instanz und bei einer selbst betriebenen. Erkannt wurde der Angriff erst am 28. September. Am 30. September bestätigte Mandiant die Befunde, am 8. Oktober erschien der Patch, am 15. Oktober folgte die Veröffentlichung. Zum Stand des Beitrags vom 16. Oktober waren dem Hersteller nur diese zwei betroffenen Kunden bekannt.

Bemerkenswert finde ich ein Detail aus dem Bericht: Die Sensoren von BeyondTrust schlugen laut Hersteller an, als die Angreifer ihre Rechte ausweiteten. Das automatische Triage-Werkzeug der eingesetzten Erkennungsplattform eines Drittanbieters schloss diese Alarme aber als Fehlalarm. Gefunden wurde der Angriff erst durch eine gezielte Suche, fast einen Monat später. BeyondTrust zieht daraus die Lehre, dass automatische Bewertungen nur ein Hinweis sein sollten und schwere Alarme nicht allein schließen dürfen.

Mandiant, Teil von Google, hat die Angriffe untersucht. Verantwortlich ist laut Mandiant die Gruppe ARMORY CASTLE, früher als UNC5221 geführt, eine mutmaßlich China-nahe Spionagegruppe. Nach dem ersten Zugriff legten die Angreifer laut Bericht eine Webshell ab, erweiterten ihre Rechte bis auf Root-Ebene, löschten Logs und veränderten Berechtigungen kompromittierter Administratorkonten. BeyondTrust schreibt, die Gruppe nutze eine Zero-Day-Lücke zunächst gezielt und gehe nach der Veröffentlichung typischerweise zur breiten Ausnutzung aller ungepatchten Systeme über. Mandiant warnt, damit auch hier zu rechnen.

Warum Patchen allein nicht reicht

Der wichtigste Satz steht in der Warnung des BSI vom 16. Oktober: „Ein erfolgreiches Update allein schließt eine bereits erfolgte Kompromittierung nicht aus.“ Das BSI stuft die Lage als Kritikalität 3 (orange) ein und hält weitere, opportunistische Ausnutzung für wahrscheinlich. Mandiant formuliert es noch deutlicher: Jede Appliance, die im Ausnutzungszeitraum mit einer verwundbaren Version aus dem Internet erreichbar war, sollte bis zur Prüfung als möglicherweise kompromittiert gelten.

Der Grund ist einfach. Ein Angreifer mit Root-Rechten auf der Appliance kann sich dort so einnisten, dass er einen Neustart und das Zurücksetzen der Konfiguration übersteht. Kunden können das Dateisystem der Appliance laut Mandiant nicht selbst prüfen. Deshalb rät Mandiant bei bestätigter oder unklarer Lage zum Neuaufbau aus einem sauberen, gepatchten Image statt zum Bereinigen.

Warum mich das auch in der OT interessiert

Fernwartung ist in der Industrie Alltag: Maschinenbauer, Integratoren und Servicepartner greifen auf Anlagen zu, oft über zentrale Zugangslösungen. Ob dort BeyondTrust oder ein anderes Produkt läuft, das Muster ist dasselbe. Die Fernwartungsplattform hält die Schlüssel zu vielen Systemen und ist meist aus dem Internet erreichbar. Fällt sie, fällt der Schutz dahinter gleich mit.

Für mich heißt das: Ein Fernwartungszugang gehört in eine eigene Zone mit klar geregelten Verbindungen zu den Anlagen, wie es die IEC 62443 mit Zonen und Conduits beschreibt. Die Grundlagen dazu habe ich in IEC 62443 einfach erklärt zusammengefasst. Und die Verwaltungsoberfläche einer solchen Plattform hat im Internet nichts zu suchen.

Was du jetzt tun solltest

1. Version prüfen und patchen. Prüfe in der Verwaltungsoberfläche, ob der Patch BT26-05-RS installiert ist. Bei Versionen vor 24.3.1 zuerst auf eine unterstützte Version aktualisieren. Wenn du Privileged Remote Access einsetzt, spiel auch dort den vorsorglichen Patch ein.
2. Erreichbarkeit einschränken. Laut Mandiant sollten aus dem Internet nur die Techniker-Konsole, das Kundenportal und der Verkehr der Jump Clients erreichbar sein. Die Verwaltungsoberflächen unter /login und /appliance gehören auf bestimmte IP-Adressen oder Netzsegmente beschränkt.
3. Nach Spuren suchen. CISA und BeyondTrust nennen unter anderem unbekannte privilegierte Sitzungen, unbekannte Skriptdateien, Lücken in den Logs oder der Log-Weiterleitung sowie ungeplante Änderungen an Konten, Berechtigungen, Jump Items oder Teams. Leite Syslog und Sitzungsereignisse an ein SIEM weiter, falls das noch nicht passiert.
4. Bei Verdacht isolieren und sichern. Trenne die Appliance vom Netz, zieh einen Snapshot oder ein forensisches Image und sichere Firewall-, Proxy- und WAF-Logs für den Zeitraum ab Ende August.
5. Neu aufbauen statt reparieren. Bei bestätigter oder unklarer Kompromittierung aus einem sauberen Zustand neu aufsetzen und dann patchen. Nur Konfigurationssicherungen aus der Zeit vor dem Ausnutzungszeitraum zurückspielen, oder eine neuere Sicherung erst isoliert prüfen, bevor die Appliance wieder ins Netz geht.
6. Zugangsdaten rotieren, aber erst danach. Nach Patch oder Neuaufbau alle Zugangsdaten ändern, die die Appliance gespeichert oder vermittelt hat, alle aktiven Sitzungen beenden und neue MFA-Registrierungen an privilegierten Konten prüfen. Mandiant weist ausdrücklich darauf hin, nicht vorher zu rotieren: Sonst landen die neuen Passwörter direkt beim Angreifer.
7. Dienstleister fragen. Wenn ein Servicepartner per BeyondTrust auf deine Systeme zugreift, frag nach, ob seine Instanz gepatcht und geprüft ist.

Häufige Fragen

Quellen

• BeyondTrust: Security Advisory BT26-05, CVE-2026-102764 (15.10.2026)
• BeyondTrust: Blogbeitrag zu BT26-05 mit Zeitlinie und Empfehlungen (Stand 16.10.2026)
• Google Threat Intelligence Group / Mandiant: ARMORY CASTLE Exploits BeyondTrust (15.10.2026)
• CISA: CISA Urges Patching Critical Vulnerability in BeyondTrust Remote Support (16.10.2026)
• BSI: Cybersicherheitswarnung 2026-297832-1032, BeyondTrust Remote Support (Version 1.0, 16.10.2026, PDF)

Stand: 22.10.2026.