This post follows the same pattern as Hunting the Rapuncel Infostealer: threat intelligence publishes, the IOC section describes what to hunt, and this translates those indicators and behaviors into CQL you can run in CrowdStrike Falcon NGSIEM today. Source: Microsoft Threat Intelligence on X, published October 3, 2026.
The Campaign
Standard ClickFix: a compromised website shows a fake CAPTCHA, tells the user to press Win+R and paste a command, and the command fetches a payload from a C2 domain. Network tooling can catch the fetch. This variant removes that step.
When the user visits the compromised site, injected JavaScript silently pre-stages the VBScript payload in the browser’s disk cache. It is stored as a generic f_xxxxxx file, disguised as a PNG. This happens before any user interaction. By the time the CAPTCHA lure prompts Win+R, the payload is already sitting on disk. The command the user pastes does not reach out to download anything. It walks the browser’s cache directory, matches the staged file by size, copies it to %TEMP%\t.vbs, and hands it to wscript.exe.
That kills network-layer detection at the execution stage. The only network activity is the initial page load and the post-execution C2 callback from PowerShell.
From there: wscript.exe runs WMI host enumeration, fetches v.ps1 from cocojambo[.]us[.]com/alfa, which downloads cab.dat and triggers in-memory .NET compilation via csc.exe → cvtres.exe → timeout.exe. Code injects into timeout.exe for browser credential theft and C2 to capsysnet[.]vg and ciliabula[.]cc. Persistence: tar.exe unpacks an embedded Python runtime to %APPDATA%, schtasks.exe creates a logon task running pythonw.exe.
Hunting It in CrowdStrike NGSIEM
Five queries ordered by position in the kill chain. All are LogScale HQL for CrowdStrike Falcon NGSIEM. Q1 and Q5 are the highest-value starting points.
All queries are also available as a copy-ready gist: gist.github.com/ltorresv/59fcc092e2e9b49fb72b9a0d06c0b505
Q1: RunMRU Registry Hunt (primary IOC, retrohunt-friendly)
Every command pasted into Win+R writes to HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU. The entry persists after the process exits. That makes this useful for retroactive investigation days or weeks after the wscript execution is gone from process logs, which is where most ClickFix detections actually land.
#event_simpleName = "RegSetValue"
| RegObjectName = /\\Explorer\\RunMRU/i
| RegValueName != "MRUList"
| (RegStringValue = /wscript/i OR RegStringValue = /mshta/i
OR RegStringValue = /powershell/i OR RegStringValue = /rundll32/i
OR RegStringValue = /Profiles/i OR RegStringValue = /\.vbs/i
OR RegStringValue = /\.ps1/i OR RegStringValue = /LOCALAPPDATA/i)
| table([ComputerName, UserName, ContextProcessName, RegStringValue, timestamp])
| sort(timestamp, order=desc)cmd is intentionally omitted from the regex, since it is too noisy from legitimate admin activity. The field to check first: ContextProcessName. In a clean hit it should be explorer.exe. If it is anything else, that host goes to the front of the line.
I ran this as a 90-day retrohunt after the Microsoft post dropped on Friday. Three results. Two were IT batch file shortcuts; MRUList ordering confirmed they predated the campaign by weeks. The third was a developer running Get-Service from the Run box. None were ClickFix. The query fires correctly; the triage is fast.
Q2: Browser Cache to VBScript Drop (pre-execution)
This fires before wscript runs. It catches the cmd.exe command that traverses the browser cache directory and copies the staged payload to %TEMP%\t.vbs. Earlier in the chain than Q1 and closer to prevention, but it requires the specific directory traversal patterns, which means you need the user to have visited the compromised site on a browser whose cache path matches the query.
#event_simpleName = "ProcessRollup2"
| ParentBaseFileName = "cmd.exe"
| (CommandLine = /\\Mozilla\\Firefox\\Profiles/i
OR CommandLine = /\\Chrome\\User Data/i
OR CommandLine = /\\Edge\\User Data/i)
| CommandLine = /copy/i
| CommandLine = /\.vbs/i
| table([ComputerName, UserName, CommandLine, ParentBaseFileName, timestamp])A single hit here means the user already pasted and ran the command. The payload is on disk. Pull the full process tree for that aid immediately.
Q3: wscript/cscript Executing from TEMP
wscript.exe or cscript.exe executing anything out of %TEMP% is not something your users do legitimately. This query is almost always signal.
#event_simpleName = "ProcessRollup2"
| (ImageFileName = /(?i)\\wscript\.exe$/ OR ImageFileName = /(?i)\\cscript\.exe$/)
| (CommandLine = /(?i)\\Temp\\/ OR CommandLine = /(?i)\\AppData\\Local\\Temp\\/)
| table([ComputerName, UserName, ImageFileName, CommandLine, ParentBaseFileName, timestamp])
| sort(timestamp, order=desc)Match on CommandLine rather than ImageFileName for the path. The script’s location appears in the command line argument, not the wscript process image path. Depending on sensor version, FilePath may also be populated; add it to the table if you want both for comparison.
Q4: Python Persistence via tar.exe and schtasks
The final persistence stage uses two Windows built-ins that rarely appear together outside IT or dev environments: tar.exe (a LOLBin since Windows build 17063) to unpack a Python runtime, and schtasks.exe to register the logon task. Either sub-condition alone is worth alerting on outside a developer workstation context.
#event_simpleName = "ProcessRollup2"
| (
(ImageFileName = /(?i)\\tar\.exe$/ AND CommandLine = /python/i) OR
(ImageFileName = /(?i)\\schtasks\.exe$/ AND CommandLine = /pythonw/i)
)
| table([ComputerName, UserName, ImageFileName, CommandLine, ParentBaseFileName, timestamp])If Q4 fires from a non-dev machine, assume the earlier stages have already run and work backwards from the aid.
Q5: Correlated Chain (high-fidelity, two-part)
These two queries run separately. Part A surfaces the RunMRU indicator hosts. Part B narrows scripting process activity to those same machines, which is where the actual verdict lives.
Part A: RunMRU indicator hosts:
#event_simpleName = "RegSetValue"
| RegObjectName = /\\Explorer\\RunMRU/i
| RegValueName != "MRUList"
| (RegStringValue = /Profiles/i OR RegStringValue = /\.vbs/i OR RegStringValue = /LOCALAPPDATA/i)
| groupBy([ComputerName, UserName], function=count())
| sort(_count, order=desc)Part B: Scripting processes on those hosts (add ComputerName filter from Part A):
#event_simpleName = "ProcessRollup2"
| ComputerName = /WORKSTATION_FROM_PART_A/i // replace with actual name(s)
| (ImageFileName = /(?i)\\wscript\.exe$/ OR ImageFileName = /(?i)\\cscript\.exe$/ OR ImageFileName = /(?i)\\powershell\.exe$/)
| table([ComputerName, UserName, ImageFileName, CommandLine, ParentBaseFileName, timestamp])
| sort(timestamp, order=desc)When Part A returns a short list (it usually does), the manual join is two minutes. The correlated result is what you bring to the incident channel, not a raw list of RunMRU hits.
The Pattern
The cache pre-staging step is technically interesting, but from a detection standpoint it mostly shifts where your coverage lives. Network tooling looking for wscript.exe making suspicious outbound connections catches nothing. The execution stage is clean by design. What survives in CrowdStrike is the Win+R paste in RunMRU, the cache traversal in cmd.exe process arguments, and wscript executing from TEMP. All endpoint events that were already being logged.
RunMRU is underused as a hunt surface. It is writable by any process, it persists after execution, and the signal profile is good: legitimate users do not paste scripting commands into the Run dialog. The false positive rate in my retrohunt was zero across three hits. Making it a standing hunt query costs almost nothing and the payoff on any real hit is immediate context.
The thing this variant gets right is timing. The payload arrives before the social engineering starts, so the only window to break the chain at network is the initial compromised-site visit. Everything after that is local. Your EDR coverage becomes the primary control, not secondary.
All IOCs in this post are derived from the Microsoft Threat Intelligence post published October 3, 2026. Domains are defanged. File hashes were intentionally omitted, since the cached payload is served fresh per visitor and hashes are valid only until the next delivery.
Detections like these are only useful if someone is watching. If your team is stretched thin on threat response, see what fractional CISO coverage looks like in practice.
Need a hand with this at your company?
543HQ helps startups and growing companies build security programs that actually work. Start with a free 30-minute call.
Book a Free Call