Five Security Vendors Rewrote This Link. None of Them Stopped It.

The button said View your Report. Between every letter sat a zero-width joiner, an invisible control character that splits a word for a machine while leaving it whole for a human. A person read a clean call to action. A keyword filter scanning the raw text saw no word at all.

That is the small trick. The large one is what the link did before anyone clicked it. By the time the message landed, the destination behind that button had been rewritten five separate times, each rewrite added by a different security vendor. The final hop resolved to a credential-harvest host. Not one of the five rewriters stopped it. Each one passed it to the next.

This is what a laundered link looks like, and it is a direct consequence of how layered email security actually gets deployed.

The remittance lure that borrowed two brands

The email announced a document ready for signature: an accounts-receivable statement and a quarterly settlement report, both attributed to the recipient's own company, both flagged as past due. Financial urgency with a personalized reference is a reliable opener. Business email compromise (BEC) and payment-fraud pretexts work because they mimic a routine the target performs without a second thought.

The rendering gave it away, if anyone was looking. The header carried a SharePoint document-services logo. The footer carried an Indeed logo and boilerplate describing a professional employer organization, with a corporate mailing address that had nothing to do with SharePoint. Two unrelated brands stapled to the same message. Real notification systems do not do this. Automated phishing templates, assembled from scavenged assets, do it constantly.

The greeting used a truncated form of the recipient's username rather than a proper name, another tell of a template populated from an address rather than a directory.

Why five vendors touched the same link

Here is the mechanic that makes this case worth studying. The recipient's mailbox was not the message's first stop. It arrived after being forwarded across several organizations' mail infrastructure, and each stack that handled it applied its own time-of-click URL protection.

Time-of-click rewriting is a standard, legitimate defense. A gateway replaces the original link with a wrapper pointing at its own scanning service, so the destination gets re-checked at the moment of the click rather than at delivery. Useful in isolation. The problem is what happens when a message crosses several of these systems in a row.

The link behind the button resolved through this sequence of vendor wrappers before reaching the true host:

urlsand.esvalabs.com -> shared.outlook.inky.com -> atpscan.global.hornetsecurity.com -> securelinks.cloud-security.net -> url-shield.securence.com -> hxxps://icchost[.]com/docx

Five commercial security services, nested in order, each one wrapping the wrapper before it. Every domain in that chain is a legitimate vendor with a clean reputation. And that is exactly the failure. A downstream scanner inspecting this link sees the domain of the security vendor one hop upstream, not the malicious terminal host buried at the center. Reputation lookups return "trusted" at every layer. The threat rides inside its own protection.

Embedded in the query string of the innermost wrappers was a recipient tracking parameter, an encoded target address, alongside session identifiers. That is the attacker confirming exactly who opened what, turning a scanning artifact into reconnaissance.

The terminal host is an old domain (registered in the late 1990s) sitting behind a content delivery network. On passive inspection it returned benign, blog-style HTML with no visible credential form. That is normal for this class of attack. Content is served conditionally, so a scanner fetching the page sees something harmless while a human arriving with the right token and referrer gets the harvesting page. The 90-plus percent of phishing that begins with a link, per the gateway telemetry in the 2024 Microsoft Digital Defense Report, depends on precisely this gap between what a scanner sees and what a victim sees.

Authentication was never the weak point

The reflex is to blame the filters for letting an unauthenticated message through. They did not. The message authenticated cleanly.

It was sent through Amazon SES. The sending domain, the SES infrastructure, and a Microsoft tenant all applied valid DKIM signatures, SPF passed, and SRS rewriting kept the bounce path aligned as the message was forwarded. DMARC evaluated to a pass. Every authentication check a gateway runs returned green.

None of that says anything about intent. Attackers use commercial senders like SES precisely because the reputation and the cryptographic signing come included. Authentication confirms the path is technically valid. It does not confirm the content is safe, and treating a pass as a safety verdict is how a first-time sender with a privacy-shielded domain walks a credential-harvest link into an inbox. This is the same laundering-through-legitimate-infrastructure pattern behind the credential abuse that the 2024 IBM Cost of a Data Breach report ties to some of the most expensive and slowest-to-contain breaches on record.

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

What actually flagged it

No single reputation check caught this, because there was no single indicator to catch. The sending path was clean. Every URL in the chain belonged to a trusted vendor. The visible text was fractured into non-words.

What caught it was the combination, scored together rather than one signal at a time. A first-time sender. A header brand that did not match the footer brand. Display text broken by zero-width characters. A financial-urgency pretext to a mailbox with no prior relationship to the sender. Recipient tracking parameters riding inside a security wrapper. Individually, each is weak. Together they describe an attack.

That is where Themis, the IRONSCALES agentic AI, scored the message. It classified the email as credential theft on behavioral signals and the community reputation of similar reports, and the message was resolved as phishing rather than acted on by the recipient. The gateways in the chain evaluated the link. Behavioral AI evaluated the behavior. Only the second approach had anything to work with here.

Fixing the trust-the-upstream-verdict gap

Two takeaways for anyone running layered email defense.

Stop treating a rewritten link as a scanned link. When a wrapper domain belongs to another security vendor, most stacks assume the upstream already did the work and pass it through. Chained deployments turn that courtesy into a blind spot. Detection has to unwrap the full chain and evaluate the terminal host and its behavior, not the reputation of the nearest wrapper. This is the core argument for augmenting the gateway with a layer that reasons about the whole message rather than trusting a prior verdict.

Score behavior, not reputation. Zero-width obfuscation, brand collisions, and conditional payload hosting are built specifically to defeat static and reputation-based checks. The CISA phishing guidance for network defenders makes the same point: layered technical controls have to assume some phishing will pass the perimeter, and the defensive weight belongs on detecting the attempt in context. Techniques like link-based spearphishing (MITRE T1566.002) paired with masquerading (MITRE T1036) are engineered to survive exactly the reputation checks these stacks depend on. Behavioral models, informed by credential-harvesting patterns seen across a global community, catch the intent the wrappers launder away.

Five vendors rewrote this link. The message still reached the inbox. The lesson is not that URL rewriting is useless. It is that rewriting is not the same as verifying, and a stack that trusts the wrapper upstream of it will keep passing threats along, politely, one hop at a time.

Indicators of Compromise