Hunt the ScreenConnect Guest that runs your scripts: 1.vbs through 4.vbs

The alert is wscript.exe, four short script names, and a Run key that looks like a Windows service helper. ScreenConnect is already on the box. Someone says helpdesk has a session. There is no ransomware family on the page, and the brand name on the client is the same one your techs use every day. That is when this chain wants you to call it a rogue RMM install and move on.

Here is the plain version before the product jargon. A modified ScreenConnect client on one host watches for a new Host session, packages 1.vbs through 4.vbs, and pushes them across Guest file transfer with a Run action. The connected box executes them. That is not "another ScreenConnect got installed." That is worm-like spread across sessions, using the product's own transfer path.

Huntress saw this in late August 2026 across unrelated organizations. ConnectWise published a Guest File Transfer advisory on 3 September 2026 for Support and Access sessions, cloud and on-prem. A CVE and a fix are promised within the week. Until then the interim mitigation is to disable TransferFiles, or TransferFilesInSession on legacy builds. Outside Huntress and that ConnectWise note, observation is still thin. If you came in hunting the RMM brand name, you are hunting the wrong leftover. The case is Guest-run scripts in the audit log, wscript.exe on 1.vbs–4.vbs, and a WindowsServiceHost Run value pointing at AppData.

How Guest file transfer turns into the delivery rail

The story Huntress caught does not open on a CVE string. It opens on social engineering that lands a rogue ScreenConnect client. Quick Assist shows up as a lead-in on one August 20 case. On another, a phishing path drops ScreenConnect.ClientSetup.msi from an Edge download folder. On a third, a Geek Squad refund lure gets the victim to run ScreenConnect.Client.exe. Those are familiar doors. What comes next is not.

After the client is up, Huntress watches ScreenConnect.WindowsClient.exe spawn wscript.exe again and again. The children run four staging scripts: 1.vbs, 2.vbs, 3.vbs, and 4.vbs, often from a ScreenConnect temp path or later from under Public Libraries. The chain profiles the host, pulls staged content, and builds persistence. Across the incidents, attackers also create a User Run key named WindowsServiceHost that points at WindowsServiceHost.vbs in the user's AppData. Some hosts also pick up UltraViewer. That secondary RMM is noise you should not ignore, but it is not the leftover that makes this case different.

The part that changes the case is the modified client itself. Huntress recovered clients that watch ScreenConnect's connection list for newly observed Host sessions. When a new Host shows up, the client reads those four VBS files, registers them with ScreenConnect's virtual file-transfer system, sets the action to Run, and queues the transfer. Connecting to an infected client can land the same four-stage chain on the Host. Connection IDs get recorded so the same live session is not hit over and over, then cleared after disconnect so a later reconnect can fire again. That is why this is not a one-host rogue-install recap. Guest file transfer becomes the delivery rail.

I am not going to reconstruct every stage of 1.vbs through 4.vbs, the AES unwrap, or the UAC tricks in the access package. You do not need the recipe. You need the leftovers that survive when the write-up names change.

Leftovers that stick after the brand name fades

Start in ScreenConnect's own audit trail, not in another "block ScreenConnect" rule. Huntress is blunt about this: RunFiles or RanFiles entries for those suspect scripts, executed from Process: Guest, should raise immediate suspicion. By the time you read this the filenames may rotate, so Guest-run Windows Script Host or PowerShell is the broader signal. That audit line is the difference between "we have ScreenConnect" and "Guest just ran code on a Host."

On the endpoint, ScreenConnect spawning wscript.exe against 1.vbs–4.vbs is the process shape that woke Huntress. Watch temp paths tied to ScreenConnect and the Public Libraries tree Huntress called out for later staging. Persistence that sticks is the WindowsServiceHost Run value under the current user, pointing at WindowsServiceHost.vbs in AppData. That name is meant to skim past a tired registry glance. It is not a Windows service host. It is the decoy Huntress documented.

If you are inventorying clients, Huntress also published a malicious ScreenConnect ID: 7a4d7d66502d4260. Pair that with secondary tooling when it shows, UltraViewer and Quick Assist lead-ins, and the infrastructure Huntress listed, including tele-sync.opik.net, 45.13.237.190, 131.123.40.98 on port 8041, and homehub.opik.net. Those are supporting leads. The hunt that still works when the C2 names rotate is Guest-run scripts plus the Run key.

ConnectWise's 3 September advisory is the operational brake. They identified an issue in file transfer behavior for ScreenConnect Remote Access Support and Access sessions. Partners can cut risk now by clearing TransferFiles on roles, or TransferFilesInSession on legacy versions, without waiting for a version bump. Apply that where you can, then keep hunting. A disabled permission does not rewrite last month's audit log.

