ConnectWise schließt eine 9,9-bewertete ScreenConnect-Lücke, die in wurmartigen Angriffen ausgenutzt wurde

ConnectWise hat ein Notfallupdate für ScreenConnect veröffentlicht, seine Software für Fernsupport und Fernzugriff, um eine kritische Lücke auf der Client-Seite zu schließen, die einem Angreifer erlaubte, Dateien innerhalb einer aktiven Sitzung zu verschieben und auszuführen, ohne dass der Host zustimmt. Der Fix, ScreenConnect 26.6.5, erschien am 8. September, wie aus dem Sicherheitsbulletin des Herstellers hervorgeht. Die Schwachstelle, geführt als CVE-2026-84869, hat einen CVSS-Wert von 9,9 von 10, und Forscher hatten bereits etwa zwei Wochen lang beobachtet, wie sie ausgenutzt wurde, bevor ein Patch existierte.

Zum Weiterlesen: Angreifer nutzten die App-Identität von ConnectWise Cloud Backup für Anmeldungen in Microsoft-365-Tenants · FBI verhaftet OpenAI-Mitarbeiter, der ein verstecktes Aufnahmegerät platziert haben soll.

Der Fehler sitzt im ScreenConnect-Client, nicht im Server. ConnectWise beschreibt einen Zustand, in dem Dateiübertragungen unter bestimmten Umständen „durch eine aktive Remote-Sitzung ohne Autorisierung oder Host-Bestätigung" ablaufen können, und erklärt, dass ScreenConnect-Server nicht betroffen sind. In der Praxis kann ein Angreifer, der bereits in einer Sitzung sitzt, eine Datei auf den verbundenen Endpunkt schieben und ausführen, auch über Aktionen mit erhöhten Rechten.

Was Huntress beobachtet hat

Die Sicherheitsfirma Huntress hat die Aktivität dokumentiert, sie Ende August erstmals gemeldet und ihre Ergebnisse am 9. September in einer ausführlichen Analyse veröffentlicht. In drei voneinander unabhängigen Vorfällen fanden ihre Analysten gefälschte ScreenConnect-Installationen auf Opferrechnern, die wiederholt wscript.exe starteten, um vier Skripte mit den Namen 1.vbs bis 4.vbs auszuführen.

Die gefälschten Installationen kamen über Social Engineering. Eine begann mit einem Tech-Support-Betrug über Windows Quick Assist. Eine weitere folgte auf die Suche nach einem Geek-Squad-Rückerstattungsformular, die das Opfer dazu brachte, eine heruntergeladene Client-Setup-Datei auszuführen. Eine dritte begann mit einem vergifteten Suchergebnis, das eine gefälschte ScreenConnect.Client.exe unterschob. Das sind vertraute Taktiken: Werkzeuge für Remote-Monitoring und -Management (RMM) sind für Kriminelle attraktiv, gerade weil sie vertrauenswürdige Software sind, die tief in ein Netzwerk reicht.

Was diese Kampagne anders machte, war das, was die modifizierten Clients als Nächstes taten. Laut Huntress beobachtete der gefälschte Client die Verbindungsliste von ScreenConnect, und sobald eine neue Host-Sitzung erschien, registrierte er die vier VBScript-Dateien im eigenen Dateiübertragungssystem der Software und schob sie auf den neu verbundenen Rechner. Die Kette wiederholte sich dann auf diesem Endpunkt. Huntress nannte das Verhalten wurmartig, weil sich die Nutzlast von Sitzung zu Sitzung von selbst ausbreitet, statt darauf zu warten, dass ein Operator die Arbeit von Hand wiederholt.

Auf jedem Host hinterließen die Eindringlinge zudem einen Windows-User-Run-Schlüssel namens WindowsServiceHost, der auf WindowsServiceHost.vbs im AppData-Ordner des Nutzers zeigte, und in mindestens einem Vorfall installierten sie ein zweites Fernzugriffswerkzeug, UltraViewer. Huntress listete Command-and-Control-Adressen auf, die während der Vorfälle gesehen wurden, darunter 45.13.237[.]190, 131.123.40[.]98 und 15.204.185[.]204.

Der vierstufige Loader

Die Skripte waren darauf angelegt, jeden Rechner zu profilieren, bevor sie eine Nutzlast auswählten. Das erste, 1.vbs, schrieb einen Drei-Bit-Wert in eine temporäre Datei, der beschrieb, ob ScreenConnect bereits installiert war, welche Sicherheitsprodukte liefen und wie viel Speicher der Host hatte. Die Speicherprüfung, so Huntress, ist ein gängiger Weg, um zu verhindern, dass eine Nutzlast in einer kleinen Analyse-VM läuft.

