In einem Sicherheitshinweis schreibt ConnectWise, nach einer ersten Einschätzung könnte ein Angreifer unabhängige Drittanbieter-Erweiterungen missbraucht haben, die in Partnerumgebungen installiert sind. Diese Einschätzung werde noch geprüft. Wie die Angreifer zuerst eingedrungen sind und wie groß der Vorfall insgesamt ist, werde weiter untersucht. Der Hersteller hat rund 400 Partnerumgebungen ermittelt, in denen mindestens eine der Erweiterungen installiert ist. Er betont aber, dass ihre bloße Installation noch keine Kompromittierung belegt. Die Erweiterungen bieten eine API, über die sich Befehle aus der Ferne ausführen lassen. Der Zugang zu dieser API ist mit einer Passphrase geschützt, die der Partner bei der Einrichtung festlegt. Vorsorglich deaktiviert wurden diese Erweiterungen:

  • Labtech Plus
  • RMM Plus
  • RMM+
  • RMM Plus Password Link
  • RMM+ Password Link

Partner mit lokal betriebenen Installationen hat ConnectWise aufgefordert, die Erweiterungen selbst abzuschalten. Allen Partnern rät der Hersteller, ihre Sicherheitskontrollen aktiv zu halten und Protokolle verdächtiger Aktivitäten aufzubewahren. Außerdem sollen sie auf folgende Anzeichen achten:

  • ungewöhnliche Anmeldungen, unbekannte Standorte, wiederholt fehlgeschlagene Logins und unerwartete Abfragen zur Multi-Faktor-Authentifizierung
  • neue Administratorkonten oder geänderte Benutzerrechte
  • unerwartet installierte Erweiterungen, Fernbefehle und Toolbox-Aktivitäten
  • nicht genehmigte Fernzugriffssoftware auf Kundengeräten und Techniker-Arbeitsplätzen
  • unerwartete Supportanfragen, Nachrichten zum Zurücksetzen von Passwörtern und Software-Downloads über einen vertrauenswürdigen Kanal

ConnectWise hat folgende Kompromittierungsindikatoren veröffentlicht:

  • IP-Adressen: 185.99.255[.]28, 155.94.150[.]39
  • Domains und URLs: 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

Huntress hat die Aktivität erstmals am 11. November 2026 gegen 17:47 Uhr UTC festgestellt. Die Angreifer nutzten den Zugang zu den Panels, um per Run-Befehl die bösartigen Clients zu installieren. Auch Huntress hat nach eigenen Angaben keine Hinweise auf eine neue Schwachstelle gefunden. Wie die Angreifer an den Panel-Zugang gelangten, sei aber noch unklar. Die vorliegenden Telemetriedaten sprechen für kompromittierte Zugangsdaten oder übernommene Sitzungen von Bedienern.

Der Angriff breitet sich wie ein Wurm aus und läuft in zwei Schritten ab. Im ersten Schritt verteilen die Angreifer über die Run-Command-Funktion eines kompromittierten Panels einen bösartigen Client auf die Endpunkte. Damit entsteht eine dauerhafte Hintertür, die das ursprüngliche Panel nicht mehr braucht. Im zweiten Schritt geht es um die seitliche Ausbreitung: Verbindet sich ein Techniker über ScreenConnect mit einem infizierten Endpunkt, kann die Schadsoftware auf seinen Arbeitsplatz überspringen. Dort stiehlt sie gespeicherte Browser-Sitzungen und Authentifizierungstoken und greift auf weitere ScreenConnect-Panels über, auf die der Techniker Zugriff hat.

Die Huntress-Forscher Ben Nahorney und Susannah Matt erklärten, die bösartigen Clients lieferten SCKit aus. Das sei ein eigens entwickeltes Schadwerkzeug, das dauerhaften Fernzugriff einrichte und eine Relay-Falle zum Abfangen von Sitzungscookies aufbaue. Der Infektionsweg verlaufe in zwei Stufen: vom infizierten Endpunkt zum Techniker, der sich damit verbindet, und vom Arbeitsplatz des Technikers zu allen Endpunkten, die sein Panel erreicht. Nicht alle Funktionen seien bei realen Vorfällen beobachtet worden. Einige habe man erst bei der Analyse der Schadcodes entdeckt.

