Two Security Vendors Scanned This Link and Both Said Clean

The "Read the message" button had a TitanHQ link wrapper on it. That wrapper pointed to a Cisco secure-web URL. The Cisco URL pointed to shoppingtrends.in, a domain hosting a malware payload with a broken TLS certificate.

Both TitanHQ and Cisco scanned the link. Both returned Clean.

That is not a failure of the individual products. It is a deliberate architectural exploit. Stack two competing security vendor wrappers on the same URL, and each one evaluates the other vendor's infrastructure instead of the final destination. The malicious payload sits one more hop past where either scanner looks.

The Lure: Microsoft Encryption, JULY Branding, One Button

The email arrived on March 30, 2026 at 21:37 UTC. No subject line. The visible From name was "Sarah Hamilton," sending from noreply0@openservices[.]com[.]mx via Amazon SES (eu-west-1). SPF, DKIM, and DMARC all passed cleanly.

The body was a standard Office 365 encrypted message notification template: Microsoft blue header, padlock icon pulled directly from outlook.office365.com, footer links pointing to legitimate Microsoft privacy pages. One call-to-action button in the center labeled "Read the message."

The text block below the button said "Alex Schneider" had sent a protected message, and that "JULY has sent you an encrypted email" to protect retirement plan data. The JULY Secure Email Guide reference pointed to julyservices[.]com. JULY is a real retirement services company. The Microsoft template visuals are real. The padlock image is real. The footer links are real.

The attacker's contribution was the container holding those components and the button in the middle. Borrow visuals from two trusted brands, insert the payload, send via infrastructure that passes email authentication, and let pattern recognition do the rest.

The Link Chain: TitanHQ Wrapping Cisco Wrapping Malware

The CTA button href, extracted from the raw HTML:

`` hxxps://linklock.titanhq[.]com/analyse?url=hxxps%3A%2F%2Fsecure-web.cisco[.]com%2F...%2Fhxxps%253A%252F%252Fshoppingtrends[.]in&data=... ``

Decoded, the chain is:

1. linklock.titanhq[.]com/analyse (TitanHQ's link analysis and rewriting endpoint)
2. secure-web.cisco[.]com/... (Cisco's URL scanning and rewriting service)
3. hxxps://shoppingtrends[.]in (the final payload destination)

TitanHQ's scanner evaluated the link at the linklock.titanhq.com layer. What it found at the end of that URL was a Cisco secure-web.cisco.com address. Cisco's infrastructure. Clean.

Cisco's scanner evaluated the link at the secure-web.cisco.com layer. What it found, depending on when the scan ran and how deeply it unpacked the double-URL-encoding, was TitanHQ-adjacent infrastructure or the final domain. The verdict returned: Clean.

Neither scanner produced a definitive examination of shoppingtrends.in. A third-party security gateway that did look directly at the final domain returned something very different: a "Malware Detected!" block page. Direct HTTPS access produced a TLS hostname verification error. The SSL certificate was not valid for shoppingtrends.in. The A record resolved to 45.133.74.62, hosting in Germany. Cloudflare nameservers but non-matching PTR records.

The domain was not benign infrastructure that happened to have a configuration issue. It was a purpose-built phishing endpoint with enough technical roughness to confirm the attacker was not interested in long-term operation.

Why This Works Against URL Reputation Systems

URL reputation and link scanning systems operate on a model: examine what is at the destination, compare it against known-bad databases and behavioral signals, return a verdict. That model assumes you can reach the actual destination.

When the destination is two hops of competing vendor infrastructure deep, the probability that any single scanner reaches the payload drops significantly. Two factors work in the attacker's favor here:

Double-URL-encoding. The final shoppingtrends.in URL is encoded twice (%2525 notation). A scanner that does not recursively decode the full chain stops at Cisco's domain and sees only clean infrastructure.

Vendor trust short-circuiting. Scanners commonly stop analysis when they encounter another known security vendor's domain in the redirect chain. Cisco's infrastructure is not a threat. TitanHQ's infrastructure is not a threat. The scanner marks the hop clean and moves on, never reaching the payload.

Three mailboxes received the email before Themis identified it as phishing. All three were quarantined.

See how many phishing emails are getting through your filters.

What Broke the Attack: Behavioral Context, Not Link Scanning

Themis flagged this at 90% confidence and auto-resolved it without manual SOC intervention. The signals were behavioral, not link scan results:

• First-time sender. noreply0@openservices[.]com[.]mx had never sent to this organization before.
• Multi-brand impersonation. Microsoft template visuals plus JULY retirement branding from a domain at neither organization is structurally anomalous.
• VIP recipient flag. The targeted mailbox carried a VIP designation, elevating scrutiny automatically.
• Community intelligence. Cross-tenant signals from the IRONSCALES platform matched the structural fingerprint of this campaign.
• Final domain reputation. Themis unpacked the full redirect chain. shoppingtrends.in returned the malware block page and TLS mismatch consistent with attacker-controlled infrastructure.

TitanHQ and Cisco said Clean. The behavioral envelope said otherwise.

Defending Against Stacked Wrapper Attacks

URL wrappers from legitimate security vendors are not a trust guarantee. They are a scanning attempt, subject to the limitations of what the scanner can see at the moment it scans. Teams configuring detection policy need to account for the gap between "a vendor wrapped this" and "this destination is safe."

Specific posture recommendations:

1. Configure recursive URL unwrapping. Security platforms should follow multi-hop redirect chains and double-encoded URLs all the way to the final destination. Stopping at the first trusted-domain hop is exactly where this attack wins.

1. Apply time-of-click scanning. Static scan-at-delivery misses domains that activate post-delivery or return different content to scanner IPs. Evaluating the destination when the user actually clicks closes that gap.

1. Flag multi-vendor wrapper stacking as an anomaly. Legitimate email does not chain one security vendor's URL wrapper inside another vendor's wrapper. That construction pattern, combined with a first-time sender, warrants automatic escalation. And do not exempt Cisco or TitanHQ URLs from analysis just because they belong to known security vendors. The wrapper validates that the vendor touched the URL. It says nothing about the destination.

1. Layer behavioral signals over link verdicts. First-time sender, multi-brand impersonation, VIP recipient flag, and cross-tenant community intelligence caught what two purpose-built link scanners missed. Link scanning is one input. It cannot be the only one.

The IRONSCALES detection model combines behavioral signals with technical indicators. Here, that combination produced an auto-resolution before any of the three affected mailboxes clicked through.

Indicators of Compromise

MITRE ATT&CK: T1566.002 Spearphishing Link, T1036 Masquerading, T1027 Obfuscated Files or Information

Sources: IRONSCALES platform analysis; Verizon 2025 DBIR (phishing primary initial access vector); Microsoft Digital Defense Report 2024 (trusted intermediary abuse increasing); CISA Phishing Guidance SC3; MITRE ATT&CK T1566; IBM X-Force Threat Intelligence Index 2024 (phishing accounts for 41% of initial access vectors)