Aktuell

Fernwartung als Generalschlüssel: Was der BeyondTrust-Zero-Day über Support-Zugänge lehrt

Seit August wurde eine Lücke in BeyondTrust Remote Support ausgenutzt. Was passiert ist und wie Sie Fernwartungszugänge jetzt prüfen und absichern.

17. Oktober 2026

Security
Identität & Zugang
Monitoring

Eine staatlich unterstützte Angreifergruppe hat eine bis dahin unbekannte Schwachstelle in BeyondTrust Remote Support rund sieben Wochen lang ausgenutzt, bevor sie öffentlich wurde. Das Werkzeug dient IT-Abteilungen und Dienstleistern dazu, sich auf die Rechner ihrer Anwender aufzuschalten. Wer es übernimmt, bekommt damit nicht ein einzelnes System, sondern den Weg zu allen Systemen, die darüber betreut werden. Das BSI hat am 16. Oktober 2026 einen Sicherheitshinweis mit der höchsten Kritikalitätsstufe veröffentlicht.

Schwachstelle

CVE-2026-102764

Unentdeckt ausgenutzt

ca. 7 Wochen

Im Internet erreichbar

über 1.400 Instanzen

Was passiert ist

Ablauf nach Angaben von BeyondTrust und BSI

29. August 2026
Erster Angriff
Die Gruppe nutzt die Lücke gegen eine von BeyondTrust gehostete Instanz und eine selbst betriebene Appliance eines Kunden.
27./28. September
Fund durch Threat Hunting
Nachdem ein Angriff auf einen anderen Hersteller bekannt wird, sucht BeyondTrust gezielt nach ähnlichen Mustern, findet die betroffene Instanz und isoliert sie nach eigener Aussage innerhalb von 27 Minuten.
30. September
Bestätigung durch Mandiant
Die Incident-Response-Einheit von Google bestätigt die Befunde aus der Kundenumgebung.
8. Oktober
Patch BT26-05
SaaS-Instanzen werden automatisch aktualisiert, selbst betriebene Appliances müssen manuell gepatcht werden, sofern keine automatischen Updates aktiv sind.
15. Oktober
Koordinierte Veröffentlichung
CVE, Advisory und die Analyse von Mandiant erscheinen gemeinsam.
16. Oktober
BSI-Sicherheitshinweis
CERT-Bund stuft die Lage mit Kritikalität 3 (sehr hoch) ein.
Heute

Google Threat Intelligence und BeyondTrust ordnen die Angriffe einer chinesischen Spionagegruppe zu, die Mandiant inzwischen „Armory Castle“ nennt (früher UNC5221, bei CrowdStrike Warp Panda). Dieselbe Gruppe wird für frühere Zero-Day-Angriffe auf Citrix NetScaler und Ivanti Connect Secure verantwortlich gemacht. Betroffen ist Remote Support bis einschließlich Version 26.2.3. Den Patch BT26-05-RS gibt es für die Versionen ab 24.3.1, ältere Installationen müssen zuerst auf einen unterstützten Stand gebracht werden. Einzelne Medien nennen abweichend „Versionen vor 26.2.3“, maßgeblich ist das Herstelleradvisory. Privileged Remote Access (PRA) teilt den betroffenen Code. BeyondTrust hat dort keinen Angriffsweg gefunden, empfiehlt den Patch aber vorsorglich ebenfalls.

Warum der Fall technisch bemerkenswert ist

Eine Fernwartungs-Appliance ist mehr als ein Server mit Webportal. Sie speichert Zugangsdaten für die betreuten Systeme oder reicht sie bei Sitzungen weiter, und sie kennt jede Verbindung, die Techniker regelmäßig aufbauen. Nach der Übernahme legten die Angreifer eine Web-Shell ab, also ein Skript, über das sie die Appliance im Browser fernsteuern konnten. Mit erbeuteten Administratorzugängen hoben sie im Portal die Rechte für sogenannte Jump Items und Teams von „kein Zugriff“ auf „Administrator“ an. Jump Items sind die hinterlegten Zielsysteme, auf die sich ein Techniker mit einem Klick verbinden kann. Vor dem Rückzug löschten sie die lokalen Protokolle.

Der Alarm kam – und wurde automatisch geschlossen

Lehre für jedes SOC

