Wurmartiger ScreenConnect-Missbrauch verbreitet VBScript auf neue Hosts

Sicherheitsforscher von Huntress haben Details über wurmartigen Missbrauch von ConnectWise ScreenConnect, einem weit verbreiteten Remote-Zugriffstool, veröffentlicht, bei dem bösartige Clients eine vierteilige VBScript-Kette an neu verbundene Systeme liefern. Das Unternehmen beobachtete im August 2026 drei unabhängige Vorfälle, die mit verschiedenen Ködern begannen: einem Quick-Assist-Techniksupport-Betrug, einem Phishing-zugestellten MSI-Installationsprogramm und einer gefälschten Geek-Squad-Erstattungsformularsuche. Jeder installierte letztendlich einen bösartigen ScreenConnect-Client, der wiederholt wscript.exe startete, um vier Skripte namens 1.vbs, 2.vbs, 3.vbs und 4.vbs auszuführen.

Die vier Skripte bilden eine gestaffelte Infektionssequenz. Zuerst profiliert 1.vbs das Opfergerät: Es prüft, ob das System mehr als 5 GB RAM hat, ob ScreenConnect bereits installiert ist, und listet Sicherheitsprodukte auf, einschließlich Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos und Symantec Endpoint Protection. Die Ergebnisse werden als dreistelliger Zustandswert in %TEMP%\value.txt geschrieben. Huntress erklärt, dass ein Zustand von 000 beispielsweise bedeutet, dass keine bestehende ScreenConnect-Installation vorhanden ist, Prozesse von Drittanbieter-Sicherheitssoftware vorhanden sind und keine ScreenConnect-Clients unter Program Files installiert sind. Als Nächstes wartet 2.vbs auf value.txt und sucht nach dem Wort abort. Wenn das Wort nicht vorhanden ist, lädt es eine Datei von einem Dropbox-Link herunter, dekodiert den Inhalt und schreibt ihn in %TEMP%\map.txt. Der Inhalt dieser Textdatei wird nicht ausgeführt, und die genaue Art der heruntergeladenen Daten ist unklar, da die Dropbox-URL bereits am 2. September 2026 offline war. Skript 3.vbs wartet dann auf map.txt, lädt die in dieser Textdatei genannte Datei basierend auf dem Zustandswert herunter und speichert sie als %TEMP%\out.enc. Schließlich wartet 4.vbs auf out.enc, startet ein PowerShell-Skript unter %TEMP%\runner.ps1, um den Inhalt zu entschlüsseln, schreibt das Ergebnis in %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip und führt dann ein PowerShell-Skript der zweiten Stufe namens PyTorchFix.ps1 aus.

Die drei beobachteten Vorfälle zeigen, wie dieselbe Kette über verschiedene Einstiegspunkte geliefert wurde. Im ersten Fall wurde ein Benutzer während eines Techniksupport-Betrugs dazu überredet, Quick Assist auszuführen, woraufhin ein bösartiger ScreenConnect-Remotezugriffsclient Kontakt mit einem Command-and-Control-Server unter 45.13.237[.]190, auch bekannt als tele-sync.opik[.]net, aufnahm; dieser Server hostete ein RAR-Archiv mit den vier VBS-Dateien. Im zweiten Fall stellte ein MSI-Installationsprogramm namens ScreenConnect.ClientSetup.msi, das wahrscheinlich per Phishing gesendet wurde, einen Client bereit, der so konfiguriert war, dass er 131.123.40[.]98 auf Port 8041 erreicht, und der Client führte fast sofort die vier Skripte aus dem temporären ScreenConnect-Verzeichnis aus. Im dritten Fall führte eine Suche nach einem Geek-Squad-Erstattungsformular zu einer bösartigen ausführbaren Datei namens ScreenConnect.Client.exe, die sich mit borertors92.anondns[.]net verband und dann wscript.exe verwendete, um dieselben Skripte aus dem Temp-Ordner auszuführen.

