Three Hops, Two Brands, One Fake WAV File: Inside a Multi-Layer Redirect Phishing Attack

The email subject suggested a voicemail.

The call to action was a button labeled "Play Audio-Playback.wav."

And if a banking operations specialist at a regional community bank had clicked it, they would have traveled through three separate URL layers before arriving anywhere at all.

That layering is the point. Each hop in the chain passes through a legitimate-looking service. SafeLinks hands off to Cisco Secure Web, which hands off to the actual destination: ithm[.]org, an unrelated domain with no connection to the displayed brand. By the time any URL scanner finishes evaluating the first redirect, the real payload is two steps away.

Themis flagged this one as credential theft before either of the two targeted mailboxes could interact with it. But unpacking how the attack was built is worth the time, because this isn't a one-off.

It's a repeatable playbook.

A Sender That Passes the Authentication Test (Technically)

The email came from glh-glh@umail[.]hinet[.]net, a Taiwanese ISP email service. The display name was "TeamVoiceReports," which reads like a generic notification service and is easy to overlook when you're scanning an inbox.

DKIM passed. DMARC passed. Both authenticated the sending domain, umail[.]hinet[.]net, correctly. This is the scenario that catches a lot of security teams off guard: authentication standards verify the sending infrastructure, not the brand identity being impersonated. An attacker routing mail through a legitimate ISP can clear both checks while displaying whatever they want in the "From" field.

SPF tells a more complicated story. The origin IP, 59[.]126[.]167[.]139 (a HiNet-registered address in Taiwan), passed SPF. But the email routed through a Votiro relay at 44[.]206[.]213[.]130 after that, which produced a softfail. That mismatch in the relay chain, combined with the display name disconnect, is exactly the kind of behavioral signal that separates AI-driven behavioral analysis from static authentication gatekeeping. According to the Verizon 2024 Data Breach Investigations Report, 68% of breaches involve a human element, and attacks built to look credible at a glance are designed to exploit that gap.

The Redirect Chain: Three Gates Before the Payload

Here is the full path the attack was designed to send a victim through:

1. Microsoft SafeLinks (nam11.safelinks.protection[.]outlook[.]com) rewrites the URL as part of M365's built-in link scanning. It's intended as a protection layer. Attackers use it because adding a Microsoft-owned URL to the chain makes the message look more legitimate and delays analysis.
2. Cisco Secure Web (secure-web[.]cisco[.]com) represents another security scanning hop. Same logic: the redirect through a security vendor's infrastructure signals safety to other tools scanning the chain.
3. ithm[.]org/a is where the chain ends. This domain has no connection to the displayed brand, no legitimate context for a banking notification, and no reason to appear at the end of an audio playback flow.

This technique maps to MITRE ATT&CK T1608.005 (Stage Capabilities: Link Target) and T1566.002 (Spearphishing Link). The attacker staged the final malicious destination behind layers of trusted intermediaries specifically to survive sequential URL scanning. By the time a scanner has verified that SafeLinks is a real Microsoft domain, it may not evaluate what SafeLinks is pointing to.

Brand-Mixing as a Credibility Play

The email body combined visual elements from two unrelated legitimate services: branding styled after the victim's bank, alongside logos and image assets from Fathom (the video meeting platform at fathom[.]video and fathom[.]ai). The actual CTA resolved to ithm[.]org.

This is brand-mixing as a deliberate technique (MITRE ATT&CK T1036.005: Masquerading), and it creates a specific problem for automated detection: no single brand is being spoofed cleanly. There is no exact match to a known phishing template. A scanner looking for a "Bank of America phish" or a "DocuSign phish" won't find a clean hit here because the visual identity is deliberately composite.

Fathom's assets appearing alongside financial institution branding creates a surface-level coherence. Organizations use video tools for internal communications. A voicemail-style notification that incorporates both is odd but not immediately disqualifying to a recipient who isn't looking closely.

What the attacker didn't clean up: asset hosts. The email referenced storage[.]googleaps[.]com (note: googleaps instead of googleapis) and used the word "assts" where "assets" was intended. The subject also used a non-standard Unicode character in the word "Vοice" (the omicron character substituted for a standard Latin 'o'). These homoglyph substitutions (T1036.005) evade exact-string matching in scanners while rendering visually similar on screen. The grammar error ("Voice Message's" with an incorrect possessive) adds another layer of rough edges that an attacker moving fast, relying on a templated mass-mailing kit, often leaves behind.

What the IOC Table Shows

What Security Teams Should Take from This

The attack passed two authentication checks. It routed through two legitimate security vendor URLs before reaching its payload. It mixed brands to avoid clean template matching. It used Unicode substitution to defeat string scanners. Every one of those layers is a deliberate choice designed to exploit a specific gap in rule-based and authentication-first defenses.

According to IBM's 2025 Cost of a Data Breach Report, the average cost of a phishing-related breach reached $4.76 million. The attacks driving those numbers are not simple. They are layered, adaptive, and purpose-built to survive the tools most organizations are relying on.

Three things security teams should act on after reviewing this case:

• Audit what your URL scanner actually evaluates. SafeLinks and Cisco Secure Web are in this chain because attackers know scanners often stop at the first redirect. Confirm your tooling follows multi-hop chains to their final destination before rendering a verdict.
• Treat authentication pass as one signal, not a clearance. DKIM and DMARC passing for umail.hinet.net tells you nothing about whether "TeamVoiceReports" is a legitimate sender for your organization. Behavioral alignment between displayed identity and sending infrastructure is a separate check that authentication headers don't perform. IRONSCALES DMARC management covers where the standard leaves off.
• Train for visual credibility attacks, not just obvious fakes. This email looked coherent enough to be a legitimate notification. Phishing simulation testing that includes brand-mixing, audio lure themes, and multi-step CTAs prepares employees for the attacks actually reaching their inboxes, not the textbook examples.

The two mailboxes in this case were quarantined. Themis identified the credential theft classification from the combination of authentication mismatch, relay anomalies, and redirect chain behavior. Without that layer of analysis running in parallel with gateway scanning, this email had a plausible path to a clicked link. For organizations still relying on perimeter filtering as the primary control, the missed-attack math on that approach is worth confronting directly.

External sources referenced:

• Verizon 2024 Data Breach Investigations Report
  verizon.com/business/resources/reports/dbir

• IBM Cost of a Data Breach Report 2025
  ibm.com/reports/data-breach

• MITRE ATT&CK T1566.002 (Spearphishing Link)
  attack.mitre.org/techniques/T1566/002

• MITRE ATT&CK T1036.005 (Masquerading: Match Legitimate Name or Location)
  attack.mitre.org/techniques/T1036/005

• MITRE ATT&CK T1608.005 (Stage Capabilities: Link Target)
  attack.mitre.org/techniques/T1608/005

• CISA Phishing Guidance
  cisa.gov/topics/cybersecurity-best-practices/phishing