Do not wait for a weekend outbreak. Huntress incidents land in late August. The ConnectWise advisory lands 3 September. Coverage outside those two sources is still thin. A clean bill is not "we allowlist ScreenConnect." A clean bill is quieter: Guest file-run noise is visible, wscript on numbered VBS from ScreenConnect paths is quiet, WindowsServiceHost is not pointing at AppData, and the named ID and infra are quiet. Anything short of that is still the Guest that ran your scripts.

ScreenConnect Guest VBS hunts

Paste these. They are bound to the Huntress artifacts above. The window starts at datetime(2026-08-20), matching the late-August incidents, and stays useful through the 3 September advisory. They do not reconstruct the staging chain.

Hunt ScreenConnect Guest VBS in KQL

DeviceProcessEvents
| where Timestamp >= datetime(2026-08-20)
| where FileName =~ "wscript.exe"
| where InitiatingProcessFileName has "ScreenConnect"
| where ProcessCommandLine has_any ("1.vbs", "2.vbs", "3.vbs", "4.vbs")
   or FolderPath has_any (@"ScreenConnect", @"Users\Public\Libraries")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, FolderPath,
    InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

DeviceRegistryEvents
| where Timestamp >= datetime(2026-08-20)
| where RegistryKey has @"CurrentVersion\Run"
| where RegistryValueName =~ "WindowsServiceHost"
| where RegistryValueData has "WindowsServiceHost.vbs"
   or RegistryValueData has @"AppData"
| project Timestamp, DeviceName, ActionType, RegistryKey, RegistryValueName,
    RegistryValueData, InitiatingProcessFileName, InitiatingProcessCommandLine

DeviceNetworkEvents
| where Timestamp >= datetime(2026-08-20)
| where RemoteIP in ("45.13.237.190", "131.123.40.98")
   or RemoteUrl has_any ("tele-sync.opik.net", "homehub.opik.net")
   or RemotePort == 8041
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
    RemoteIP, RemotePort, RemoteUrl, Protocol

// ScreenConnect audit / custom log ingest: Guest RunFiles / RanFiles
union isfuzzy=true DeviceFileEvents, DeviceProcessEvents, DeviceEvents
| where Timestamp >= datetime(2026-08-20)
| where * has_any ("RunFiles", "RanFiles")
| where * has_any ("1.vbs", "2.vbs", "3.vbs", "4.vbs", "wscript", "Guest")
| project Timestamp, DeviceName, *

Hunt ScreenConnect Guest VBS in Falcon CQL

event_simpleName=ProcessRollup2
| timestamp>=#2026-08-20#
| ImageFileName=*\\wscript.exe*
| ParentBaseFileName=*ScreenConnect*
| (CommandLine=*1.vbs* OR CommandLine=*2.vbs* OR CommandLine=*3.vbs* OR CommandLine=*4.vbs*
   OR CommandLine=*Public\\Libraries* OR CommandLine=*ScreenConnect*)
| table timestamp, ComputerName, UserName, ParentBaseFileName, ImageFileName, CommandLine

event_simpleName=RegistryValueUpdate OR event_simpleName=RegKeyValueSet
| timestamp>=#2026-08-20#
| RegistryValueName=WindowsServiceHost
| (RegistryValueData=*WindowsServiceHost.vbs* OR RegistryValueData=*AppData*)
| table timestamp, ComputerName, UserName, RegistryPath, RegistryValueName, RegistryValueData

event_simpleName=NetworkConnectIP4 OR event_simpleName=DnsRequest
| timestamp>=#2026-08-20#
| (RemoteAddressIP4=45.13.237.190 OR RemoteAddressIP4=131.123.40.98
   OR DomainName=*tele-sync.opik.net* OR DomainName=*homehub.opik.net*
   OR RemotePort=8041)
| table timestamp, ComputerName, ImageFileName, DomainName, RemoteAddressIP4, RemotePort

// ScreenConnect audit / Guest RunFiles|RanFiles if forwarded into Falcon
#event_simpleName=*
| timestamp>=#2026-08-20#
| (RawMessage=*RunFiles* OR RawMessage=*RanFiles* OR Message=*RunFiles* OR Message=*RanFiles*
   OR event_simpleName=*ScreenConnect* OR Facility=*ScreenConnect*)
| (RawMessage=*Guest* OR Message=*Guest* OR RawMessage=*1.vbs* OR Message=*1.vbs*
   OR RawMessage=*2.vbs* OR RawMessage=*3.vbs* OR RawMessage=*4.vbs*
   OR RawMessage=*wscript* OR Message=*wscript*)
| table timestamp, ComputerName, event_simpleName, Facility, RawMessage, Message

Hunt ScreenConnect Guest VBS in Splunk

