Definition
An adaptive phishing kit is a phishing page that runs a check against the visiting device — operating system, screen size, location, or a browser fingerprint — before deciding what to show or deliver, so the same link produces a different attack for different victims.
How It Compares
| Mobile / non-Windows visitor | Windows visitor | |
|---|---|---|
| What loads | A cloned login page matched to the victim's actual email provider (Gmail, Outlook, Yahoo) | A fake "Norton security check" animation |
| What it takes | The typed password, sent straight to the attacker | A malware payload, downloaded quietly in the background |
| Decision point | One conditional check on the visiting device, evaluated before the page finishes loading | Same check, opposite branch |
In one documented kit, the entire branching logic was a single conditional: if the visiting device is Windows, deliver the file; otherwise, harvest the password. The lure in front of it — a fake dinner invitation from a pastor, built on a real invitation-service template — was ordinary on purpose. The branching logic behind the "view invitation" button, not the bait itself, is what did the work.
The Evidence
A separate FedEx "delivery failed" smishing case showed the same adaptive pattern applied to location and time instead of OS:
- Legitimacy theater first: the link led to a Cloudflare Turnstile "prove you're human" check before showing any scam content — the same pattern legitimate sites use, likely borrowed because it reads as trustworthy to a visitor before they've seen anything else.
- Location spoofing observed live: the page's "Delivery To" field briefly displayed Sacramento before resolving to Seattle — the phone's actual location — indicating the page pulled the visitor's real location and substituted it into the fake shipment record.
- Time spoofing: the "Delivery Failed" timestamp shown matched the exact time on the victim's phone clock in the screenshot, making the failure appear to have just happened to that specific visitor.
- Fingerprinting without analytics: the page fingerprinted every visitor (canvas rendering, installed fonts, screen geometry — enough to build a unique ID per person) but ran no analytics platform of any kind. A real corporate site runs analytics; the deliberate absence here indicates the operator wanted visitor tracking on their own terms, without leaving the kind of trail that would let investigators track them back.
These kits are reused, not one-off builds. A separate delivery-scam investigation on a .shop domain was linked to a second .shop delivery scam within the same day, based on two matching signatures: both used a random nine-character hostname pattern, and both sent the exact same delivery code in their SMS message. Shared infrastructure across both sites confirmed it was the same underlying kit, redeployed rather than rebuilt — the adaptive logic described above isn't hand-crafted per campaign, it's kit infrastructure meant to be reused across many simultaneous scams.
What To Do About It
- Don't tap links in unsolicited delivery or account texts. Open the carrier or vendor's official app or website directly instead of following the link.
- Treat a "human verification" screen as neutral, not reassuring. Turnstile and similar checks appear on both legitimate sites and phishing pages — their presence alone proves nothing about legitimacy.
- Don't type a password into any login page reached by following a link from a text or email. Navigate to the service directly and log in from there if you need to check something.
- Forward suspicious texts and emails to a scam-investigation contact rather than acting on them yourself — the specific behavior (what loads, what it asks for) is what identifies the kit, and that's easiest to confirm from a fresh, unclicked copy.
Caveats & Edge Cases
Legitimate delivery-failure notices and account-security texts do exist and sometimes arrive close to a real event, which is what makes the location/time-matching trick effective — the coincidence feels personal. The distinguishing signal isn't whether the message could be real, it's whether the link routes through an unfamiliar domain rather than the carrier or vendor's own site or app.