Rogue ScreenConnect-clients verspreiden een vierfasige VBScript-keten naar nieuw aangesloten hosts

Cybersecurity-onderzoekers hebben details onthuld van wormachtige activiteiten die ConnectWise ScreenConnect misbruiken om een ​​kwaadaardige Visual Basic Script (VBScript)-payload naar nieuw verbonden systemen te verspreiden.

Volgens Huntress zijn er bij drie niet-gerelateerde incidenten verschillende initiële toegangsmethoden gebleken, namelijk een Quick Assist-oplichting met technische ondersteuning, een door phishing geleverd MSI-installatieprogramma en een nep-terugbetalingsformulier van Geek Squad, om een ​​VBScript-keten in vier fasen te activeren die leidt tot frauduleuze ScreenConnect-installaties.

Toen de ScreenConnect-instanties echter eenmaal waren geïnstalleerd, zei het cyberbeveiligingsbedrijf dat het zag dat de clients herhaaldelijk “wscript.exe” voortbrachten om VBScripts met de namen 1.vbs, 2.vbs, 3.vbs en 4.vbs uit te voeren. De incidenten werden waargenomen in augustus 2026.

De details van de drie aanvallen staan ​​hieronder:

• Een social engineering-aanval die een gebruiker overhaalde om Quick Assist uit te voeren als onderdeel van een oplichting met technische ondersteuning, waarna een frauduleuze ScreenConnect-client voor externe toegang werd ingezet om contact te maken met een command-and-control (C2)-server op “45.13.237(.)190” (“tele-sync.opik(.)net”). Op het IP-adres wordt een RAR-archief gehost dat de vier VBS-bestanden bevat.
• Een MSI-installatieprogramma (“ScreenConnect.ClientSetup.msi”) werd waarschijnlijk geleverd via een phishing-aanval waarbij een ScreenConnect-client werd ingezet die was geconfigureerd om te communiceren met “131.123.40(.)98” op poort 8041. De frauduleuze ScreenConnect lanceerde vrijwel onmiddellijk de vier VBScript-bestanden vanuit de tijdelijke map ScreenConnect.
• Een zoektocht naar een teruggaveformulier van Geek Squad leidde tot de inzet van een frauduleuze ScreenConnect-client (“ScreenConnect.Client.exe”), die vervolgens verbinding maakte met “borertors92.anondns(.)net.” De sessie gebruikt vervolgens “wscript.exe” om de vier VBS-scripts uit de map Temp uit te voeren.

Bij deze incidenten zou de aanvalsvolgorde een proces van vier stappen hebben gevolgd, waarbij elke VBScript de volgende lanceerde en deze verder liet gaan –

• 1.vbsdat de host profileert, de systeembronnen controleert (bijvoorbeeld of het RAM-geheugen groter is dan 5 GB), verifieert of ScreenConnect is geïnstalleerd, beveiligingsproducten opsomt, waaronder Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos en Symantec Endpoint Protection, en de resultaten van deze controles schrijft naar “%TEMP%value.txt” in de vorm van een drie-bits statusvariabele. De statuswaarde “000” geeft bijvoorbeeld aan dat er geen bestaande ScreenConnect-installatie is, dat er beveiligingsprocessen van derden aanwezig zijn en dat er geen ScreenConnect-clients zijn geïnstalleerd in de map Program Files.
• 2.vbsdat wacht op het bestand “%TEMP%value.txt” en controleert op de aanwezigheid van het woord “abort.” Als het woord niet bestaat, downloadt het een bestand van Dropbox, decodeert de inhoud ervan en schrijft het naar “%TEMP%map.txt.” Hoewel de inhoud van het tekstbestand niet wordt uitgevoerd, is de exacte aard van de opgehaalde payload onduidelijk, aangezien de Dropbox-URL sinds 2 september 2026 niet langer online is.
• 3.vbsdat op dezelfde manier werkt als 2.vbs door te wachten op “%TEMP%map.txt” en vervolgens doorgaat met het downloaden van het relevante bestand via de Dropbox-link die is opgegeven in het tekstbestand op basis van de statuswaarden die zijn ingesteld door 1.vbs in “%TEMP%value.txt” en schrijft het naar “%TEMP%out.enc.”
• 4.vbsdat wacht op de aanwezigheid van de gedownloade payload “%TEMP%out.enc” en een PowerShell-script (“%TEMP%runner.ps1”) lanceert om de inhoud van “%TEMP%out.enc” te decoderen, deze naar “%APPDATA%MicrosoftWindowsTemplatesClassicsys_cache.zip” te schrijven en een PowerShell-script van de tweede fase uit te voeren (“PyTorchFix.ps1”).