Ein zweites Skript wartete auf diesen Wert, holte eine Datei von Dropbox, dekodierte sie mit einem Ein-Byte-XOR-Schlüssel und erzeugte einen Katalog weiterer Nutzlasten, der auf den Drei-Bit-Wert abgestimmt war. Ein drittes Skript las den Katalog und lud den passenden Eintrag herunter, der verschlüsselt als out.enc gespeichert wurde. Das vierte entschlüsselte ihn mit einem AES-Schlüssel aus dem Katalog, startete einen PowerShell-Runner, entschlüsselte ein zweites Archiv in ein Windows-Vorlagenverzeichnis, löschte die Staging-Dateien und beendete alle verbleibenden Skript-Hosts.

Zu den Ergebnissen, die Huntress beobachtete, gehörten ein UAC-Bypass auf Basis des ms-settings-Protokollhandlers, ein Versuch, die Antimalware-Scan-Schnittstelle abzuschalten, ein Microsoft-Defender-Ausschluss für den gesamten C:\Users-Baum und ein versteckter ScreenConnect-Client, dessen Deinstallations-Eintrag und Dienstbeschreibung entfernt worden waren, damit er nicht an den üblichen Stellen auftaucht. Eine Nutzlastvariante lieferte zudem einen Kryptominer, ein Zeichen für finanziell motivierte Vorgehensweise.

Ein Detail sticht für Verteidiger hervor. Ein Kommentar in 3.vbs legte das erwartete Format des Nutzlastkatalogs dar, die Art erklärender Notiz, die ein menschlicher Entwickler hinterlässt. Huntress schrieb, das Skript sei „wahrscheinlich" von einem großen Sprachmodell erzeugt worden. Massenmalware, die mit denselben Assistenten zusammengesetzt wird, die gewöhnlichen Code schreiben, ist inzwischen Routine bei der Incident Response, und sie lässt die Skripte sauberer lesen, als es ihre Absicht verdient.

Verzweigte Nutzlasten

Nicht jeder Host erhielt dasselbe Paket. Huntress fand, dass der Katalog das Drei-Bit-Profil einer von drei verschlüsselten Nutzlasten zuordnete: einer Hintertür auf Nutzerebene über ScreenConnect, einem Zugriffspaket mit Werkzeugen für Persistenz und Rechteausweitung oder einem kombinierten Paket, das laut Huntress Tunneling-Werkzeuge und einen Kryptominer enthielt. Ein Zielprofil zu erstellen und dann eine Nutzlast auszuwählen, ist gewöhnliche Vorgehensweise für einen Loader dieser Art, zeigt aber, dass die Operatoren Rechner sortierten, statt eine einzige Stufe auf alles zu sprühen, was sie berührten.

Wie die Reaktion verlief

Die Offenlegung lief nach einem komprimierten Zeitplan. ConnectWise veröffentlichte am 3. September ein Advisory, das vor einem Problem beim Dateiübertragungsverhalten in den Support- und Zugriffssitzungen von ScreenConnect in Cloud- und On-Premises-Bereitstellungen warnte, und kündigte an, dass eine CVE und ein offizieller Fix innerhalb der Woche folgen würden; Partnern empfahl das Unternehmen, in der Zwischenzeit die Berechtigung TransferFiles zu prüfen und zu deaktivieren. Huntress, das die Anomalien seit Ende August verfolgt hatte, aktualisierte seine Analyse am 8. September, als der Patch 26.6.5 erschien, und erneut, als sich das Bild der Ausnutzung füllte. CISA nahm die Schwachstelle am 11. September in seinen Katalog auf und machte damit aus einer Herstellerbehebung eine Frist des Bundes vom 14. September für zivile Behörden. Die Abfolge, erst das Advisory, Tage später der Patch, dann die Einstufung als nachweislich ausgenutzt, ist zum Standardrhythmus für einen ernsten Fehler in Unternehmenssoftware geworden, ließ aber dennoch etwa zwei Wochen zwischen den ersten beobachteten Eindringlingen und einem Fix.

Warum Fernzugriff immer wieder das Ziel ist

