Footprints in the Snow

Snowshoe spam is named after the footwear. A snowshoe distributes your weight so you don't break through the surface. A snowshoe spammer distributes a campaign across hundreds of disposable domains, each one sending just enough mail that no single domain accumulates the reputation to get blocklisted before delivery.

I didn't know the term until this investigation. At the end of May, 248 of these emails hit my personal inbox over five days. My spam filter caught 5% of them. SpamAssassin was scoring them below zero, and no amount of threshold tuning was going to change that. So I started working the problem with Claude Code.

I wrote recently about a similar experience buying a car, where an emergent methodology came from correcting Claude Code's assumptions over dozens of sessions. This followed the same pattern. I started with SpamAssassin headers, then one of the emails showed up with the spammer's raw LLM generation prompt instead of a rendered body and I posted about it. Then we kept going. Over the course of the investigation we captured a live scam kit, mapped the sending infrastructure across three continents, and caught three analytical errors along the way. I'm starting to wonder if there's a series in this.

#SpamAssassin

The emails followed the same pattern every time. A fake loyalty notification from a brand I actually shop at (Harbor Freight) and many I do not (Walmart, Lowe's, Ace, CVS), each carrying a sender domain not obviously related to the brand, and a clear spam indicator of a call to action linking elsewhere. This was my frustration: these are obvious spam patterns and ones I would expect my hosted SpamAssassin service to catch.

So digging in, I pulled two emails: one that landed in my inbox, and another that was flagged correctly. Using Claude Code, I compared the headers side by side.

Uncaught — Harbor Tools impersonation

  From: Harbor Tools Team <harbortoolsteam@horsessecure.living>
  Subject: Claim a Pittsburgh Tool Set + 100 Harbor Freight Card Today Only
  List-Unsubscribe: <hxxps://ww6.horsessecure[.]living/SnXHC-ygfqgphouyoG4>
  List-Unsubscribe-Post: List-Unsubscribe=One-Click
  DKIM-Signature: v=1; a=rsa-sha256; d=horsessecure.living; s=mtaazdrzi40tp [valid]
  X-Spam-Score: -6
  X-Spam-Flag: NO
  X-Spam-Status: No, score=-0.7
  X-Spam-Bar: /

Caught — Lowe's impersonation

  From: MyLowesTeam <mylowesteam@nashvillemarketresearch.com>
  Subject: [SPAM] See the My-Lowe's Points in Your account before midnight tonight
  List-Unsubscribe: <hxxps://ww1.nashvillemarketresearch[.]com/DprB-kyyzfpkcfvBR>
  List-Unsubscribe-Post: List-Unsubscribe=One-Click
  DKIM-Signature: v=1; a=rsa-sha256; d=nashvillemarketresearch.com; s=mtavi2qarvets [valid]
  X-Spam-Score: 52
  X-Spam-Flag: YES
  X-Spam-Status: Yes, score=5.2
  X-Spam-Bar: +++++
  X-Spam-Report: (5.2 points, 4.0 required)
      1.9 URIBL_ABUSE_SURBL  [nashvillemarketresearch.com]
      4.0 URIBL_BLACK         [nashvillemarketresearch.com]
     -0.5 SPF_PASS
     -0.0 SPF_HELO_PASS
      0.0 HTML_MESSAGE
      0.1 DKIM_SIGNED
     -0.1 DKIM_VALID_EF
     -0.1 DKIM_VALID_AU
     -0.1 DKIM_VALID

The flagged email scored 5.2. The one that made it through scored -0.7, below zero. SpamAssassin considered it more legitimate than neutral. The entire difference was two URI blocklist rules: the flagged email's sending domain had already been reported to URIBL_BLACK (+4.0) and URIBL_ABUSE_SURBL (+1.9). Strip those and the base score was -0.7, identical to the one that made it through.

That -0.7 was consistent across every sample I checked:

DKIM_SIGNED      +0.1
DKIM_VALID       -0.1
DKIM_VALID_AU    -0.1
DKIM_VALID_EF    -0.1
SPF_PASS         -0.5
SPF_HELO_PASS    -0.0
HTML_MESSAGE      0.0
                 -----
                 -0.7

DomainKeys Identified Mail (DKIM) passed, meaning the email wasn't altered in transit and the sender controls the domain. SPF (Sender Policy Framework) checked out too, confirming the sending IP was authorized. Both passed because the spammer provisioned proper DNS authentication for each throwaway domain they rotated through. SpamAssassin rewards that with negative points. No content rules fired at all.

#The Prompt

While I was troubleshooting SpamAssassin, one of the emails arrived with no rendered content at all. Instead of the usual HTML loyalty notification, the body was the spammer's raw LLM generation prompt. Over 20,000 characters of instructions for an AI to produce the email I was supposed to receive. Their content pipeline had broken mid-send: the stage that runs the prompt failed, but the stage that sends the email worked fine, so the prompt shipped as the body.

I posted the highlights on LinkedIn and the full prompt to Pastebin. The prompt is essentially an annotated evasion spec. Every section maps to a specific filter it's designed to beat.

"Create a new email variant that stays on-brief but not on-template."

On sounding legitimate:

"The text must be natural, human-like, and conversational as if replying to a friend or co-worker."

On evading content filters through hidden text:

"Include TWO separate hidden text sections... One immediately BEFORE the main email table... One immediately AFTER."

It includes 35 CSS techniques for hiding text, randomized per send. The hidden content has to be 100 to 200 words of first-person conversational filler, avoiding the email's topic and anything financial. I went back to the caught emails and checked SpamAssassin's content preview. The "I meant to reply sooner, I've been overthinking a simple plan" filler was this instruction, working as intended. Bayesian poisoning, designed to make the body read as ham to a content scorer.

On not getting caught repeating itself:

"This run must not reuse a previous scaffold verbatim... Make the current run feel like a fresh concept, not a lightly edited duplicate."

Each generation gets a unique run seed (a 32-character hex string) and instructions to produce structurally different output every time. This is deliberate polymorphism, designed to defeat fuzzy hashing and signature-based detection (Razor, Pyzor, DCC).

Five hard rules close the spec: no images of any kind (sidesteps image-spam scoring and OCR), no HTML comments (comments carry reusable signatures), no body unsubscribe link or physical address (avoids footer patterns filters look for), and no merge tags or template variables (avoids the broken-{{first_name}} spam signal). The one-click unsubscribe lives in the headers only, collecting RFC 8058 compliance credit from SpamAssassin. There's no actual opt-out in the email body.

#The Mailbox

I have SSH access to my mail server, so Claude Code and I started enumerating. We searched every folder for messages originating from the three sending IP ranges we'd identified across the initial samples.

248 messages over five days, all hitting the same personal email address. It was on a list.

Claude Code bucketed them by folder and came back with 189 in .spam, 47 in .Trash, 10 in the Inbox. I had to correct that. My .spam folder is three things mixed together: SpamAssassin server-side catches, Mac Mail's trained junk filter, and my own manual flagging. To measure SpamAssassin specifically, I needed the X-Spam-Flag header and the [SPAM] subject rewrite.

# Build file list by sender IP range
find . -type d \( -name cur -o -name new \) -print0 \
  | xargs -0 grep -rlIE \
    'Received: from .*\(\[(104\.243\.247|102\.135\.108|93\.92\.72)\.[0-9]+\]' \
  > /tmp/op.txt
echo "operation total: $(wc -l < /tmp/op.txt)"

# SpamAssassin true catch count
echo "SA caught (X-Spam-Flag: YES): $(xargs grep -liE \
  '^X-Spam-Flag:[[:space:]]*YES' < /tmp/op.txt | wc -l)"

# Cross-check with subject rewrite
echo "[SPAM] in subject: $(xargs grep -liE \
  '^Subject:.*\[SPAM\]' < /tmp/op.txt | wc -l)"

# SA misses, bucketed by folder
xargs grep -LiE '^X-Spam-Flag:[[:space:]]*YES' \
  < /tmp/op.txt > /tmp/op_missed.txt
echo "SA missed: $(wc -l < /tmp/op_missed.txt)"
sed -E 's#^\./##; s#/?(cur|new)/[^/]+$##; s#^$#INBOX#' \
  /tmp/op_missed.txt | sort | uniq -c | sort -rn

operation total: 248
SA caught (X-Spam-Flag: YES): 12
[SPAM] in subject: 12
SA missed: 236
    179 .spam
     47 .Trash
     10 INBOX

SpamAssassin caught 12 out of 248 (5%) by its own flag, all URIBL hits. My Mac Mail filter, which I'd been training by manually flagging these emails for days, caught 179 (72%).

#The Infrastructure

We extracted every call-to-action URL from the 248 messages and deduplicated the sending domains.

import email, re

url_re = re.compile(rb"https?://[A-Za-z0-9.\-]+/[A-Za-z0-9._/~?=&%\-]*")

# op.txt contains one Maildir path per line, built by grepping
# Received headers for the three sending /24s
for fn in open("/tmp/op.txt").read().splitlines():
    try:
        msg = email.message_from_binary_file(open(fn, "rb"))
    except Exception as e:
        continue
    for part in msg.walk():
        if part.get_content_type() in ("text/plain", "text/html"):
            body = part.get_payload(decode=True) or b""
            for u in set(url_re.findall(body)):
                d = u.decode("latin1")
                if "w3.org" not in d:
                    print(d)

231 unique domains for 248 sends. Every CTA URL appeared exactly once. A sample:

hxxp://www.englandpretty[.]garden/eu/scope/vector/8kf2m9x...
hxxp://www.horsessecure[.]living/nz/signal/wire/q4np7rt...
hxxp://www.captainartificial[.]bond/us/relay/junction/2jv8hd...
hxxp://www.climatejoe[.]garden/de/anchor/feed/w9km3px...

Different domains, but the URL paths share a vocabulary: scope, vector, signal, wire, relay, junction, anchor, feed, openlatest, followalong. A two-letter geo code, then path segments drawn from the same word pool, then a unique token. The same vocabulary across 231 unrelated domains is a single kit generating the landing paths.

The domain layer is almost entirely disposable, with 74% sitting on cheap new-gTLDs:

The domains themselves are two concatenated dictionary words, bulk-registered and disposable: understandprison, promisedsuper, gangimprovement, captainartificial. Each one carries valid DKIM and SPF, meaning the operator auto-provisions DNS authentication per domain at scale.

The sending infrastructure underneath doesn't rotate. All 248 messages came from three /24 ranges, the same three behind all 231 domains:

#The Landing Page

I wanted to see what those CTA URLs actually delivered, but there was an OPSEC problem. Fetching from my mail server or home IP would confirm to the operator that the mailbox is active and someone is investigating. My first thought was to permute the URL token slightly, hit a neighbor like 8kf2m9y instead of 8kf2m9x. Claude Code walked me off that: the tokens are opaque random strings with no derivable relationship to the run seed or variation tokens. A permuted guess either 404s, or worse, burns a different victim's tracker. And the request itself tells the operator someone is probing their infrastructure.

We started with passive tools. urlscan.io, VirusTotal, URLhaus, PhishTank. Three urlscan scans of campaign URLs came back empty: 204 No Content, 404, or a 302 redirect to expressvpn.com/?utm_source=cts. VirusTotal and URLhaus had no cached content. Claude Code's read was that the tokens had a short shelf life and had expired.

This was a huge tell for me. I was certain this was some sort of evasion tactic at hand. Despite Claude Code not seeing the pattern, I insisted, and ended up switching into manual testing, using incognito and my mobile phone as a hotspot (to avoid exposing my home's upstream provider). The page was live.

A Walmart-branded survey promising a $100 gift card, an urgency timer counting down, fake "verified customer" comments from hardcoded names like Daniel Clark and Anantara Evans, and a form at the end collecting name, address, and credit card for a "processing fee." The fine print: "Cost of processing fee and/or handling fee is for an entry for a chance to receive the product."

Claude Code's expiry theory was wrong. The page was filtering visitors by profile. Scanner IPs and known research infrastructure get a 204 or a redirect to ExpressVPN's affiliate program (the utm_source=cts tag is the operator's affiliate publisher ID). Load the same URL on a real browser over a residential or mobile connection and you get the scam.

Then I checked view-source on the same live page, and found a second evasion tactic. The HTML source was a clone of ExpressVPN's actual homepage. The scam content exists only in the rendered DOM, injected entirely by client-side JavaScript after the page loads. View source shows a legitimate website. The scam kit only appears in the rendered DOM through DevTools. I captured the full rendered DOM through Chrome DevTools while the page was live.

window.surveyConfig = {
  "target": "wlm",
  "brand_name_html": "Walmart",
  "brand_color": "rgb(0, 102, 204)",
  "questions_json": "datas/wlm.json",
  "offers_json": "offers_json/offers_2_m.json?kwd=wlm"
    + "&c=|77328&k=&v=&s=1938&t=&cr=opfxx3&src="
    + "&lp=normal&id=whrc8fvus73s2nrijtqjh1a4"
    + "&isp=att enterprises llc"
    + "&chki=NGZjYTBkMTgwM2E0YWY1ZDhmNGI2Mjg5MDNkZTgzMTQ="
    + "&browser=Chrome"
    + "&chkb=OTg2YzM3NDgwYjFmMWMyZTQ0MzUwNGIzOGI2MzYxYjQ="
    + "&s2=opfxx3&s3=&s4=&s5=",
  "timer_seconds": 390,
  "custom_body_text": null,
  "custom_frs_text": null,
  "confirmation_club": false,
  "custom_comment_overrides": [],
  "single_offer": false,
  "show_popup": true
};

The kit is parameterized. A window.surveyConfig object configures the target brand, survey questions, offers, and countdown timer. The tracking parameters include ISP fingerprinting (isp=att enterprises llc), visitor and browser hashes, a CPA publisher ID (c=|77328), and campaign and creative codes. Assets serve from two CloudFront distributions. The kit is built to run any brand, not just Walmart.

<script>
var _0x45a3=['href','310326TemamY','$1//$2','3789jqLAjI',
'201260CufYBR','includes','location','624856ogdMrz',
'28pRWhXX','10734yvtFqz','352RuMMpQ','1339PvpRAh',
'392868PctkdY','indexOf','596BmZxvY'];
var _0x5ce7=function(_0x34bb17,_0x37718d){
  _0x34bb17=_0x34bb17-0x1b8;
  var _0x45a37a=_0x45a3[_0x34bb17];
  return _0x45a37a;};
var _0x3c82e1=_0x5ce7;
(function(_0x4279be,_0x4a014c){
  var _0x2ec4e6=_0x5ce7;
  while(!![]){try{
    var _0xe2f92d=-parseInt(_0x2ec4e6(0x1c4))
      +parseInt(_0x2ec4e6(0x1c2))*-parseInt(_0x2ec4e6(0x1bf))
      +-parseInt(_0x2ec4e6(0x1c0))
      +parseInt(_0x2ec4e6(0x1bc))*parseInt(_0x2ec4e6(0x1bd))
      +parseInt(_0x2ec4e6(0x1bb))
      +-parseInt(_0x2ec4e6(0x1b8))
      +parseInt(_0x2ec4e6(0x1c6))*parseInt(_0x2ec4e6(0x1be));
    if(_0xe2f92d===_0x4a014c)break;
    else _0x4279be['push'](_0x4279be['shift']());
  }catch(_0x1227cb){
    _0x4279be['push'](_0x4279be['shift']());
  }}}(_0x45a3,0x87e5e));
var params='';
params!=''&&(window[_0x3c82e1(0x1ba)][_0x3c82e1(0x1c3)]
  [_0x3c82e1(0x1c1)]('?')<0x0
  ?params='?'+params:params='&'+params);
if(window['location']['href'][_0x3c82e1(0x1b9)]('#'))
  window[_0x3c82e1(0x1ba)][_0x3c82e1(0x1c3)]=
  window['location'][_0x3c82e1(0x1c3)]['replace'](
    /(.*?)\/\/(.*?)\/(.*)#/,_0x3c82e1(0x1c5))+params;
</script>
<html>
<body>
<script defer
  src="hxxps://static[.]cloudflareinsights[.]com/beacon.min.js/v84..."
  data-cf-beacon='{"token":"7092b83116ff4010907be780fcec704d"}'
  crossorigin="anonymous">
</script>
</body>
</html>

#Attribution

I wanted to know who was behind this from early in the investigation. Claude Code kept steering toward detection rules and analytical work, which was useful, but I was interested in the operator. When I explicitly asked about attribution, Claude Code distinguished between the snowshoe mechanism and the identity question, then offered a list of seven research directions with attribution buried at number three.

I pushed. We started with the landing side, resolving all 231 domains through a public DNS resolver. Claude Code predicted they would converge on a small set of operator-controlled IPs, since registering 231 domains is cheap but standing up 231 web hosts isn't. Most came back as Cloudflare. Six resolved to a single AWS IP: 52.20.84.62. Claude Code got excited, called it "the crack in the mask," and started building a case that this was the shared origin for the whole fleet.

I ran a reverse DNS lookup on that IP. 2.1 million domains. A shared parking and redirect service. We tried certificate analysis next, then passive DNS history. Same result every time: CDN, parking, shared infrastructure. Every passive pivot on the landing side dead-ended. Claude Code walked it back and recommended we drop the landing-side hunt entirely.

That left the sending ranges. I ran WHOIS on the three /24s from my mail server.

The first two ranges share the same abuse contact (admin@pointtoserver.com) and the same "Internet Security" branding. The typo in the AFRINIC record, secuirty, is a copy-paste artifact that fingerprints the provisioning across both blocks better than any clean string would. These are the same operator, sourcing sending space from two different Regional Internet Registries (RIRs).

The third range is a separate supplier. Italian telco, different abuse contact, no pointtoserver.com fingerprint.

The ARIN parent block for the vititude range names it outright: NetName PUREVPN, OrgName Secure Internet LLC, abuse handle GADIT3-ARIN listing contact Uzair Gadit, phone +1-217-651-4225. The estate has a documented abuse footprint across multiple carriers and regions.

Three /24s sourced from three RIRs (ARIN, AFRINIC, RIPE) is deliberate. No single registry's abuse process covers the whole operation.

The phishing campaign sends from IP space administered by the Secure Internet LLC / pointtoserver.com network, confirmed by matching abuse contacts and branding across two registries. Whether that network operates the campaign or leased snowshoe-friendly space to a downstream customer is a different question. The /24s carry thin downstream reassignment labels, which is the signature of a leasing provider.

#The Ceiling

We identified the sending infrastructure. The campaign operator is still unknown. Every passive method I had access to is now exhausted. The operation has no public footprint in any threat intelligence feed I checked. Zero results on the kit identifiers, the Cloudflare analytics token, or the CloudFront distribution IDs. The TDS domains (surveysreswards.com, insighthepanel.com) are both registered through Internet Domain Service BS Corp with Whois Privacy Corp in Nassau, Bahamas.

Three parties hold information that could break this open:

ExpressVPN. The affiliate tag utm_source=cts is being used in two ways: scanner traffic gets a 302 redirect to ExpressVPN's affiliate signup, and the source HTML served to real browsers on the live scam page is ExpressVPN's homepage (either cloned or proxied, serving as a shell that JavaScript replaces with the scam kit in the rendered DOM). ExpressVPN can identify the affiliate behind that tag and share payment details with law enforcement.

Cloudflare. The Cloudflare Web Analytics token 7092b83116ff4010907be780fcec704d is embedded in the TDS source, linking all traffic distribution to a single Cloudflare account. Both TDS domains sit behind Cloudflare nameservers. Cloudflare holds the account holder's identity.

AWS. The CloudFront distributions d3e1y4kqljcb and d3e1y4kxkqljcb serve the scam kit's assets. AWS holds the account owner.

The actual identity of the operator behind the TDS and scam kit is still unknown. So is the CPA network behind publisher ID c=|77328, and whether the sending infrastructure (pointtoserver.com / Secure Internet LLC) and the scam kit operator are the same entity or a client and vendor.

The full IOC table is published as a companion to this post.

If any of these identifiers look familiar, I'd like to hear from you. Contact page.