The Security Vendor's Scanner That Became the Phishing Lure

The email looked like a Microsoft encrypted message notification. Office 365 header bar, lock icon, a single blue button. Below the button: a note explaining that a colleague had shared protected retirement plan data, courtesy of something called JULY Services, along with a link to the JULY Secure Email Guide. Clean, professional, plausible.

The "Read the message" button pointed to linklock.titanhq.com.

TitanHQ LinkLock is a real product. It's a commercial link-scanning service that email security vendors use to wrap outbound URLs and scan them at click time. When a recipient sees linklock.titanhq.com in a hover preview, the reasonable assumption is that someone's security stack is on the job. That assumption is exactly what this attacker was counting on.

According to the Verizon 2024 Data Breach Investigations Report, phishing remains the dominant delivery method for credential theft, with attackers increasingly routing attacks through trusted infrastructure specifically to defeat scanning controls. Borrowing the reputation of a legitimate security vendor's domain takes that pattern to its logical extreme.

The scan runs. The scan shows clean. The redirect fires. The victim lands on a malware-flagged domain with an invalid TLS certificate. By then, every security tool in the chain has already had its verdict laundered.

How Three Security-Adjacent URLs Wrapped One Malicious Domain

The redirect chain in this email had three layers before reaching the final destination.

Layer one was the TitanHQ LinkLock URL. This is the href value the recipient sees directly in the email. The LinkLock service is designed to intercept link clicks, scan the destination, and either pass through or block. Here, it wrapped a Cisco Secure Email URL.

Layer two was a Cisco Secure Email rewritten link (secure-web.cisco.com). Cisco's Secure Email product rewrites links in transit, inserting its own scanning infrastructure. This is also a legitimate security feature. The Cisco URL encoded the final destination in its own query string.

Layer three, buried inside the Cisco wrapper, was https://shoppingtrends.in. That domain was blocked as malware by at least one security gateway at scan time, returned an SSL/TLS hostname mismatch (the certificate was not valid for shoppingtrends.in), and resolved to a hosting IP in Germany (45.133.74.62) inconsistent with its Cloudflare nameservers.

The net effect: a link that, at first glance, pointed to a trusted commercial security scanner, which pointed to a trusted enterprise security vendor's infrastructure, which pointed to a malicious site. Automated scanners that stop at the first or second hop issue a clean verdict and move on.

The technique maps to MITRE ATT&CK T1566.002 (Spearphishing Link) and T1027 (Obfuscated Files or Information), where the obfuscation layer is not code but infrastructure reputation.

The Envelope Was Spotless

Making this harder to catch: the email passed every authentication check. The Microsoft Digital Defense Report 2024 specifically flags the growing use of legitimate cloud sending infrastructure by attackers as one reason authentication-based filtering is losing effectiveness as a standalone control.

The message came from noreply0@openservices.com.mx, sent via Amazon SES out of the eu-west-1 region (IP 54.240.7.44). SPF passed because SES is a permitted sender for that domain. DKIM passed with valid signatures for both openservices.com.mx and amazonses.com. DMARC passed.

Microsoft's filtering stack scored it at SCL:1 (not spam). CompAuth passed with reason code 100.

From a header forensics standpoint, this email looked identical to legitimate transactional mail. The attacker controlled the sending domain, set up the DNS records, and used a reputable commercial sending platform. That combination defeats signature-based and reputation-based filtering at the envelope level entirely.

The mismatch lived in the content and the link chain: the sender domain had nothing to do with Microsoft, JULY Services, or ProdigyNSI. A colleague named "Alex Schneider" purportedly sent a protected message about retirement plan data, but the actual From address was a first-time sender at an unrelated Mexican domain. None of that shows up in an authentication result.

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

What IRONSCALES Resolved That the Chain Could Not

The key problem with relay-chain attacks is that each scanning layer tends to evaluate only its own hop. LinkLock scans what Cisco gives it. Cisco scans what it received from the email. Neither necessarily traces the full chain to ground.

IRONSCALES resolved the full redirect chain to the terminal domain and evaluated it directly. The findings at shoppingtrends.in were unambiguous: malware block from an independent security gateway, TLS certificate that did not match the domain name, DNS/hosting indicators that pointed to infrastructure inconsistent with a legitimate business, and zero content relationship to the claimed brands in the email body.

That verdict, combined with behavioral signals, a first-time sender flag, brand mismatches across three different named entities (Microsoft, JULY Services, ProdigyNSI), and the community reputation of similar incident patterns, drove a 90% confidence phishing classification.

The message was quarantined across three affected mailboxes within minutes of delivery. No user interaction occurred.

Indicators of Compromise

What This Means for Teams Relying on Link Scanning

The FBI IC3 2024 Internet Crime Report recorded over $2.9 billion in BEC and credential theft losses, a figure that reflects how often legitimate-looking emails succeed precisely because detection stops at the envelope. The CISA cybersecurity advisories on phishing persistently note that link-scanning evasion through multi-hop redirect chains is among the most difficult detection problems for perimeter-based tools.

The uncomfortable implication of this attack is that the security tooling itself became an ingredient in the deception. This is not a flaw in TitanHQ or Cisco's products. Both services do what they are designed to do. The problem is that their domain reputation becomes a trust signal that attackers can borrow.

Any link scanner that resolves a chain one hop at a time and sees a known security vendor URL can issue a clean verdict without ever reaching the payload. That gap is intentional and exploitable.

Teams defending against this pattern need a few things in place. Full-chain URL resolution matters: the verdict has to be based on the terminal domain, not an intermediate hop. Contextual coherence analysis catches what authentication cannot: the sender domain, the claimed brand, the recipient's relationship to the named party, and the final destination domain should all tell a consistent story. When they do not, that mismatch is signal.

Authenticated, multi-hop, multi-brand phishing like this is why link scanning alone is not a sufficient detection layer. The credential harvesting protection problem has moved past "is the link safe" and into "does this entire email make sense."