Table of Contents
The "Read the message" button sat behind two security vendor URL scanners. TitanHQ LinkLock wrapped the outer layer. Cisco Secure Web handled the middle. Both returned clean verdicts.
The final destination, a domain called shoppingtrends.in, was flagged as malware by at least one security gateway and served an invalid TLS certificate. None of that mattered. By the time the link reached an inbox at a North American technology services firm, it looked like it had been pre-screened twice by tools the recipient's organization already trusted.
This is what trust laundering looks like when attackers stop using one vendor as a shield and start stacking two.
The Four-Identity Problem
The email presented itself as a Microsoft Office 365 encrypted message notification. The body text referenced "JULY" (a secure email service) and claimed to protect "retirement plan data." The purported sender was "Alex Schneider" with an email address at prodigynsi.com. The actual From header read noreply0@openservices.com.mx, a Mexican domain registered through Akky Online Solutions with WHOIS data almost entirely redacted.
That is four distinct brand identities in a single email: Microsoft, JULY, ProdigyNSI, and openservices.com.mx. No legitimate encrypted message notification involves four unrelated organizations.
The Verizon 2024 Data Breach Investigations Report found that phishing remains the initial access vector in 36% of breaches. Attacks like this one show why: the social engineering is not in the message content (which was generic). It is in the infrastructure layering that makes the delivery mechanism look credible.
How the Redirect Chain Weaponized Two Scanners
The single call-to-action button ("Read the message") linked to a URL that decoded into three distinct hops:
Hop 1: TitanHQ LinkLock (linklock.titanhq[.]com/analyse?...). This is a legitimate link protection service used by organizations to scan URLs before users reach them. The attacker encoded the next hop inside TitanHQ's analysis parameter.
Hop 2: Cisco Secure Web (secure-web.cisco[.]com/...). Cisco's URL scanning proxy received the request from TitanHQ and evaluated the encoded destination. It returned a clean verdict. The IRONSCALES link scanner also recorded this hop as "Clean" status.
Hop 3: shoppingtrends.in. The actual payload destination. DNS resolved to 45[.]133[.]74[.]62 (hosted in Germany). A security gateway blocked the domain with a "Malware Detected!" interstitial. The TLS certificate did not match the domain name. WHOIS data was unavailable.
The attacker understood something important: security tools that evaluate URLs often check the first hop, not the final destination. When the first hop is a security vendor's own domain, the check stops there. Two vendor wrappers created what looked like a double validation. In reality, neither vendor caught what was at the end of the chain.
According to MITRE ATT&CK T1566.002 (Phishing: Spearphishing Link), this technique exploits the gap between URL reputation at time-of-click and actual destination resolution. The Microsoft Digital Defense Report 2024 documents a 146% year-over-year increase in adversary-in-the-middle phishing, much of it relying on redirect chains through trusted infrastructure.
See Your Risk: Calculate how many threats your SEG is missing
Authentication Passed. Every Single Check.
The email was sent through Amazon SES (a7-44.smtp-out.eu-west-1.amazonses.com). SPF passed for the SES sending IP. DKIM signatures validated for both openservices.com.mx and amazonses.com. DMARC passed with compauth=pass reason=100, which is Microsoft's highest confidence score.
This is the authentication paradox that the FBI IC3 2024 Report highlights when documenting $2.9 billion in BEC losses: authentication protocols prove that an email was sent from the infrastructure it claims. They do not prove the sender is who they claim to be, and they certainly do not prove the content is safe.
The attacker registered (or compromised) openservices.com.mx, configured proper DKIM signing through Amazon SES, and achieved full authentication. The entire sending chain was technically legitimate. Microsoft's own anti-spam filters assigned an SCL score of 1 (low confidence spam), which means the message reached the inbox without intervention.
The Behavioral Signals That URL Scanning Missed
IRONSCALES Themis flagged this email at 90% confidence and automatically quarantined it across three affected mailboxes within minutes of delivery. The detection was not based on URL reputation (which returned clean for the vendor-wrapped hops). It was based on behavioral analysis.
Three signals converged. First, the sender had never contacted this organization before. First-time sender from an unfamiliar domain, sending what claims to be an encrypted message about retirement plan data, is a high-risk combination. Second, the brand mismatch across four identities (Microsoft template, JULY body text, ProdigyNSI claimed sender, openservices.com.mx actual sender) triggered social engineering pattern detection. Third, community intelligence from the IRONSCALES network of 35,000+ security professionals had already flagged similar campaigns using the same infrastructure pattern.
The gap here is structural. URL scanning evaluates links. Behavioral analysis evaluates context. When the links are designed to look clean (wrapped in vendor scanners that return clean verdicts), only behavioral signals catch what is actually happening.
Indicators of Compromise
| Type | Indicator | Context |
|---|---|---|
| Sender Email | noreply0@openservices[.]com[.]mx | Phishing sender, authenticated via Amazon SES |
| Sending IP | 54[.]240[.]7[.]44 | Amazon SES eu-west-1 relay |
| Domain | openservices[.]com[.]mx | Sender domain, DKIM-signed, Mexican registrar (Akky) |
| URL (Hop 1) | linklock[.]titanhq[.]com/analyse?... | TitanHQ LinkLock wrapper (legitimate service, abused) |
| URL (Hop 2) | secure-web[.]cisco[.]com/... | Cisco Secure Web wrapper (legitimate service, abused) |
| URL (Hop 3) | hxxps://shoppingtrends[.]in/ | Final malicious destination, malware-flagged |
| IP | 45[.]133[.]74[.]62 | Hosting IP for shoppingtrends.in (Germany) |
| Claimed Sender | aslavik@prodigynsi[.]com | Display name: "Alex Schneider," used in body text |
Why "Pre-Screened" Does Not Mean Safe
This attack exploits a specific mental model: if a security vendor's scanner touched the link, the link must be safe. That assumption breaks when attackers control what the scanner evaluates versus what the user ultimately reaches.
For security teams dealing with URL-wrapped phishing, three actions matter.
Resolve the full redirect chain. Do not trust the first hop. Sandbox the final destination independently of any vendor wrapper. CISA's advisory guidance on link analysis recommends evaluating the terminal URL, not intermediate proxies.
Treat brand mismatch as a high-confidence signal. Four unrelated organizations in a single email is not normal. Behavioral detection that flags identity fragmentation across From, display name, body branding, and reply-to address catches what authentication cannot.
Do not rely on authentication as a trust decision. SPF, DKIM, and DMARC are necessary infrastructure. They are not phishing detection. This email passed every authentication check because the attacker set up the infrastructure correctly. The content was still malicious.
The IBM 2024 Cost of a Data Breach Report puts the average cost of a phishing-initiated breach at $4.88 million. When two security vendors scan a link and both say "clean," the cost of trusting that verdict is measured in the gap between what the scanner saw and what the user reached.
Explore More Articles
Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.