Bemerkenswert offen beschreibt BeyondTrust die eigene Erkennung: Die Sensoren haben beim Rechteausbau in Echtzeit angeschlagen. Die automatische Vorbewertung der eingesetzten Detection-Plattform hat diese Meldungen aber als Fehlalarm eingestuft und geschlossen. Gefunden wurde der Angreifer erst durch eine gezielte Suche, die unabhängig von Alarmen läuft und von aktuellen Bedrohungsinformationen ausgeht.

Was Betreiber jetzt prüfen sollten

Version und Patchstand prüfen. Im Verwaltungsbereich der Appliance (/appliance) die Version ablesen und BT26-05 einspielen. Bei Versionen unter 24.3.1 zuerst auf einen unterstützten Stand aktualisieren. Wer PRA selbst betreibt, patcht dort ebenfalls.
Erreichbarkeit reduzieren. Aus dem Internet nur den Teil freigeben, den Kunden und Anwender wirklich brauchen. Die Administrationsoberfläche gehört auf vertrauenswürdige Netze oder hinter ein VPN. Ausgehenden Verkehr der Appliance auf die nötigen Ziele beschränken.
Protokolle von der Appliance wegleiten. Syslog und Sitzungsereignisse nahezu in Echtzeit an ein SIEM senden. Da die Angreifer lokale Logs löschen, ist die Kopie außerhalb oft der einzige Nachweis. Lücken in der Weiterleitung, die genau eine Sitzung lang dauern, sind selbst ein Warnsignal.
Nach Verhalten suchen, nicht nur nach Indikatoren. Geänderte Berechtigungen für Jump Items und Teams, Administratorsitzungen von privaten Breitbandanschlüssen oder kommerziellen VPN-Diensten ohne passendes Ticket, unbekannte Skriptdateien in Webverzeichnissen. Die Gruppe wechselt Infrastruktur und Werkzeuge pro Opfer, feste IP-Listen helfen deshalb wenig.
Bei jedem Befund: alle hinterlegten Zugangsdaten tauschen. Jedes Kennwort, das die Appliance gespeichert oder in Sitzungen eingesetzt hat, gilt dann als bekannt. Neue MFA-Registrierungen an privilegierten Konten prüfen und die Appliance als Image sichern, bevor sie neu aufgesetzt wird.
Den Blick über BeyondTrust hinaus richten. Eine Liste aller Fernwartungswerkzeuge im Haus erstellen, auch der, die Softwarelieferanten für ihre Fachverfahren mitbringen. Für jedes klären: Wer betreibt es, wie wird es aktualisiert, ist MFA aktiv und wohin gehen die Protokolle?

Einordnung

Vier Punkte nehmen wir aus dem Fall mit:

Fernwartung ist privilegierte Infrastruktur. Sie gehört in dieselbe Kategorie wie Firewall, VPN-Gateway und Domänencontroller und braucht denselben Patch- und Überwachungsrhythmus. Dass Angreifer gezielt solche Randsysteme übernehmen, haben wir zuletzt im Beitrag „Wenn der Torwächter fällt“ beschrieben.
Nach der Veröffentlichung beginnt die zweite Welle. BeyondTrust und Mandiant gehen davon aus, dass die Gruppe nach der Bekanntgabe auf breite Ausnutzung aller noch ungepatchten Systeme umschwenkt. Die Zeit zwischen Advisory und Patch muss deshalb in Tagen gemessen werden, nicht in Wartungsfenstern. Mehr dazu in unserem Beitrag zur negativen Time-to-Exploit.
Automatisierte Vorbewertung darf kritische Alarme nicht allein schließen. Das gilt für jedes SIEM und jede XDR-Plattform. Meldungen mit hohem Schweregrad sollten von einem Menschen gesehen werden, auch wenn das System sie für harmlos hält.
Kunden dürfen ihren Dienstleister fragen. Wer einem IT-Dienstleister Fernzugriff gibt, sollte wissen, welches Werkzeug dabei im Einsatz ist, wo es betrieben wird, ob MFA erzwungen wird und ob Sitzungen protokolliert werden. Diese Fragen sind keine Misstrauenserklärung, sondern Teil einer ordentlichen Lieferkettenprüfung, wie sie auch NIS2 verlangt.

Anlass für diesen Beitrag war der Sicherheitshinweis des BSI vom 16. Oktober 2026 zur ausgenutzten Zero-Day-Lücke in BeyondTrust Remote Support.