Spam Tales: Claim Your Free Stanley Tool Set

Overview

Sweet, a tool set!

Methodology

For this type of email lure, I like to preserve a few layers separately:

1. Capture the rendered email before interacting with any links.
2. Review the sender, recipient, timestamps, and authentication results.
3. Inspect the raw HTML for hidden text, tracking, encoding tricks, and unusual objects.
4. Open the link in an isolated browser or sandbox.
5. Record the first-hop domain, JavaScript redirects, and any visible URL parameters.
6. Separate victim-specific fields from reusable campaign indicators.

Tools used

• Email source view for MIME structure and hidden HTML content
• Message authentication summary for SPF, DKIM, and DMARC results
• Browser developer tools in an isolated environment (Browserling)
• Manual IOC extraction from the lure, auth panel, and first-hop landing page

Email Authentication

The message presented itself as:

From: O'Reilly Auto Parts <[email protected]>
Subject: Claim Your Free Stanley Tool Set!
Created: Mon, Apr 27, 2026 at 3:35 PM

The authentication panel:

Observed results:

SPF:   PASS with IP 103.136.41.191
DKIM:  PASS with domain Uj30.store.ass0041.xalprimo.biz.ua
DMARC: FAIL

tip

SPF and DKIM can pass individually while DMARC fails because DMARC also cares about alignment with the visible From domain. Here, the visible From domain was cultd.xfr, while DKIM aligned to an unrelated xalprimo.biz.ua subdomain.

Investigation

Lure structure

The lure uses a familiar reward-survey flow:

Claim your free Stanley Tool Set
Complete this short 30-second survey
Get started now
Reward status: Pending

The rendered body also claims that the message was sent from a trusted sender. That line is part of the lure's credibility play, not an authentication result to trust.

Hidden filler text

The HTML source included hidden content inside zero-height, zero-width, opacity-zero objects. The visible snippet begins with the trusted-sender language, then buries unrelated prose in the body.

Redirect chain

The original link used a Google Cloud Storage object with campaign parameters placed after the fragment marker:

https://storage.googleapis.com/strow/strw_v3.html#?act=cl&pid=19298_md&uid=4&vid=849710&ofid=118&lid=486&cid=534301

That page presented a fake Cloudflare-style security check and used a Turnstile callback to preserve the fragment while moving the browser to the next host:

function onSuccess() {
  const h = window.location.hash || "";
  window.location.replace("http://strw3.gogomailbali.it.eu.org/" + h);
}

That produces:

http://strw3.gogomailbali.it.eu.org/#?act=cl&pid=19298_md&uid=4&vid=849710&ofid=118&lid=486&cid=534301

Fake Cloudflare gate

The Cloud Storage page visually imitates a Cloudflare security check:

Under the hood, it loads Cloudflare's Turnstile API and embeds a Turnstile widget with a reusable-looking site key:

<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>
<div class="cf-turnstile" data-sitekey="0x4AAAAAAAWyD8kIgIxaOYq5" data-callback="onSuccess"></div>

The page also generates a fake-looking Ray ID client-side:

document.getElementById('ray').textContent =
  Math.random().toString(36).substring(2, 10).toUpperCase();

That combination is a nice social-engineering layer: it borrows the look of a known security brand, presents the URL as already "clean," then requires interaction before forwarding the victim to the next campaign host.

info

One funny-but-benign artifact here: Cloudflare's Turnstile API script at:

https://challenges.cloudflare.com/turnstile/v0/api.js

contains logic that sends a watchdog-style message like:

{ event: "meow", source: "cloudflare-challenge", widgetId: ... }

and then handles a response event:

case "food":
  ...

So meow / food appears to be Cloudflare's internal parent-frame to challenge-iframe heartbeat/ack messaging. Delightfully silly, but not suspicious by itself.

Landing page behavior

The second-stage URL observed in the sandbox used:

strw3.gogomailbali.it.eu.org

The page itself was nearly empty except for a script that rewrites fragment-marked URLs into normal path separators:

The visible script logic checks whether the current URL contains #, then replaces escaped and unescaped hash markers with /.

In practical terms, this lets the actor place routing data after a URL fragment and then normalize it client-side after the page loads. It also makes the original link a little less straightforward for static URL parsers that do not execute JavaScript.

For this lure, the normalized next URL is:

http://strw3.gogomailbali.it.eu.org/?act=cl&pid=19298_md&uid=4&vid=849710&ofid=118&lid=486&cid=534301

And then I lost the redirect trail, drat!

Earlier-month pivot

A related Hybrid Analysis submission from April 11, 2026 shows the same storage.googleapis.com/strow/strw_v3.html object, fake CAPTCHA/security verification behavior, and redirect to strw3.gogomailbali.it.eu.org:

• https://hybrid-analysis.com/sample/56be8f22434065af1080d922e24ea95d8beb1f967d86b346f01651ca28eb638a/69dacb78401c5f72a40ee976

That earlier sample used an encoded fragment:

https://storage.googleapis.com/strow/strw_v3.html?#%3Fact%3Dcl%26pid%3D18125_md%26uid%3D4%26vid%3D650852%26ofid%3D414%26lid%3D348%26cid%3D989216

After the Cloud Storage page redirected to strw3, the strw3 fragment-rewrite logic produced a path beginning with %3F instead of a normal query string:

http://strw3.gogomailbali.it.eu.org/%3Fact%3Dcl%26pid%3D18125_md%26uid%3D4%26vid%3D650852%26ofid%3D414%26lid%3D348%26cid%3D989216

Hybrid Analysis observed that encoded-path request returning 404 Not Found. That makes the newer literal #?act=... version worth noting: it normalizes into a clean query string instead of an encoded path.

Hybrid Analysis also matched the HTML against fake CAPTCHA social-engineering behavior. The relevant pattern was the combination of Cloudflare-branded verification text, Turnstile challenge markup, and the redirect callback:

Detected social engineering methods via fake CAPTCHA site in HTML
window.location.replace("http://strw3.gogomailbali.it.eu.org/" + h)
Security Verification
Cloudflare | Security Check

The embedded challenge script includes normal Cloudflare challenge terms such as cloudflare-challenge, turnstile_timeout, turnstile_expired, invalid_sitekey, and unsupported_browser. Those strings are not malicious on their own, but in this case they appear inside an attacker-controlled gate whose success callback redirects to unrelated HTTP infrastructure.

IOCs

cultd.xfr
103.136.41.191
ass0041.xalprimo.biz.ua
gogomailbali.it.eu.org
56be8f22434065af1080d922e24ea95d8beb1f967d86b346f01651ca28eb638a

Detection Logic

IF
message display name impersonates a known brand
AND DMARC fails
AND DKIM passes with a domain unrelated to the visible From domain
THEN
brand impersonation or spoofed reward lure likely

IF
HTML contains hidden zero-size or opacity-zero text blocks
THEN
spam-filter evasion likely

IF
page imitates Cloudflare security verification
AND callback redirects to an unrelated HTTP domain using window.location.hash
THEN
fake CAPTCHA gate for phishing redirect likely

Observations & Conclusions

1. The social engineering is a simple survey-for-reward offer.
2. The sender identity imitates a recognizable retail brand.
3. The authentication results show partial pass signals but failed domain alignment.
4. The HTML includes hidden filler text to muddy content-based filtering.
5. The first stage uses a fake Cloudflare verification page hosted from Google Cloud Storage.
6. The second stage uses JavaScript to normalize a fragment-heavy tracking URL.
7. An April 11 sandbox sample shows the same hosted HTML object and redirect host - I'm not special, boo hoo!