earliest=08/20/2026:00:00:00
(index=sysmon OR index=windows OR index=crowdstrike OR index=screenconnect OR index=proxy)
(
  (EventCode=1 AND Image="*\\wscript.exe" AND ParentImage="*ScreenConnect*"
   AND (CommandLine="*1.vbs*" OR CommandLine="*2.vbs*" OR CommandLine="*3.vbs*" OR CommandLine="*4.vbs*"
        OR CommandLine="*Public\\Libraries*" OR CommandLine="*ScreenConnect*"))
  OR (EventCode=13 AND registry_value_name="WindowsServiceHost" AND registry_path="*CurrentVersion\\Run*"
      AND (registry_value_data="*WindowsServiceHost.vbs*" OR registry_value_data="*AppData*"))
  OR (query="*tele-sync.opik.net*" OR query="*homehub.opik.net*" OR dest="tele-sync.opik.net" OR dest="homehub.opik.net"
      OR dest_ip IN ("45.13.237.190","131.123.40.98") OR dest_port=8041)
  OR (("RunFiles" OR "RanFiles") AND ("Guest" OR "1.vbs" OR "2.vbs" OR "3.vbs" OR "4.vbs" OR "wscript"))
  OR (Image="*\\wscript.exe" AND (CommandLine="*1.vbs*" OR CommandLine="*2.vbs*" OR CommandLine="*3.vbs*" OR CommandLine="*4.vbs*"))
)

Hunt ScreenConnect Guest VBS in Kibana

@timestamp >= "2026-08-20" AND (
  (process.name:wscript.exe AND process.parent.name:*ScreenConnect* AND process.command_line:(*1.vbs* OR *2.vbs* OR *3.vbs* OR *4.vbs* OR *Public\\Libraries* OR *ScreenConnect*))
  OR (registry.value:"WindowsServiceHost" AND registry.path:*CurrentVersion\\Run* AND registry.data:(*WindowsServiceHost.vbs* OR *AppData*))
  OR dns.question.name:(*tele-sync.opik.net* OR *homehub.opik.net*)
  OR (destination.ip:("45.13.237.190" OR "131.123.40.98") OR destination.port:8041)
  OR (message:(*RunFiles* OR *RanFiles*) AND message:(*Guest* OR *1.vbs* OR *2.vbs* OR *3.vbs* OR *4.vbs* OR *wscript*))
  OR process.command_line:(*7a4d7d66502d4260*)
)

Sources

Huntress, Rogue ScreenConnect Installations Across Unrelated Hosts Suggest Worm-Like Activity, updated 3 September 2026. Late-August incidents; Guest RunFiles/RanFiles guidance; WindowsServiceHost persistence; ScreenConnect ID 7a4d7d66502d4260.

ConnectWise, September 3, 2026: ScreenConnect Remote Access: Guest File Transfer Advisory. TransferFiles / TransferFilesInSession interim mitigation; CVE and fix expected within the week.

Huntress IOCs present in the primary write-up but not pasted into the hunts above (keep for enrichment, not invent new ones): VBS and WindowsServiceHost.vbs SHA256 hashes; WindowsServiceHost.bat; %TEMP%\\value.txt / map.txt / out.enc / runner.ps1; PyTorchFix.ps1; Themes.exe (masqueraded wstunnel); SearchIndex.exe (XMRig); svcdrv64.sys (WinRing0); UltraViewer destinations 146.59.55.107 and 45.32.192.150; additional C2/host names borertors92.anondns.net and 15.204.185.204; Dropbox staging URL (offline as of Huntress's September 2 note).

What This Means for Your Team

This case does not open on "rogue ScreenConnect installed." It opens when Guest file transfer runs scripts on a Host and the audit log still has RunFiles or RanFiles with Process: Guest. The endpoint leftovers are wscript.exe on 1.vbs–4.vbs, often from ScreenConnect temp or Public Libraries, plus a WindowsServiceHost Run key aimed at AppData. ConnectWise's 3 September advisory gives you an interim brake—disable TransferFiles / TransferFilesInSession—while the CVE and patch land. If your hunts only watch the RMM brand, you will miss the Guest that pushed the scripts. Observation is still mostly Huntress plus ConnectWise. Hunt the leftovers while the window is quiet.

Strengthening Your Defenses with Inception Protection

At Inception Security, Inception Protection is our MDR for Microsoft environments. We use the Defender, Sentinel, Conditional Access, and Azure licenses you already have. For this chain we hunt ScreenConnect-parented wscript on numbered VBS files, WindowsServiceHost Run values pointing at AppData, Guest RunFiles/RanFiles audit noise, ScreenConnect ID 7a4d7d66502d4260, and the Huntress-listed C2 and secondary RMM leads—while you work TransferFiles hardening pending ConnectWise's fix.

Assessing Your Security Posture with free Inception Foresight M365 Assessment

Want to see where your environment stands against Guest-run script leftovers like these, not just the RMM brand on the ticket? Grab our free Inception Foresight M365 Assessment. No strings. If this is useful, follow Inception Security on LinkedIn and @inceptionsec on X.