Table of Contents
Security Tools as Camouflage: The Rise of Redirect Laundering
Phishing infrastructure has a trust problem, and attackers are exploiting it in their favor. A pattern emerging across recent campaigns shows threat actors deliberately routing malicious URLs through legitimate security gateways, academic identity providers, and cloud storage platforms. The result: the link that lands in a recipient's inbox points to a domain that most email filters consider explicitly safe.
This technique, redirect laundering, transforms the very tools organizations deploy for protection into delivery vehicles for credential theft. Two campaigns caught in the wild within a two-week window illustrate how this works in practice.
Key findings:
- Both campaigns passed SPF and DMARC authentication, leveraging compromised or authorized accounts on legitimate mail infrastructure
- Automated link scanners returned "clean" verdicts on the intermediary URLs, missing the malicious final destinations
- Redirect chains spanned 2-3 hops through high-reputation domains before reaching credential-harvesting endpoints
- Each campaign abused a different class of trusted infrastructure: enterprise security gateways in one, academic federation + cloud hosting in the other
- AI-powered email security that evaluates behavioral context caught both campaigns where static URL analysis failed
Voicemail Lure Through the Security Stack
The first campaign targeted a U.S. financial services organization with a voicemail notification impersonating a workplace collaboration tool. The email arrived from a Taiwanese ISP mail server (umail[.]hinet[.]net), authenticated with valid DKIM signatures and passing DMARC. A first-time sender flagged as high risk.
The social engineering was layered: the message body carried branding from a legitimate meeting-transcription service while the display name referenced a different product entirely ("Vantage" branding vs. embedded assets from a well-known AI notetaker). Homoglyph characters in the word "Voice" and a misspelled asset hostname (storage[.]googleaps[.]com instead of googleapis) revealed template-level sloppiness, but the redirect chain was anything but sloppy.
The call-to-action button, labeled "Play Audio-Playback.wav", triggered a three-hop redirect:
- Microsoft SafeLinks (nam11[.]safelinks[.]protection[.]outlook[.]com) wrapped the URL for click-time scanning
- Cisco Secure Web (secure-web[.]cisco[.]com) processed the link as a second layer of URL filtering
- Final destination: ithm[.]org/a, an unrelated domain with no public trust signals, positioned to serve a credential-harvesting page
The irony is architectural. Two enterprise-grade security tools, designed to protect users from malicious links, became the outer layers of the attack's obfuscation stack. Link scanners evaluated the SafeLinks and Cisco Secure Web domains, returned clean verdicts, and never interrogated the terminal URL with the same rigor. The message was quarantined only after AI-driven analysis flagged the brand mismatch, first-time sender signals, and behavioral anomalies that static URL reputation could not surface.
Academic Trust as an Attack Vector
Two weeks earlier, a separate campaign targeted a European-region mailbox using a SharePoint document-sharing notification. The sender domain, i[.]shizuoka-pho[.]jp, registered to a Japanese prefectural government, passed SPF and DMARC. The originating infrastructure sat on a KAGOYA hosting server, suggesting either a compromised account or an authorized sender abusing its mail privileges.
The social engineering took a different approach. Rather than brand-mixing, the attackers embedded a real-looking email thread beneath the phishing CTA, complete with fabricated participants, phone numbers, and event logistics. This conversational hijacking technique adds contextual legitimacy and makes the message harder to dismiss as templated spam.
The "View in SharePoint" button initiated a two-hop redirect:
- Australian Access Federation (central[.]test[.]aaf[.]edu[.]au): an academic identity federation portal used as an intermediary, with the malicious destination embedded in the redirect_uri parameter
- Amazon S3 (1cb23ecf6acb[.]s3[.]us-east-2[.]amazonaws[.]com): hosting a static HTML page capable of rendering a Microsoft login clone for credential harvesting
The AAF domain carries inherent trust: it is a .edu.au federation service used by Australian universities for single sign-on. Attackers weaponized that trust by constructing an OAuth-style authorization URL that appeared to route through legitimate authentication infrastructure. The S3-hosted landing page, meanwhile, benefits from Amazon's domain reputation, a pattern well-documented across cloud-hosted phishing campaigns that continues to evade blocklist-based defenses.
IRONSCALES AI classified this incident with 89% confidence as credential theft, auto-resolving it before any user interaction.
Why URL Reputation Alone Cannot Solve This
Redirect laundering exploits a structural weakness in how most secure email gateways evaluate links. Reputation databases score domains in isolation. When a phishing URL is wrapped inside a Microsoft SafeLinks redirect, the scanned domain is microsoft.com, which will never appear on a blocklist. The same logic applies to Cisco Secure Web, .edu.au federation portals, and S3 buckets. Each intermediary is individually trustworthy; the attack exists only in the chain.
Research from Google's Threat Analysis Group and Cisco Talos has documented the acceleration of cloud infrastructure abuse in phishing. Mandiant's M-Trends 2025 report flagged credential theft via trusted redirect chains as a top initial-access vector. The Anti-Phishing Working Group's Q4 2025 data showed that phishing attacks leveraging cloud hosting platforms increased 28% year-over-year, with S3 and Azure Blob Storage among the most frequently abused services.
The operational challenge is clear: defenders need analysis that follows the full redirect chain to the terminal URL, evaluates behavioral signals (brand consistency, sender history, content anomalies), and correlates against community-sourced threat intelligence to detect novel campaigns before they mature into widespread attacks.
What This Means for Security Teams
Redirect laundering is not an edge case; it is becoming the default evasion layer for credential-theft campaigns targeting enterprise mailboxes. The two campaigns documented here used entirely different infrastructure stacks (Cisco + SafeLinks vs. AAF + S3) to achieve the same outcome: clean URL verdicts from automated scanners and delivery to the inbox.
Organizations that rely solely on gateway-level URL filtering are operating with a structural blind spot. The path forward requires adaptive AI that evaluates intent, context, and chain behavior, not just the reputation of the first domain in the redirect sequence.
---
Combined IOC Table
| Indicator | Type | Case | Context |
|---|---|---|---|
| umail[.]hinet[.]net | Sender Domain | 1 | Authenticated sender (DKIM/DMARC pass); Taiwanese ISP |
| glh-glh@umail[.]hinet[.]net | Sender Address | 1 | Display name: "TeamVoiceReports" |
| 203[.]69[.]209[.]163 | Sending IP | 1 | cmsr-t-4[.]hinet[.]net; SPF pass |
| 59[.]126[.]167[.]139 | Originating IP | 1 | Client IP (hinet-ip[.]hinet[.]net) |
| ithm[.]org/a | Phishing URL | 1 | Terminal credential-harvesting destination |
| storage[.]googleaps[.]com | Typosquat Domain | 1 | Misspelled asset host in email template |
| i[.]shizuoka-pho[.]jp | Sender Domain | 2 | Japanese prefectural government domain; SPF/DMARC pass |
| kazuhiro-asada@i[.]shizuoka-pho[.]jp | Sender Address | 2 | Likely compromised account |
| 203[.]142[.]206[.]254 | Sending IP | 2 | vms21[.]kagoya[.]net (KAGOYA hosting) |
| 34[.]97[.]138[.]170 | Originating IP | 2 | Google Cloud (googleusercontent[.]com) |
| central[.]test[.]aaf[.]edu[.]au | Redirect Intermediary | 2 | Australian Access Federation portal abused as redirect |
| 1cb23ecf6acb[.]s3[.]us-east-2[.]amazonaws[.]com | Phishing Host | 2 | S3-hosted credential-harvesting HTML page |
| f5355c7df4d805[.]html | Phishing Page | 2 | Filename of S3-hosted phishing payload |
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.