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:
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:
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.
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:
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.
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.
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.
---
| 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 |