ConnectWise hat fünf Drittanbieter-Erweiterungen vorsorglich deaktiviert, nachdem Berichte über unbefugten Zugriff auf Partnerumgebungen eingegangen waren, wie The Hacker News am 12. November 2026 berichtete. Huntress beobachtete, dass Angreifer über cloudgehostete ScreenConnect-Verwaltungsoberflächen Befehle absetzten, um nicht autorisierte Remote-Zugriffsclients zu installieren. Die Angreifer zielten dabei auf mindestens 288 verwaltete Endpunkte in 48 Organisationen.
Die Maßnahme betrifft Partner, die Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link oder RMM+ Password Link einsetzen. ConnectWise fand mindestens eine dieser Erweiterungen in rund 400 Partnerumgebungen. Diese Zahl bezieht sich auf Installationen und belegt nicht, wie viele Umgebungen kompromittiert wurden. Partner, die ScreenConnect selbst vor Ort betreiben, wurden aufgefordert, die Erweiterungen selbst zu deaktivieren.
In seiner Warnmeldung erklärte ConnectWise laut The Hacker News, seine vorläufige Bewertung deute auf einen möglichen Missbrauch unabhängiger Drittanbieter-Erweiterungen hin. Das Unternehmen untersuche noch sowohl den Einstiegsweg als auch den Umfang. Es gebe keine Hinweise darauf, dass die eigene Infrastruktur kompromittiert wurde oder dass eine ScreenConnect-Schwachstelle beteiligt war. Die Erweiterungen ermöglichen es Software, Remote-Befehle über eine Anwendungsprogrammierschnittstelle (API) auszuführen. Diese ist durch eine Passphrase geschützt, die der Partner bei der Einrichtung wählt.
Nicht autorisierte Clients verschaffen einen separaten Zugangspunkt
Huntress erkannte die Aktivität erstmals gegen 17:47 Uhr UTC am 11. November 2026. Das Unternehmen erklärte gegenüber The Hacker News, seine Telemetriedaten deuteten darauf hin, dass gestohlene Zugangsdaten oder übernommene Bediener-Sitzungen den Zugriff auf die Oberflächen erklären könnten. Der Einstiegsweg sei jedoch weiterhin ungeklärt, und man habe keine Hinweise auf eine neue Schwachstelle gesehen.
Hat sich ein Angreifer in einer Oberfläche festgesetzt, kann er deren Funktion „Run Command“ nutzen, um auf verwalteten Geräten einen vom Angreifer kontrollierten ScreenConnect-Client zu installieren. Diese Installation verschafft dem Angreifer dauerhaften Zugriff, ohne dass er auf die ursprüngliche Oberfläche angewiesen ist.
Die Huntress-Forscher Ben Nahorney und Susannah Matt identifizierten SCKit als das schädliche Toolkit, das über die betrügerischen Clients ausgeliefert wird. Neben dem dauerhaften Fernzugriff richtet es eine Falle ein, die Sitzungs-Cookies abfangen soll. Dabei handelt es sich um Browserdaten, mit denen angemeldete Sitzungen aufrechterhalten werden.
Das Toolkit kommt über eine verschlüsselte Nutzlast und über sckit-run.bat an. Dabei handelt es sich um einen Dropper, also ein Skript, das weitere Schadsoftware nachlädt. Er ist mit Base64 kodiert, einer Methode, Daten als Text darzustellen. Das Batch-Skript fordert sckit-decoder.ps1 von einem Remote-Server an. Dieses PowerShell-Skript startet SCKit. Weitere Komponenten sind darauf ausgelegt, Dateien oder Speicherorte von der Prüfung durch Microsoft Defender auszunehmen, einen weiteren vom Angreifer kontrollierten ScreenConnect-Client hinzuzufügen, eine geplante Aufgabe namens TrapWatch anzulegen und eine legitime Installation durch eine vom Angreifer kontrollierte zu ersetzen.
Der Bericht beschreibt außerdem Anzeichen für eine mögliche Beteiligung eines großen Sprachmodells (Large Language Model) an mindestens einem Skript. Die Hinweise stützen sich auf detaillierte Code-Verweise und Kommentare, die die Funktionsweise erklären.
Ein Verbreitungsmechanismus, aus den Dateien rekonstruiert
Die Analyse von Huntress ergab eine wurmartige Struktur, die die Verbindung eines Technikers in einen Weg zu weiteren Geräten verwandeln könnte. Ein infizierter Endpunkt könnte Schadsoftware an den Arbeitsplatzrechner eines verbindenden Technikers weitergeben. Dort könnten gespeicherte Browsersitzungen und Authentifizierungs-Token andere ScreenConnect-Oberflächen offenlegen. Diese Token sind Zugangsdaten, mit denen Software Zugriffe autorisiert.
Diese Verbreitungsfähigkeit ergibt sich teilweise aus der Analyse der Nutzlasten. Huntress hatte jedoch weder eine erfolgreiche Übertragung von einem infizierten Endpunkt auf den Arbeitsplatzrechner eines Technikers noch von dort auf weitere Endpunkte beobachtet.
Die rekonstruierte Abfolge beginnt mit Run-Lateral-Full.bat. Sie nutzt die Verbindung, um ns.mo7sen[.]dev zu erreichen und einen Loader abzurufen. Dieser sammelt die eindeutige Kennung des Arbeitsplatzrechners und sendet sie an den Angreifer. Die Antwort liefert ein verschlüsseltes Toolkit, das für diesen Arbeitsplatzrechner angepasst ist.
Zwei Skripte, Panel-Lateral.ps1 und LabConfig.ps1, arbeiten zusammen, um das Sitzungs-Cookie .aspxauth abzugreifen. Sie versuchen, es der Oberfläche als authentifizierte Sitzung vorzulegen, und erhalten die Token, die nötig sind, um weitere Sitzungen aufzulisten, auf die der Techniker zugreifen kann.
Anschließend nutzt ToolboxRelayUploader.exe den so erlangten Zugriff, um WithUninstall.ps1 in der Shared Toolbox der Oberfläche abzulegen. Über die Oberfläche wird eine Anfrage gestellt, die jede erreichbare Sitzung anweist, diesen Eintrag auszuführen. Die Nutzlast ist so ausgelegt, dass sie unter SYSTEM läuft, einem Windows-Konto mit sehr hohen Rechten, und die Falle auf diesen Endpunkten installiert. Etwa 60 Sekunden nach dieser Verteilung entfernt der Uploader den Toolbox-Eintrag wieder.
Huntress fand außerdem fortlaufende Nummernkennungen, die kompromittierten Managed Service Providern (MSPs) zugewiesen waren. Dabei handelt es sich um Unternehmen, die Kundensysteme verwalten. Da die beobachtete Nummerierung mitten in der Reihenfolge begann, vermuteten die Forscher, dass andere Provider womöglich schon früher kompromittiert worden waren.
Sophos verzeichnet ein passendes Installationsmuster
Eine separate Sophos-Warnung beschrieb nicht autorisierte ScreenConnect-Bereitstellungen, die von drei Instanz-IDs ausgingen, bei denen ein Kompromittierungsverdacht besteht: d905b2b1b165d0a9, 4b8f4089ddaac6a9 und df1f7ef0cfacd0d8. Die weiteren schädlichen Instanzen, die im Zuge dieser Aktivität bereitgestellt wurden, hatten die IDs 2588ef5c15954b10 und ed630cc2c873b091.
Bei einer beobachteten Installation wurde mit Curl.exe ScreenConnect.ClientSetup.msi von 185.99.255[.]28 abgerufen und als C:\Windows\TEMP\sc.msi gespeichert. Eine von ScreenConnect erzeugte Befehlsdatei rief anschließend msiexec.exe auf, um das Paket lautlos zu installieren. Sophos beobachtete außerdem Skripte, die Batch-Dateien auf Systemen ablegten und PowerShell mit Umgehung der Ausführungsrichtlinie (execution-policy bypass) starteten, um ein Second-Stage-Skript von ns[.]mo7sen[.]dev/EadF.php?p=4 abzurufen.
Prüfungen für Partner und Techniker
ConnectWise stellte die folgenden Indikatoren für Kompromittierungen bereit. Dabei handelt es sich um Adressen und Dateien, mit denen Ermittler nach verwandter Aktivität suchen können:
- IP-Adressen:
185.99.255[.]28,155.94.150[.]39 - Domains und URL:
ns[.]mo7sen[.]dev,ns[.]mo7sen[.]dev/EadF.php?p=4,sc[.]payproofkit[.]com,cdn007-digitaldownloads[.]com,newnewnew[.]gotdns[.]org,Soxnewwork[.]homedns[.]org - Dateien:
sckit-run.bat,sckit-decoder.ps1,TrapWatch.ps1,Panel-Lateral.ps1,Run-Lateral-Full.bat,runnew.cmd,ToolboxRelayUploader.exe,Sqlite3.exe
ConnectWise empfiehlt allen Partnern, zu prüfen, ob ihre Sicherheitskontrollen funktionieren, und Protokolle mit verdächtiger Aktivität aufzubewahren. Die Hinweise sehen vor, Folgendes zu überprüfen:
- Anmeldungen von unbekannten Standorten, wiederholte Authentifizierungsfehler und unerwartete Aufforderungen zur Multi-Faktor-Authentifizierung, mit denen eine zusätzliche Bestätigung der Anmeldung verlangt wird.
- Neu angelegte Administratorkonten und geänderte Benutzerberechtigungen.
- Unerwartete Installationen von Erweiterungen, Remote-Befehle und Vorgänge in der Toolbox.
- Nicht genehmigte Fernzugriffssoftware auf Kundengeräten oder Arbeitsplatzrechnern von Technikern.
- Unerwartete Support-Anfragen, Nachrichten zum Zurücksetzen von Passwörtern und Software-Downloads, die über einen vertrauenswürdigen Kanal eingehen.
Partner mit lokalen Bereitstellungen sollten die fünf von ConnectWise genannten Erweiterungen deaktivieren. ScreenConnect-Nutzer sollten zudem ihren Run-Command-Verlauf prüfen, auch wenn kein Alarm ausgelöst wurde.
