The Security Tools That Became the Camouflage

The "Read the message" button looked exactly like what it claimed to be: a Microsoft encrypted message notification, complete with the blue Office 365 header bar and a padlock icon. Below it, a note about protecting retirement plan data from a financial services provider. Familiar, institutional, trustworthy.

The link behind that button ran through two security vendors before it reached its actual destination.

That's the move this attack was built around. Not impersonating Microsoft. Not faking a Cisco URL. Using them. Routing a malware payload through legitimate defensive infrastructure so that every scanner evaluating the link saw a known-good vendor domain, not the .in address waiting at the end of the chain.

Authentication Passed. That Was the Point.

The email arrived from noreply0@openservices[.]com[.]mx, sent via Amazon SES out of the EU-West-1 region. SPF passed. DKIM passed for both openservices[.]com[.]mx and amazonses[.]com. DMARC passed. Microsoft's compound authentication (compauth) returned clean at reason code 100.

This is not a coincidence. Amazon SES is a legitimate commercial email delivery service, and attackers register sending domains specifically to obtain valid DKIM signatures and DMARC alignment. The openservices[.]com[.]mx domain is registered through a Mexican registrar (AKKY ONLINE SOLUTIONS), expires in October 2026, and has no public registrant information. It's a domain acquired specifically for this campaign, set up just long enough to authenticate.

Authentication tells you the message came from where it claimed. It tells you nothing about what the message wants you to do.

According to the Verizon 2024 Data Breach Investigations Report, the human element is involved in 68% of breaches. Attackers building on authenticated infrastructure know they're aiming at that element directly. The inbox filter is already neutralized. What remains is the person making the decision to click.

Two Vendor Wrappers, One Malware Domain

The CTA in the email body decoded to this redirect chain:

1. hxxps://linklock[.]titanhq[.]com/analyse?url=...&data=... (TitanHQ link-lock analysis service)
2. hxxps://secure-web[.]cisco[.]com/1NpS8r5wPus779... (Cisco secure-web URL rewrite)
3. Final destination: hxxps://shoppingtrends[.]in/

TitanHQ's link-lock service is a legitimate threat in email security tooling: it intercepts links, rewrites them, and sends users through a scanning proxy before delivery. Cisco's secure-web URL format serves a similar function. Both are designed to protect users. Here, both are being used as obfuscation layers.

A URL reputation scanner evaluating the CTA sees a titanhq.com domain, which is a known, reputable security vendor. It may follow one redirect hop and see a cisco.com domain (also clean). The final payload URL encoded inside the Cisco wrapper is never evaluated. The scanner stops at the outermost legitimate layer.

See Your Risk: Calculate how many threats your SEG is missing with the IRONSCALES SEG calculator

The final destination, shoppingtrends[.]in, tells a different story. At least one security gateway blocked it with a "Malware Detected!" block page. Direct HTTPS access returned an SSL/TLS hostname verification error. The certificate is not valid for that domain. The domain resolves to 45[.]133[.]74[.]62, hosted in Germany, with Cloudflare nameservers that don't match the A record hosting. WHOIS data returned nothing.

This is not a misconfigured legitimate site. It's a purpose-built domain with a freshly-broken TLS certificate, blocked by malware detection on access.

The Branding Layer

The email body layered two brand identities over each other. The visual framework was Microsoft: the #155C9E blue header bar, the Office 365 padlock image hosted at outlook.office365.com, the Segoe UI font stack, and footer links pointing to microsoft.com privacy and support pages.

Embedded in that Microsoft frame was content attributed to a financial services provider ("JULY"), referencing retirement plan data and pointing readers to www.julyservices[.]com for a secure email guide.

The sender, meanwhile, was noreply0@openservices[.]com[.]mx, with a display name of "Sarah Hamilton". Unconnected to either brand.

This is not accidental confusion. The layering is deliberate. Microsoft's visual authority reduces suspicion. The retirement plan reference creates urgency (sensitive financial data, a protected message waiting). The financial services brand provides a plausible reason for the email to exist. None of it connects to the sender domain, but recipients rarely check that alignment.

The MITRE ATT&CK technique here is Masquerading (T1036) compounded with Obfuscated Files or Information (T1027): the attack presents itself as something recognizable and trusted while concealing the actual payload chain inside vendor infrastructure.

IOCs

What Caught It When the Chain Didn't

Themis reached a 90% phishing confidence score and quarantined the message across three mailboxes before any user interaction. The signals weren't in the link's outermost layer. They were in everything around it.

The sender had never contacted this organization before (first-time sender). The visible branding had no relationship to the sending domain. The community signal was clear: similar redirect chains using TitanHQ and Cisco wrappers had already been reported and resolved as phishing across the IRONSCALES customer base. And the recipient was flagged as a VIP, triggering additional scrutiny on an already suspicious message.

This is what behavioral and community-driven detection provides that URL reputation alone cannot: context. A clean outer wrapper only looks clean to a scanner evaluating links in isolation. When you add behavioral history, sender reputation, first-time sender risk, and cross-organization threat intelligence, the picture looks entirely different.

The IBM 2024 Cost of a Data Breach Report puts the average breach cost at $4.88 million. The IRONSCALES platform draws on real-time feedback from a global community of over 35,000 security professionals across 3,000 MSPs. When a redirect chain like this one surfaces in one organization's inbox, it surfaces against a backdrop of everything that community has already seen.

What Defenders Should Do With This

The exploit here is not a technical vulnerability in TitanHQ or Cisco. Both tools work as designed. The problem is that their trustworthiness is being borrowed. A redirect through a legitimate vendor URL carries the implied reputation of that vendor.

A few concrete steps that address this pattern specifically:

• Evaluate redirect chains at depth, not just the first hop. Any URL scanner or email security layer that stops at the first redirect will miss chains like this one. Advanced malware and URL protection that follows multi-hop redirects and evaluates the final destination is the minimum bar.
• Treat vendor URL wrappers as neutral, not trusted. A link that begins at titanhq.com or cisco.com is not inherently safe. These wrappers exist to carry content from arbitrary sources. Build detection logic accordingly.
• Cross-reference sender domain against visual branding. This email presented Microsoft and JULY visuals from an openservices.com.mx domain. That mismatch is detectable. Automated brand impersonation checks that flag visual/sender domain divergence would have surfaced this before the link was even evaluated.
• Don't lean on SPF/DKIM/DMARC as a pass signal. They're a baseline, not a verdict. According to the Microsoft Digital Defense Report 2024, attackers increasingly use legitimate cloud services to pass authentication. DMARC management helps you control your own domain's authentication posture. It doesn't protect you from authenticated messages from attacker-controlled domains.
• Run phishing simulation training that includes redirect-chain scenarios. Users encountering a TitanHQ or Cisco link for the first time may not recognize they're looking at a wrapper, not a destination. The FBI IC3 2024 Internet Crime Report recorded over $2.9 billion in BEC and phishing losses. Scenarios that start exactly like this one.

Attackers know which tools you trust. That's what they're targeting.