Hiding Inside the Security Stack: How a Redirect Chain Used Trusted URL-Rewriters to Deliver a Throwaway Domain

The email arrived at a wire-and-cable manufacturer carrying the company's own branding, an Alan Wire header, a "View Document" button, and a footer. Every authentication signal was green: SPF passed, DKIM passed (for both the sending domain and Amazon SES), DMARC passed, compauth passed reason=100. Microsoft Exchange Online scored it SCL:1, essentially trusted. The recipient saw a message that looked like it came from inside their vendor ecosystem.

The actual sender was Admin@apl[.]com[.]sa, routed through Amazon SES out of us-west-2. The "View Document" button went nowhere near alanwire.com.

The Redirect Chain as Attack Infrastructure

The CTA visible in the email displayed an alanwire.com anchor text. Underneath it was a three-hop redirect chain:

1. hxxps://linklock[.]titanhq[.]com/analyse?data=[encoded payload] (TitanHQ Link Lock, a security URL-rewriting product used by enterprise email gateways)
2. hxxps://url-shield[.]securence[.]com/?...&u=https[:]//q[.]fezpfsj[.]com/docs/index[.]html (Securence url-shield, another security URL-rewriting product)
3. hxxps://q[.]fezpfsj[.]com/docs/index[.]html (a domain registered April 18, 2026, via IONOS, privacy-protected, with no discernible connection to Alan Wire or any legitimate business)

Both Link Lock and url-shield are real security vendor products. They rewrite URLs so that every click is routed through their scanning infrastructure, which is exactly the layer enterprises trust to catch malicious links. When these products appear in a redirect chain, security analysts and mail gateway logs register the rewriters as the link destination, not the terminal hop. If the terminal domain was clean at scan time (a domain registered weeks prior with no reputation), the chain passes.

This maps to MITRE ATT&CK T1566.002 (spearphishing link), T1656 (impersonation of Alan Wire), T1583.001 (attackers acquiring a newly registered domain for the campaign infrastructure), and T1102 (web service abuse, specifically exploiting legitimate URL-rewriting services as camouflage).

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

Amazon SES and the Authentication Laundering Problem

Amazon SES is a legitimate bulk email infrastructure provider. When a message transits SES, it acquires SES's own DKIM signature (d=amazonses.com) in addition to any DKIM signed by the configured sending domain (d=apl[.]com[.]sa in this case). SPF passes against SES's outbound IP range. DMARC evaluates against apl[.]com[.]sa, which has a configured DMARC record that passes.

The problem is that none of this tells you anything about whether apl[.]com[.]sa has any relationship with Alan Wire. Amazon SES will send mail for any verified sender domain, legitimate or attacker-controlled. The authentication stack confirms that the mail came from a real Amazon SES account configured for apl[.]com[.]sa. It says nothing about whether that account belongs to Alan Wire, a wire manufacturer, or someone with access to a Saudi Arabian domain registration.

The Verizon 2026 Data Breach Investigations Report notes that phishing accounts for 16% of initial access in breaches, with credential harvesting appearing in 39% of incidents across the kill chain. SES-enabled campaigns that pass all authentication checks contribute directly to that statistic because gateway filters that rely on authentication results pass them without escalation.

The Stitched Template Problem

The footer of this email contained NMLS IDs #1445910 and #1937133, along with a mailto contact at fortunato@carpenterhomeloans[.]com. NMLS identifiers are mortgage licensing numbers. Carpenter Home Loans is a mortgage company. Neither has any connection to Alan Wire or to wire and cable manufacturing.

This is a stitched template: a footer from one campaign or template library grafted onto branding from another. It happens when attackers reuse phishing kit components without scrubbing them. For a human reviewer, it is immediately disqualifying. For a filter evaluating individual signals in isolation, NMLS IDs and a mortgage company email address in a footer are not inherently malicious.

The Microsoft Digital Defense Report 2024 emphasizes that modern phishing campaigns increasingly exploit trusted cloud infrastructure to achieve authentication pass rates. SES plus legitimate URL-rewriters is precisely that pattern. The FBI IC3 2024 Annual Report documents credential-harvesting losses in the billions across business email contexts. The NMLS mismatch is the kind of contextual anomaly that human-in-the-loop review catches and automated signal-matching misses.

What Broke the Chain

IRONSCALES Adaptive AI identified this as a credential-theft attempt with 88% confidence. Themis, the agentic AI layer within the IRONSCALES platform, flagged the link chain specifically: the "View Document" display text anchored to a Link Lock URL whose decoded payload resolved through url-shield to a newly registered, privacy-protected domain. The community reputation signal indicated similar redirect-chain patterns had been reported across the IRONSCALES-protected organization base.

The five affected mailboxes at Alan Wire received variants of this email with individualized reference numbers in the subject line (RE: Re: Ref#: [unique hash]), suggesting this was a targeted wave against a specific organization, not indiscriminate bulk phishing. All five were automatically resolved as phishing and mitigated.

The IRONSCALES advanced URL and malware protection capability follows redirect chains to terminal destinations and scores the final URL independently of the intermediary reputation. That distinction matters: a chain that passes through two legitimate security vendors is not a clean chain if the terminal hop is a weeks-old throwaway domain. The IBM Cost of a Data Breach 2024 puts the average breach cost at $4.88 million. A credential-harvest campaign that bypasses gateway filtering through relay-chain abuse is one click away from that number.

Defanged IOC Table

A redirect chain that begins at a real security vendor's domain and ends at a newly registered throwaway is not a safe chain. The last hop is the only one that matters, and it was registered seven weeks before delivery.