Er zijn ten minste drie verschillende payloads gedetecteerd op basis van de statuswaarde:

• 000 En 001 leiden tot een ScreenConnect-achterdeur op gebruikersniveau
• 010 leidt tot tools voor escalatie van bevoegdheden via een omzeiling en persistentie van gebruikersaccountbeheer (UAC).
• 011 leidt tot het tunnelen van nutsvoorzieningen en een cryptocurrency-mijnwerker

Bovendien onderneemt “%TEMP%runner.ps1” stappen om elk “wscript.exe”- of “cscript.exe”-proces te beëindigen, en verwijdert het de staging-map nadat de laatste fase is uitgevoerd. Het 4.vbs-script schrijft de vier VBScript-bestanden ook naar “C:UsersPublicLibrariesDefaultLibLib1” als de waarde in “%TEMP%value.txt” is ingesteld op 010 of 011.

Dit veroorzaakt op zijn beurt een reeks payload-leveringen, waardoor de gecompromitteerde host effectief wordt omgezet in een mechanisme voor het leveren van inhoud voor de kwaadaardige scripts, elke keer dat de backdoor-client een nieuwe hostverbinding waarneemt.

“Dit creëert een wormachtig gedrag: het verspreiden van infecties via nieuwe ScreenConnect-verbindingen. Verbinding maken met een geïnfecteerde ScreenConnect-client kan ervoor zorgen dat het hostsysteem aan de serverzijde dezelfde vierfasige VBScript-keten ontvangt en uitvoert”, aldus Huntress. “Later registreert de client elke ConnectionID om te voorkomen dat hij zich herhaaldelijk op dezelfde actieve sessie richt, maar verwijdert vervolgens die identificatie nadat de verbinding is verbroken, waardoor een latere herverbinding de infectie opnieuw kan activeren.”

“De incidenten delen aanvullende indicatoren, waaronder een WindowsServiceHost User Run Key die verwijst naar WindowsServiceHost.vbs in de AppData-directory van de gebruiker”, zei Huntress, eraan toevoegend dat andere tools voor monitoring en beheer op afstand (RMM), waaronder UltraViewer, op sommige getroffen hosts werden waargenomen.

Aan de andere kant, de statuswaardetak “011”, wat zich vertaalt naar: (1) geen bestaande installatie van ScreenConnect op het systeem, (2) Microsoft Defender is het enige eindpuntbeveiligingsprogramma dat op de machine is geïnstalleerd, en (3) er zijn geen ScreenConnect-clients aanwezig, inclusief payloads om Microsoft Defender-rapportage uit te schakelen, Windows-geheugenintegriteit uit te schakelen en een XMRig-cryptocurrency-miner uit te voeren.

“Gezien de omvang en complexiteit van deze aanvalsketens heeft het Huntress SOC krachtige aanbevelingen gedaan om deze getroffen hosts opnieuw te imagen vanaf bekende goede media, of een schoon besturingssysteem te installeren”, aldus Huntress.

Als reactie op de bevindingen heeft ConnectWise een advies uitgebracht waarin staat dat het een probleem heeft vastgesteld dat van invloed is op het gedrag van bestandsoverdracht in ScreenConnect Remote Access Support en Access-sessies. Het probleem, zo voegde het bedrijf toe, heeft gevolgen voor zowel cloud- als on-premise-implementaties.

Totdat er een oplossing is, wordt klanten aangeraden het risico te beperken door de mogelijkheid voor technici om bestanden over te dragen uit te schakelen –

• Log in op de beheerpagina van de ScreenConnect-instantie of -installatie.
• Navigeer naar de sectie Beheer > Beveiliging > Rollen.
• Bewerk een rol die aan gebruikers is toegewezen.
• Bekijk elke sessiegroep waaraan machtigingen zijn toegewezen.
• Controleer voor elke sessiegroep in het venster Scoped Permissions of de TransferFiles-machtiging (of TransferFIlesInSession voor oudere versies) is geselecteerd. Als dit het geval is, deselecteert u deze.
• Sla wijzigingen in de rol op.
• Herhaal dit voor elke rol die is gedefinieerd in het exemplaar of de installatie.