Een groep cybersecurity-onderzoekers beschrijft worm-achtige activiteiten waarbij ConnectWise ScreenConnect misbruikt wordt om via een vierstaps VBScript keten systemen te besmetten die net nieuw verbinding maken. Het gaat niet om één standaard “attack load” die overal hetzelfde werkt: de initiële toegang verschilt per incident, maar de uiteindelijke automatisering en verspreiding volgen hetzelfde patroon.
In de gevallen die in augustus 2026 werden waargenomen, ontstond de besmetting zodra een geïnfecteerde ScreenConnect-client op een host werd geïnstalleerd. Daarna startte die client telkens opnieuw scriptstappen met wscript.exe, waarbij meerdere VBS-bestanden na elkaar werden uitgevoerd.
Wat maakt dit een ScreenConnect worm?
De kern van het verhaal is dat een gecompromitteerde ScreenConnect-installatie zichzelf inzet bij nieuwe verbindingen. Onderzoekers beschrijven dat de client verbindingen met nieuwe hosts “waarnam” en daarop opnieuw dezelfde scriptketen activeerde. Huntress verwoordt het als worm-achtig gedrag: door verbindingen te misbruiken verspreidt de infectie zich over systemen die later aan dezelfde remote access omgeving hangen.
Daarbij gebruikte de aanval een mechanisme om herhaald targeten te beperken: de client noteert een ConnectionID om niet steeds dezelfde sessie te infecteren, maar dat identificatiepad wordt verwijderd zodra de sessie weer uitgaat. Daardoor kan een latere reconnection opnieuw tot uitvoering leiden.
Drie verschillende “ingangen”, één uitvoeringsketen
De onderzoekers zagen drie incidenten met elk een andere manier om de initial access te triggeren:
- Tech-support scam met Quick Assist: een slachtoffer werd overtuigd Quick Assist te gebruiken, waarna een rogue ScreenConnect remote access client werd ingezet om naar een command-and-control (C2) server te verbinden. Op het IP-adres stond een RAR-archief met de vier VBS-bestanden.
- Phishing met MSI-installer: een phishingcampagne leverde naar verwachting een ScreenConnect.ClientSetup.msi af. Die installer configureerde de client om met een specifieke host op poort 8041 te communiceren. Al vrijwel direct werden de vier VBScript-bestanden vanuit een ScreenConnect tijdelijke map gestart.
- Misleidende “Geek Squad” refund lure: via zoeken naar een “refund form” werd een rogue ScreenConnect client (ScreenConnect.Client.exe) ingezet. Deze verbond met een domein, waarna opnieuw wscript.exe de vier VBS-scripts uit de Temp-map uitvoerde.
Hoewel de lokazen uiteenlopen, is de rode draad de daaropvolgende vierstaps logica die payloads binnenhaalt, decodet en decryptie in gang zet.
De vier stappen van de VBScript keten
De aanval bestond uit VBS-scripts die elkaar voortzetten: 1.vbs → 2.vbs → 3.vbs → 4.vbs. Elke stap heeft een specifieke rol in profiling, het ophalen van data en het uiteindelijk uitvoeren van een latere payload.
1.vbs: profileren en toestandsvariabele wegschrijven
De eerste stap brengt de host in kaart. Het script maakt onder meer een check van beschikbare systeembronnen (zoals RAM boven een drempel), controleert of ScreenConnect al geïnstalleerd is en somt beveiligingsproducten op. Denk aan onder andere Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos en Symantec Endpoint Protection.
Vervolgens schrijft het een drie-bits state variable weg naar %TEMP%\value.txt. Een voorbeeld dat onderzoekers noemen is “000”: geen bestaande ScreenConnect-installatie, aanwezigheid van derde-partij beveiligingsprocessen en geen ScreenConnect-clients in de Program Files-map.
2.vbs en 3.vbs: wachten op state en payloads ophalen
Het tweede script wacht op het bestaan van %TEMP%\value.txt en controleert vervolgens of het woord “abort” aanwezig is. Als die afbreekvoorwaarde ontbreekt, downloadt het een bestand vanuit een Dropbox-link, decodeert het en schrijft het resultaat weg naar %TEMP%\map.txt.
Ook 3.vbs werkt conceptueel vergelijkbaar: het wacht totdat %TEMP%\map.txt er is, en downloadt daarna een bestand dat afhankelijk is van de state-waarde uit %TEMP%\value.txt. Dat uiteindelijke resultaat wordt opgeslagen als %TEMP%\out.enc.
De precieze aard van de gedownloade content is niet volledig helder uit de openbare beschrijving, mede omdat de Dropbox-url in de onderzoeksperiode niet meer online was (op 2 september 2026).
4.vbs: decryptie, uitvoering en opruimen
De vierde stap wacht op %TEMP%\out.enc en start een PowerShell-script: %TEMP%\runner.ps1. Dit script decryptet de inhoud van %TEMP%\out.enc, schrijft de gedecryptde data naar %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip en start daarna een volgende PowerShell-script: PyTorchFix.ps1.
Opvallend is dat 4.vbs tevens probeert elk wscript.exe of cscript.exe-proces te beëindigen zodra de laatste stap draait, en vervolgens de staging directory verwijdert. Daarnaast worden de vier VBS-bestanden ook naar een publiek toegankelijke locatie geschreven wanneer de state in bepaalde branches valt: C:\Users\Public\Libraries\Default\Lib\Lib1.
Payload-varianten per state-waarde
Niet elk pad levert dezelfde impact op. Onderzoekers melden ten minste drie detecteerbare richtingen op basis van de state-waarde:
- 000 en 001: user-level ScreenConnect backdoor.
- 010: tooling voor privilege-escalatie via een UAC-bypass en persisterende componenten.
- 011: tunnelhulpmiddelen en een cryptocurrency miner.
In branch 011 beschrijft Huntress ook expliciete sabotage op verdediging: het pad zou Microsoft Defender-rappo rting proberen te onderdrukken, Windows memory integrity uitzetten en de miner uitvoeren.
Extra aanwijzingen: waar u op kunt letten
Naast de scriptketen noemen onderzoekers nog bredere indicatoren. Zo wordt een Windows-servicehost user run key genoemd die verwijst naar WindowsServiceHost.vbs in de gebruikers-AppData-directory.
Verder zagen ze op sommige hosts ook andere remote monitoring en management (RMM)-tools terug, waaronder UltraViewer. Dat betekent niet automatisch dat die tool de aanvallag vormde; het kan ook gaan om “meegesleept” gedrag binnen de gecompromitteerde omgeving.
Wat ConnectWise adviseert: file transfer beperken
ConnectWise heeft naar aanleiding van de bevindingen een advisory uitgebracht. De leverancier meldt dat er een issue speelt die betrekking heeft op file transfer gedrag in ScreenConnect Remote Access Support en Access sessions, en dat dit zowel van toepassing kan zijn op Cloud– als On-Premise-omgevingen.
Tot er een fix beschikbaar is, adviseert ConnectWise om het risico te beperken door de mogelijkheid voor technici om bestanden over te dragen uit te schakelen.
Mitigatie: TransferFiles toestemming uit
Concreet komt het neer op het volgende proces:
- Log in op de Administration-pagina van uw ScreenConnect instance of installatie.
- Ga naar Administration > Security > Roles.
- Open een rol die aan gebruikers is toegewezen.
- Bekijk per session group welke scoped permissions zijn toegekend.
- Schakel voor elke sessiegroep de optie TransferFiles uit (of TransferFIlesInSession in oudere versies).
- Sla de wijzigingen op en herhaal dit voor alle gedefinieerde rollen.
Actieplan voor beheerders
Als u vermoedt dat ScreenConnect door deze keten is misbruikt, is “afwachten” meestal geen goede optie. Huntress geeft als sterke aanbeveling: herinstallatie of herimaging vanaf een bekend schone bron (known-good media), of een clean operating system install.
Daarnaast is het verstandig om te controleren of er aanwijzingen zijn voor een geautomatiseerde scriptuitvoering rond de vier VBS-bestanden en PowerShell-decryptie. Denk aan sporen rond wscript.exe-aanroepen, tijdelijke bestanden in Temp, en wijzigingen in run keys of openbare bibliotheekpaden.
Voor organisaties die remote access gebruiken als “brug” naar systemen is dit ook een reden om bredere control checks opnieuw te bekijken. Heeft u daarnaast een aanpak voor cloud- en supply-chain risico’s, dan passen de lessen van dit incident in dezelfde lijn: verklein de mogelijkheden die helpen bij latere payloaddistributie.
Een relevante aanvulling op het algemeen gedachtengoed rondom beveiligingscontroles vindt u in de cloud security checklist die niet werkt als u denkt.
Waarom dit belangrijk is voor uw security strategie
Dit incident laat zien dat remote access software een aantrekkelijk doelwit is: zodra de aanvaller een werkende foothold heeft, kan hij via geautomatiseerde ketens payloads samenstellen op basis van detectie van de omgeving. De state-waarde (zoals 000/001 versus 010 versus 011) stuurt vervolgens waar de keten naartoe “doorloopt”.
Het worm-achtige karakter versterkt het risico: een besmette host kan later weer andere hosts besmetten bij nieuwe verbindingen. Dat maakt “eenmalig uitzetten” niet altijd genoeg; u moet ook kijken naar hoe sessies, permissies en file transfer in uw remote access tooling zijn ingericht.
Conclusie
De ontdekte ScreenConnect worm combineert misleiding (verschillende initial access routes) met een consistente vierstaps VBScript keten die via wscript.exe nieuwe hosts activeert zodra ze verbinding maken. De keten profileert de machine, downloadt gecodeerde content, decodeert en decryptet die en voert daarna afhankelijk van de state verschillende payloads uit, waaronder backdoor-functionaliteit, privilege-escalatie, tunnelhulpmiddelen of een cryptocurrency miner.
Tijdelijke mitigatie draait volgens ConnectWise om het beperken van file transfer in rollen en session groups. Op langere termijn is herinstallatie vanaf een schone basis het veiligste pad als er besmetting is vastgesteld. Wilt u dit soort risico’s structureel terugdringen, dan helpt een herijking van rechten, sessiebeperkingen en veiligheidschecks—niet alleen “technisch”, maar ook organisatorisch.
Bron: https://thehackernews.com/2026/09/rogue-screenconnect-clients-spread-four.html
