Huntress waarschuwt voor een wormachtige ScreenConnect-aanval waarin aangepaste of “rogue” ScreenConnect-clients worden ingezet om malware te verspreiden naar andere endpoints. De campagne startte volgens de melding in laat augustus en combineert social engineering met een keten aan scripts, persistence en remote-to-remote voortplanting.
In dit artikel leggen we de belangrijkste onderdelen van de aanval uit, waar beheerders op kunnen letten en welke maatregelen je vandaag nog kunt nemen om de kans op besmetting en verdere verspreiding te verkleinen.
Hoe de wormachtige ScreenConnect-aanval begint
De aanval begint niet met een klassieke exploit op afstand, maar met het installeren van een onbetrouwbare ScreenConnect-client op het doelapparaat. Dat gebeurt via social engineering: slachtoffers worden verleid om de kwaadaardige component zelf toe te staan of uit te voeren.
In een waargenomen incident op 20 augustus voerde een aanvaller zich uit als “tech support”. Het slachtoffer kreeg instructies om de ingebouwde Microsoft remote support tool Quick Assist te gebruiken. Daarmee kreeg de aanvaller controle over het systeem.
Van rogue client naar VBScript-ketens
Na installatie zagen onderzoekers dat de kwaadaardige ScreenConnect-instantie zeer snel vervolgacties uitvoert. Concreet werd waargenomen dat de rogue client direct vier VBScript-bestanden start vanuit een tijdelijke ScreenConnect-map.
Die VBScript’s vormen samen een georkestreerde keten. Huntress beschrijft dat deze scripts zijn gebruikt voor:
- systeemverkenning (reconnaissance),
- het voorbereiden en aansturen van payload-stappen,
- het uitvoeren van een PowerShell-script als vervolg.
PowerShell: bewijs wissen, UAC-pogingen en een nieuwe remote laag
Het eerste PowerShell-stadium leidt volgens de observaties naar een tweede PowerShell-script dat meerdere doelen dient. Daarbij gaat het om het wissen van staging evidence (sporen die in de voorbereidingsfase zijn achtergelaten), maar ook om pogingen rondom UAC bypass.
Vervolgens installeert de aanval UltraViewer remote desktop software. De combinatie van remote desktop tooling en persistence maakt het voor een aanvaller makkelijker om herhaald toegang te behouden en het traject opnieuw te starten.
Persistence via User Run Key
Naast het uitvoeren van scripts werd persistence vastgesteld met een User Run Key die verwijst naar een ander VBScript-bestand. Met andere woorden: zelfs nadat de initiële sessie voorbij is, kan de aanval zichzelf opnieuw opstarten.
Het valt op dat dezelfde patronen bij meerdere organisaties zijn teruggezien. Dat wijst erop dat de campagne niet “op één slachtoffer” is blijven steken, maar is opgezet als herhaalbare aanvalstechniek.
Voortplanting naar andere endpoints via ScreenConnect
Het meest “wormachtige” deel zit in de manier waarop de rogue client verder verspreidt. Huntress geeft aan dat de aanvallers de kwaadaardige ScreenConnect-instanties inzetten om de payload door te zetten naar andere, verbonden sessies of systemen.
Onderzoeksdata toonden ook actieve netwerkverbindingen vanuit ScreenConnect naar meerdere externe IP-adressen. Daarbij wordt de aanname ondersteund dat de aanvaller remote verbindingen onderhoudt en nieuwe hosts kan toevoegen aan hetzelfde ketenmechanisme.
Vier-stappen keten: van recon naar verdere verspreiding
De vier VBScript’s werken volgens Huntress niet alleen als “eenmalige payload”, maar als een vierfase-aanvalsproces. Het einddoel is om een nieuwe ScreenConnect-client in te zetten die vervolgens blijft controleren op nieuwe hostverbindingen en daarop opnieuw de VBScript-keten start.
Daarmee ontstaat een cyclus: nieuwe slachtoffers worden via een vergelijkbaar instapmoment (social engineering) gekoppeld, waarna de keten automatisch verder gaat.
Voorbeelden uit de campagne: 20 en 24 augustus
Naast het incident van 20 augustus werd op 24 augustus opnieuw een aanval met hetzelfde patroon waargenomen. Ook daar startte het traject met social engineering.
Het aantal herhaalmomenten en de consistentie van de acties (VBScript’s vanuit de ScreenConnect-temp directory, daarna PowerShell en persistence) ondersteunen het beeld van een gestandaardiseerde campagne.
Wat beheerders kunnen doen: extra controle op on-premises ScreenConnect
Huntress adviseert administrateurs om extra kritisch te kijken naar on-premises ScreenConnect-installaties binnen hun omgeving. De reden is dat de aanval zich lijkt te richten op situaties waarin ScreenConnect actief is en bereikbaar blijft voor (malafide) sessies.
Een praktische insteek is om te letten op:
- plotselinge ScreenConnect-activiteit vanuit tijdelijke mappen,
- processen waarbij wscript.exe herhaaldelijk child-processen start,
- PowerShell-uitvoering die aansluit op script-ketens,
- wijzigingen die passen bij persistence via Run Keys,
- remote desktop installaties of ongebruikelijke remote tooling.
Combineer dat vervolgens met netwerkobservaties: Huntress vermeldt expliciet dat telemetry actief verkeer zag richting meerdere remote IP’s.
ConnectWise advisory: file transfer uitschakelen
ConnectWise publiceerde een waarschuwing voor een issue in file transfer gedrag in ScreenConnect Remote Access Support en Access sessions. Dit zou zowel gelden voor cloud als on-premises deployments.
ConnectWise geeft aan dat er een CVE-identifier en een officiële fix wordt verwacht binnen de week. Tot dat moment adviseert de leverancier beheerders om de file transfer functionaliteit in ScreenConnect uit te schakelen om het risico te verlagen.
Waarom dit soort campagnes ook buiten “de software” impact heeft
Deze casus laat zien dat een wormachtige verspreiding vaak niet draait om één technische kwetsbaarheid alleen, maar om een keten waarin meerdere componenten samenkomen. Denk aan remote access tooling, social engineering bij de instap, scriptketens en vervolgens persistence.
Als jouw organisatie ScreenConnect gebruikt, is het daarom verstandig om niet alleen naar patch- of CVE-nieuws te kijken, maar ook naar bruikbaarheid en misbruikscenario’s: wie kan remote tools inzetten, welke taken worden er uitgevoerd tijdens ondersteuning, en welke proces- en netwerkpatronen zijn afwijkend?
Wil je meer achtergrond over hoe remote-to-remote of chain-achtige aanvallen zich kunnen gedragen? Lees dan ook ScreenConnect-worm via VBScript keten: zo herkent u het.
Checklist om de impact nu te beperken
Hoewel je altijd eerst de officiële advisory en updates moet opvolgen, kun je ondertussen gericht stappen zetten. Hieronder een korte aanpak die past bij de observaties van Huntress.
- Beperk file transfer in ScreenConnect volgens het advies van ConnectWise totdat er een fix is.
- Controleer procesgedrag: let op wscript.exe die direct scriptketens opstart vanuit ScreenConnect-temp of vergelijkbare locaties.
- Monitor scriptuitvoering: zoek naar PowerShell-stappen die passen bij staging, opschonen en vervolginstallaties.
- Check persistence: controleer Run Keys en gerelateerde autoruns op onverwachte verwijzingen naar VBScript’s.
- Analyseer remote verbindingen: bijzondere uitgaande verbindingen vanuit ScreenConnect naar meerdere IP’s verdienen extra onderzoek.
Conclusie
De wormachtige ScreenConnect-aanval die Huntress beschrijft, draait om het misbruiken van remote access tooling via rogue clients. Na social engineering volgen VBScript-ketens, PowerShell-stappen met opschonen en UAC-pogingen, persistence via Run Keys en uiteindelijk een mechanisme dat nieuwe hostverbindingen afhandelt om de keten door te zetten naar andere endpoints.
Door de ConnectWise-aanbeveling (zoals het uitschakelen van file transfer) direct toe te passen waar dat kan, en door alert te zijn op de specifieke proces- en netwerkpatronen die Huntress noemt, kun je de kans op verspreiding aanzienlijk verkleinen.
Bron: https://www.securityweek.com/modified-screenconnect-clients-used-in-worm-like-campaign/
