The Redirect That Lied About Its Own Destination

One button. A notice about messages being held undelivered reached the philanthropic-fundraising arm of a regional hospital system, offering a single orange call to action reading "View Emails." Underneath it sat a bio-link redirector on TikTok, its query string padded with parameters shaped exactly like a Google DoubleClick ad-click pass-through, including a field naming the campaign's own landing domain.

Automated scanning rated the link clean. Both copies of it, in fact. So the verify pass pulled the scanner's stored screenshots instead. The page that came back was not on the domain the URL's own parameter named. It was a bot gate on an entirely different domain, one that appears nowhere in the link and nowhere else in the case record.

A Call to Action Dressed as Ad-Tech Plumbing

What is verifiable, verbatim out of the raw HTML, is the shape of the string. The button pointed at a tiktok[.]com/link/v2 endpoint carrying an application id and a scene=bio_url marker, the profile bio-link handler, not an ordinary content URL. Threaded into it was a target= parameter formatted as adclick[.]g[.]doubleclick[.]net/pcs/click with an opaque tracking token, and then an adurl= parameter naming a privacy-registered domain that had been sitting quietly well over a year before this send.

The reasoning is not subtle. Every early hop a reputation engine encounters belongs to a household name. A major social platform. A major ad-serving network. Neither is blockable, neither carries a fresh-registration signal, and both hold valid certificates and real traffic. MITRE ATT&CK files the delivery under spearphishing link, and the 2026 Verizon Data Breach Investigations Report puts phishing behind 16% of breaches as an initial access vector, with credentials in play across 39%. Reputation-first URL analysis is the control this shape is built to satisfy.

One caution, because the record supports no more than this: what was confirmed is that the string exists in the message. Nobody watched the ad-network hop function as a working pass-through, and text is not a traversal.

The Screenshot and the URL Named Different Domains

The message carried two near-identical copies of the call to action, and the platform scanned both. One screenshot shows an error page rendered at the social platform itself, the attempt dying before it went anywhere. The other, the one that actually got somewhere, is tagged with a different domain, tristateindustrialsupplwixy[.]vu, a random-suffix name on a disposable country-code namespace, WHOIS-dark. It displayed an interstitial demanding a checkbox before continuing, the familiar verify-access challenge.

Set the two artifacts side by side and the disagreement is the finding. The URL says its endpoint is one domain. The only capture of a successful resolution says another. Either the chain hops onward past what the parameters describe, or those ad-network parameters are decoration rather than working plumbing, and the record does not settle which. What it does settle is the general lesson: a URL's parameters are an assertion by whoever wrote them, while a screenshot is evidence. Even a fully expanded, fully readable redirect chain can misdescribe its own terminus.

The bot gate deserves the same discipline. An interstitial that will not render until a human clicks is an anti-automation control, and a plausible reason a link scan came back clean twice. It is not a credential form. Whatever waits behind it was never observed, and CISA's phishing guidance is direct about how routinely campaigns hide the payload one interaction deeper than a crawler goes.

The Fragment That Spelled Out the Target

Appended to the link, after the hash, was a base64 blob. Decoding it independently, rather than trusting any narrative about it, returns the recipient's exact mailbox address. This link was minted for one person.

That matters twice over. Per-target personalization lets the landing page greet the victim by address and prefill a username field, the strongest trust cue a credential page has. It also means the address rode along encoded, and a URL fragment is never sent to the server at all, so a control grepping link strings for plaintext addresses sees nothing to flag.

The footer undercut the performance. It named the recipient's own address, then declared the message intended for that address "only for" the webmail service of an unrelated business, with a mailbox at that business beside it, neither connected to the hospital system or the sending domain. That is kit residue, boilerplate left unscrubbed from a previous target.

See Your Risk: Calculate how many threats your SEG is missing

The Display Name Did All the Impersonating

The visible sender read as the hospital system's own name followed by "Exchange" and a hex string, the sort of alias that scans as internal mail plumbing. The address behind it sat on a long-established European nonprofit domain created back in 2001, on a mainstream registrar with national DNS hosting, a real organization with a real mail history. The platform's own impersonation detector flagged the mismatch independently: the name in view was not the domain in the header.

That nonprofit is a bystander, not a participant. SPF and DKIM at every hop align to Amazon SES, the ESP account the attacker was sending through, and never to the nonprofit's domain. Nothing of theirs was touched. DMARC for their domain failed outright at the origin hop, and the only reason that cost the attacker nothing is that the domain publishes p=none, report-only, with no enforcement behind it. RFC 9989 evaluates alignment, never intent, and a non-enforcing policy is the gap that DMARC monitoring and management exists to close.

One line in the case notes is worth deflating. The final-hop verdict shows SPF failing, which read alone looks like header manipulation. It was not. That check ran against the relay IP of the recipient organization's own inbound gateway, which had already forwarded the mail, and SPF passed legitimately at the earlier hop against the true sending IP. An ordinary forwarding artifact, and calling it tradecraft sends triage after a technique nobody used.

What Actually Carried the Verdict

Our Adaptive AI scored the message at 90% confidence and labeled it credential theft, and it got there without help from the link. The URL scan was clean on both elements, and there were no attachments. What remained was content and language pattern analysis, the sender-behavior inconsistency between the alias in view and the address in the header, and community reputation signals from similar previously reported mail. The single affected mailbox, a gift-officer role in the foundation, was quarantined and the incident auto-resolved as phishing.

That division of labor is the point. When every scannable hop is reputable and the terminus hides behind an anti-bot challenge, URL verdicts stop saying much about credential harvesting. Sender behavior, brand-to-domain consistency and language stay readable. NIST defines phishing around deception rather than payload, and the deception was legible in the headers even while the destination refused to show itself.

Indicators of Compromise

MITRE ATT&CK Mapping

• T1566.002, phishing via spearphishing link, delivered as one per-recipient redirector URL
• T1036.005, masquerading by matching a legitimate name, the display name rewritten to the target organization's own brand

The Takeaway

Two habits break here at once. The expensive one is reading a redirect URL as documentation of where a click lands, because a target= or adurl= value is authored by the attacker and costs nothing to falsify. Our own URL and our own screenshot disagreed about the endpoint, and only one of them was a measurement. The cheaper one is treating a clean link verdict as a statement about a page: when a chain opens on platforms nobody can block and closes on a challenge no crawler will pass, that verdict describes reachability, not content. Expand redirect chains, check the expansion against a capture, and keep the controls that read the sender and the language.