The Phishing Link That Passed Two Security Scanners

The credential-harvesting page sat four hops deep, behind two of the more trusted names in email security. To reach it, a single link first passed through one click-protection rewriter, then a second, then a throwaway domain, and finally landed on a live login form hosted inside a legitimate mortgage-application platform. At every hop, the visible destination was a domain that any URL scanner would wave through.

That was the point.

The lure was mundane. An automated e-signature notification told a senior finance executive at a marine and recreational manufacturing company that a document was waiting for review. Tasks pending. One agreement to sign. A blue Login and complete tasks button. Nothing about it looked like the opening move of a credential-theft attempt.

This is what reputation-based URL defense looks like when it fails quietly. Reputation checks ask one question: is this destination a domain we trust? When the destination is a security vendor's own click-protection rewriter, the answer is yes, every single time. The attacker did not defeat the scanners. They borrowed the scanners' credibility.

The E-Signature Task That Never Existed

The message arrived from Admin@sch.sisconthosting[.]com, delivered through Amazon Simple Email Service. On paper the authentication was spotless. SPF passed. DKIM passed, and not on one domain but two. DMARC returned a best-guess pass, composite authentication passed, and the message landed with a spam confidence level of 1, meaning the receiving mail platform treated it as effectively clean. It was a first-time sender to this organization.

The body read like a helpdesk auto-reply. "Tasks Pending For Ticket #16844032." A note that an NDA agreement was outstanding. A signature block that claimed to be an HR department, with the manufacturer's brand pasted on top.

Except the sending domain, sch.sisconthosting[.]com, has nothing to do with the manufacturer whose name appeared in the signature. That mismatch, an authenticated sending domain that does not match the claimed brand, is the whole trick behind this class of attack. The mail was genuinely signed and genuinely sent. It was just sent by someone else entirely.

The kit was sloppy in ways worth noting. Unrendered template placeholders like {fulldomain} were visible in the message. Two different mortgage-license numbers appeared in the same email, 1445910 in one block and 1937133 in another. Sloppiness like this is a tell, but it is not a tell that a reputation scanner is built to read.

Two Rewriters, Stacked

Here is the redirect chain, unwound one layer at a time.

The Login and complete tasks button pointed to a link on url-shield.securence[.]com, a legitimate click-time URL-protection service. That link carried a u= parameter whose value was another wrapped link, this one on url.avanan[.]click, the click-protection rewriter from a well-known email-security vendor. That second wrapper in turn pointed to kia-door[.]com/docsxx/index.html, a throwaway domain, which redirected to the real prize: a credential-collection login form at 1937133.my1003app[.]com, hosted on a legitimate mortgage-application software platform and dressed in the branding of a real loan-application portal.

Four hops. Two of them were security-vendor rewriters stacked one inside the other. And in the incident record, every one of those wrapped links carried the same verdict: clean.

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

Why Reputation Gave Every Hop a Pass

A URL-reputation engine evaluates the domain it can see. Feed it a url-shield.securence[.]com address and it checks the reputation of Securence, a trusted email-security provider, and passes. It never resolves the nested u= parameter to discover that the wrapped destination is itself another wrapper, let alone that the terminal page is a login form. Each scanner in the chain sees only the next trusted host.

The final destination did not help the defender either. my1003app[.]com is real software with a valid certificate and clean reputation. Attackers host credential forms on legitimate software-as-a-service platforms precisely because the hosting domain launders the page's trustworthiness. This is the same abuse pattern seen when phishing runs through ESP redirect services or cloud page hosts. The infrastructure is legitimate. The context is not.

Put the two techniques together and you get a link that is, hop by hop, indistinguishable from a benign one. The attacker built a chain where the honest answer to "do you trust this domain?" was always yes.

The Tell the Scanners Could Not See

What flagged the message was behavior, not reputation. Themis, the IRONSCALES Adaptive AI virtual analyst, assigned a 90 percent phishing confidence and labeled the incident Credential Theft and VIP Recipient. The signals it weighed were the ones no URL check could reach: a first-time sender, a sending domain that did not match the brand in the body, a credential-collection form reached through layered redirects, and a high-value finance target being asked to log in.

One detail stands out. The outer Securence wrapper still carried a recipient parameter belonging to a victim at a completely different organization, a law firm. A rewriter wrapper is generated for a specific recipient at click time. Finding one addressed to someone else means the link was harvested from a prior campaign and replayed here, not freshly minted for this target. That is a behavioral fingerprint of reuse, and it is exactly the kind of signal that lives in message context rather than domain reputation.

The Adaptive AI behavioral engine treats the sender, the intent, and the relationship history as the primary evidence. The wrapped URLs were almost beside the point.

Indicators of Compromise

Mapping to MITRE ATT&CK

The attack maps cleanly to T1566.002, Spearphishing Link. The distinguishing feature is not the link itself but its packaging: nesting the malicious destination inside trusted click-protection rewriters to defeat reputation-based inspection while the message body carries a credential-collection pretext.

What to Change Before the Next Wrapper Chain

Stop treating rewriter domains as trusted terminals. A link on a security vendor's wrapper domain is not a verdict, it is an unopened envelope. Inspection has to follow the chain to its terminal destination and detonate the final page, not stop at the first recognizable host.

Weight sender behavior over URL reputation. The 2024 Verizon Data Breach Investigations Report found stolen credentials involved in 38 percent of breaches, with lures built around a login prompt rather than malware doing much of the work. IBM's 2024 Cost of a Data Breach report puts stolen or compromised credentials among the costliest initial vectors, and the FBI's 2023 Internet Crime Report tallies billions in losses to email-driven fraud. The common thread is that the payoff is a login, not an executable, and logins do not trip malware sandboxes.

Layer detection so that a clean URL verdict is one input, never the decision. This is where credential-harvesting protection that reads intent and context, combined with gateway augmentation that catches what reputation-based filtering waves through, closes the gap. CISA's phishing guidance for network defenders reaches the same conclusion: technical controls have to assume that some well-crafted lures will pass authentication and reputation checks, and defense in depth is the answer.

The scanners were not broken here. They answered the question they were asked. The lesson is to ask a better one.