SCKit kommt als verschlüsselte Nutzlast und über einen Base64-kodierten Dropper namens „sckit-run.bat“. Dieser lädt von einem entfernten Server das PowerShell-Skript „sckit-decoder.ps1“, das das Werkzeug startet. Weitere Komponenten tragen Ausnahmen in Microsoft Defender ein und installieren einen zweiten ScreenConnect-Client, den die Angreifer kontrollieren. Sie legen außerdem eine geplante Aufgabe namens „TrapWatch“ an und ersetzen die legitime ScreenConnect-Installation durch eine manipulierte Kopie. Mindestens eines der Skripte wurde offenbar von einem großen Sprachmodell erzeugt. Darauf deuten detaillierte Verweise auf den Quellcode und erklärende Kommentare hin.

Huntress hat zudem eine Funktion rekonstruiert, die vom Arbeitsplatz eines Technikers auf das ScreenConnect-Panel übergreifen soll. Erkannt wurde sie anhand von Skripten, Konfiguration und Werkzeugen. Einen erfolgreichen Sprung von einem infizierten Endpunkt auf einen Techniker-Arbeitsplatz oder von dort auf weitere Endpunkte hat das Unternehmen bisher nicht beobachtet. Der Ablauf sieht so aus: Über die Verbindung wird der Dropper „Run-Lateral-Full.bat“ geladen. Er kontaktiert den Server ns.mo7sen[.]dev und holt einen Loader, der die eindeutige ID des Arbeitsplatzes an den Angreifer schickt. Zurück kommt ein verschlüsseltes Kit, das auf genau diesen Rechner zugeschnitten ist. Es enthält zwei Teile:

  • „Panel-Lateral.ps1“ stiehlt zusammen mit „LabConfig.ps1“ das .aspxauth-Sitzungscookie vom Arbeitsplatz. Mit dem Cookie versucht es, sich erneut am Panel anzumelden und die Token zu erhalten, mit denen sich alle anderen für den Techniker zugänglichen Sitzungen auflisten lassen.
  • „ToolboxRelayUploader.exe“ nutzt den Zugriff auf diese Sitzungen, um die Nutzlast „WithUninstall.ps1“ in die Shared Toolbox des Panels hochzuladen.

Laut Huntress weist eine Anfrage an das Panel dann alle erreichbaren Sitzungen an, das Toolbox-Element auszuführen. Die Nutzlast läuft auf diesen Endpunkten mit SYSTEM-Rechten, installiert die Falle und setzt den Kreislauf fort. Etwa 60 Sekunden nach dem Rundruf löscht ToolboxRelayUploader.exe das Element wieder aus der Shared Toolbox.

Der Angreifer versieht jeden kompromittierten Managed Service Provider (MSP) mit einer fortlaufenden Nummer. Die von Huntress gesehenen Markierungen setzen mitten in der Zählung ein. Das deutet darauf hin, dass schon früher weitere MSPs kompromittiert wurden. Huntress rät ScreenConnect-Nutzern, ihren Run-Command-Verlauf zu prüfen, auch wenn sie keine Warnungen erhalten haben.

Auch Sophos hat unbefugt installierte ScreenConnect-Clients nach demselben Muster beobachtet. Die Aktivität ging von drei ScreenConnect-Instanz-IDs aus: d905b2b1b165d0a9, 4b8f4089ddaac6a9 und df1f7ef0cfacd0d8. Sophos vermutet, dass diese Instanzen kompromittiert sind und genutzt werden, um Befehle auszuführen und weitere bösartige Instanzen aufzusetzen. Deren IDs lauten 2588ef5c15954b10 und ed630cc2c873b091. Nach Angaben von Sophos lud Curl.exe die Datei ScreenConnect.ClientSetup.msi von 185.99.255[.]28 nach C:\Windows\TEMP\sc.msi herunter. Eine von ScreenConnect erzeugte Befehlsdatei startete anschließend msiexec.exe und installierte den Client ohne sichtbare Rückmeldung. Die Forscher sahen außerdem, wie ScreenConnect-Skripte Batch-Dateien bereitlegten und PowerShell unter Umgehung der Ausführungsrichtlinie ein Skript der zweiten Stufe von ns[.]mo7sen[.]dev/EadF.php?p=4 abrief.

Die Untersuchungen dauern an.