ScreenConnect wird von Managed Service Providers und IT-Helpdesks breit eingesetzt. Genau das macht es für Angreifer wertvoll: Es ist legitime Software mit weiter Reichweite in Kundennetze, und sie läuft mit den Rechten, die ein Helpdesk-Techniker haben soll. RMM-Missbrauch ist seit Jahren ein Spitzenangriffsvektor, und ScreenConnect hat das schon erlebt. Eine Authentifizierungsumgehung im Produkt aus dem Jahr 2024 wurde breit ausgenutzt, und das Muster, über eine Fernsupport-Sitzung Werkzeuge abzulegen, ist so verbreitet geworden, dass Verteidiger RMM-Installationen inzwischen als eigene Erkennungsfläche behandeln.

Für einen Managed Service Provider steht mehr auf dem Spiel als für ein einzelnes Unternehmen. Ein MSP verwaltet oft viele Kunden über eine einzige ScreenConnect-Bereitstellung, sodass ein kontaminierter Client, der Nutzlasten an neue Sitzungen schiebt, auch nachgelagerte Kunden bedrohen kann, dazu die eigenen Rechner des Anbieters. Das ist ein Lieferkettenproblem im Kleinen, und deshalb trifft der Rat des Herstellers, die Dateiübertragungsberechtigungen von Sitzungen zu prüfen, Dienstleister am dringendsten.

Das Ausbreitungsmodell ist das Neue. RMM-Missbrauch hängt normalerweise davon ab, dass ein Operator ein Werkzeug Rechner für Rechner schiebt, was begrenzt, wie schnell sich ein Einbruch ausbreitet, und Verteidigern mehr Chancen gibt, ihn zu bemerken. Ein Client, der die nächste Stufe auf jeden Rechner schiebt, mit dem er sich später verbindet, beseitigt diesen Engpass. Er erschwert auch die Zuordnung, weil jeder Rechner in derselben ScreenConnect-Bereitstellung zu einem möglichen Lieferpunkt wird.

Die Patch-Frist

CISA nahm CVE-2026-84869 am 11. September in seinen Katalog bekannter ausgenutzter Schwachstellen auf und gab zivilen Bundesbehörden bis zum 14. September Zeit für die Behebung, im Rahmen der Binding Operational Directive 26-04. Es war einer von drei Einträgen an diesem Tag und Teil eines breiteren Clusters, den die Behörde in dieser Woche katalogisierte, neben zwei Fehlern in MikroTik RouterOS und zwei Fehlern in JFrog Artifactory, die laut The Hacker News in Angriffen auf selbst gehostete Server verkettet wurden. SecurityWeek gehörte zu den Medien, die die Ausnutzung von ScreenConnect bestätigten.

Zwei Einschränkungen sollte man im Blick behalten. Die Beschreibung als wurmartig stammt aus der Untersuchung von Huntress und nicht von ConnectWise, und sie beschreibt die Ausbreitung von Sitzung zu Sitzung zwischen Rechnern, die sich eine ScreenConnect-Bereitstellung teilen, nicht die selbsttragende, internetweite Verbreitung, die das Wort Wurm üblicherweise impliziert. Zudem hat keines der beiden Unternehmen die Kampagne einer benannten Gruppe zugeordnet. Die gemeinsame Miner-Komponente und die Köder aus dem Verbrauchersupport deuten auf einen finanziell motivierten Operator hin, doch das ist eine Schlussfolgerung aus der Vorgehensweise, keine bestätigte Identifizierung.

Was zu beobachten ist

Die unmittelbare Frage für jede Organisation, die ScreenConnect betreibt, ist, ob die modifizierten Clients Rechner außerhalb des Bestands erreicht haben, den ihre eigenen Administratoren kennen, denn der ganze Sinn der Ausbreitung ist, auf Endpunkten zu landen, die der Operator nicht direkt berührt hat. Audit-Logs, die zeigen, dass ein Gastprozess Dateien auf einem Host ausführt, sind der Ort, an dem man anfangen sollte.

Die längerfristige Frage ist, ob dieselbe Technik in anderen Fernsupport-Produkten auftaucht. Der zugrunde liegende Zustand, ein Client, der auf Sitzungsanweisungen ohne klare Berechtigungsprüfung reagiert, dürfte kaum auf einen Hersteller beschränkt sein. ConnectWise hat den Fix ausgeliefert; der Rest des RMM-Markts hat nun einen Grund zu prüfen, wie seine eigenen Clients entscheiden, welchen Dateiübertragungen sie trauen.

Bild: ScreenConnect-Logo von ScreenConnect, via Wikimedia Commons, lizenziert unter CC BY-SA 4.0. Das Bild wurde zugeschnitten und auf einen Hintergrund gesetzt.