Abhängig vom dreistelligen Zustandswert wählt die Kette verschiedene Nutzlasten. Die Zustände 000 und 001 führen zu einem ScreenConnect-Backdoor auf Benutzerebene. Zustand 010 führt zu Werkzeugen für die Privilegienausweitung durch einen UAC-Bypass und Persistenzmechanismen. Zustand 011, von dem Huntress sagt, dass er bedeutet, dass die Maschine keine bestehende ScreenConnect-Installation hat, nur Microsoft Defender als Endpunktschutz und keine ScreenConnect-Clients vorhanden sind, führt zu Tunnel-Dienstprogrammen und einem XMRig-Cryptominer. Die Nutzlasten des Zustands 011 deaktivieren auch die Microsoft-Defender-Berichterstattung und schalten die Windows-Speicherintegrität aus. Darüber hinaus beendet das Skript runner.ps1 jeden wscript.exe- oder cscript.exe-Prozess und löscht das Staging-Verzeichnis nach der letzten Stufe. Wenn value.txt auf 010 oder 011 gesetzt ist, kopiert Skript 4.vbs auch die vier VBScript-Dateien nach C:\Users\Public\Libraries\Default\Lib\Lib1, was dazu beiträgt, dass die Infektion überlebt und sich verbreitet.

Huntress beschreibt das Ergebnis als wurmartiges Verhalten. Jedes Mal, wenn ein infizierter ScreenConnect-Client eine neue Host-Verbindung beobachtet, löst es eine weitere Runde von Nutzlastlieferungen aus und verwandelt den kompromittierten Computer in einen Content-Delivery-Mechanismus für die Skripte. Das Verbinden mit einem infizierten Client kann dazu führen, dass das Host-System auf der Serverseite dieselbe vierteilige VBScript-Kette empfängt und ausführt. Der Client zeichnet jede ConnectionID auf, sodass er nicht wiederholt dasselbe aktive Ziel angreift, aber er entfernt diese Kennung nach dem Trennen der Sitzung, sodass eine spätere erneute Verbindung die Infektion erneut auslösen kann. Huntress fand auch einen gemeinsamen Run-Key namens WindowsServiceHost im Benutzerprofil, der auf WindowsServiceHost.vbs im AppData-Verzeichnis verweist, und auf einigen betroffenen Maschinen beobachtete es andere Remote-Überwachungs- und Verwaltungstools wie UltraViewer. Aufgrund der Komplexität dieser Ketten empfiehlt das Huntress SOC dringend, betroffene Hosts von bekannten guten Medien neu abzubilden oder eine saubere Betriebssysteminstallation durchzuführen.

ConnectWise hat als Reaktion auf die Ergebnisse ein Advisory herausgegeben. Das Unternehmen sagt, es habe ein Problem identifiziert, das das Dateiübertragungsverhalten in ScreenConnect Remote Access Support- und Access-Sitzungen betrifft, und das Problem betrifft sowohl Cloud- als auch On-Premise-Bereitstellungen. Bis ein Fix verfügbar ist, empfiehlt ConnectWise Administratoren, die Möglichkeit für Techniker zu deaktivieren, Dateien zu übertragen. Dazu gehört, sich in die ScreenConnect-Administrationsseite einzuloggen, zu Administration > Sicherheit > Rollen zu gehen, jede zugewiesene Rolle zu bearbeiten, die Bereichsberechtigungen für jede Sitzungsgruppe zu überprüfen und die Berechtigung TransferFiles (oder TransferFIlesInSession in älteren Versionen) abzuwählen, wo sie ausgewählt ist, und dann die Änderungen für jede Rolle zu speichern.

Für Teams, die Remote-Zugriffs- und Support-Tools verwalten, bietet AEU-I sicherheitsorientierte IT- und Infrastrukturberatung, die helfen kann, Zugriffsrollen, Berechtigungen und Remote-Support-Konfigurationen zu überprüfen, bevor sie Teil eines solchen Angriffs werden.