The Phishing Link That Started at Google.com and Ended at a Fake Disney+ Login

The email landed in the mailbox of an HR business partner at a hospitality company with almost nothing in it. No greeting, no signature, no body copy explaining why it had been sent. The subject line was a string of characters padded with invisible spacing: C A L L E R R e f : # followed by a GUID. The only thing to click was a single link. And that link began with https://www.google.com/.

For a recipient, and for a lot of URL security tooling, that is the end of the analysis. The link goes to Google. Google is safe. But the phishing page it delivered wasn't at Google at all. It was three hops away, on Microsoft infrastructure, wearing a Disney+ login screen.

Four Domains, One Visible Link

The entire attack was a redirect chain built to launder trust through infrastructure nobody blocks. Here is the full path the click took:

1. https://www.google.com/url?q=...: Google's own /url redirect endpoint. This is a legitimate service Google uses to forward clicks. The destination is stuffed into the q= parameter, but the visible, scannable domain is google.com.
2. https://is.gd/REppUK: an is.gd short link, one of the most common URL shorteners on the internet. Expanding it is trivial, but only if your scanner bothers to.
3. https://micro000cd-fxcceegcb0gff4d9.z01.azurefd[.]net/: a Microsoft Azure Front Door subdomain. Azure Front Door is Microsoft's edge and content-delivery service. A subdomain on azurefd.net inherits Microsoft's reputation, but the content served from it is whatever the person who registered the subdomain uploaded. In this case, that was not Microsoft.
4. The credential-harvest page. IRONSCALES link analysis followed the chain to the terminal host and identified a Disney+-branded login modal, a brand with no connection to the sender, the recipient, or any of the three domains in the chain.

Every hop in that list is infrastructure a security team would hesitate to block wholesale. Google, is.gd, and Azure Front Door all carry traffic that is overwhelmingly legitimate. That is precisely why they were chosen. The attacker didn't need to evade reputation systems. They borrowed reputation from platforms that already have it.

The Trap Was URL Reputation, Not Authentication

It would be easy to file this under "authenticated phishing that sailed through every check." It wasn't. This message was noisy where it counted:

• DKIM failed. The message carried a DKIM signature for ocean-pacific[.]net, but no matching public selector was published in DNS, so validation failed outright.
• Microsoft scored it as spam. The inbound record shows SCL:5, SFV:SPM, and category SPM. Microsoft's own filtering flagged it as spam and routed it accordingly.
• The sender was brand new. ocean-pacific[.]net was a first-time sender to the organization, sending from an IP in Singapore (118[.]189[.]184[.]79) with a helo of [127.0.0.1], an anomaly on its own.

SPF passed and DMARC aligned to a p=quarantine policy, but the message was never trying to look perfectly authenticated. The technique it relied on was independent of the From header. The real blind spot was reputation-based URL filtering: a scanner that scores a link by the domain it can see reads google.com, then is.gd, then azurefd.net, and finds three trusted domains. Unless it expands every hop to the actual terminal host, it never encounters the credential page, and each domain in isolation scores as safe. The malicious destination existed only at the end of a chain that most link scanners stop short of resolving.

See Your Risk: Calculate how many threats your SEG is missing

The Page Only Appears After the Chain Resolves

There's a second reason the terminal host is hard to catch: it doesn't reliably show its true face to a scanner. When our analysis rendered the link at detection time, it captured a Disney+ credential prompt. On a later re-scan, the same host returned a CAPTCHA interstitial instead of the login page, behavior consistent with a destination that gates automated inspection and only presents the brand shell once it decides a real user has arrived.

That is the core lesson for defenders. The visible first hop looks safe. The intermediate hops are trusted infrastructure. And the final brand page, the one piece of the attack that would obviously read as phishing, only materializes after the full chain resolves, and sometimes only for a visitor the page has decided to trust. Any of those three properties, on its own, is enough to defeat a scanner that judges links by domain reputation.

IOC Table

What Actually Catches This

Expand every hop to the terminal host. Link analysis that stops at the first (or even the third) domain will keep scoring redirect chains as safe. Detection requires following google.com/url → is.gd → azurefd.net all the way to the page that renders, and evaluating that.

Treat trusted infrastructure as a delivery channel, not a verdict. Google redirects, public shorteners, and Azure Front Door subdomains all appear in legitimate mail every day. Their presence in a link says nothing about the destination. Reputation belongs to the platform, never to the arbitrary content hosted on it.

Correlate behavior, not just domains. A first-time Singapore sender with a failed DKIM signature, an empty body, a zero-width-padded subject, and a single Google-wrapped link is a coherent phishing pattern even when each domain in the chain checks out. IRONSCALES Themis resolved the full redirect chain and correlated it with community intelligence from similar reports across the network, flagging the message as credential harvesting and auto-resolving it before the recipient, or a second mailbox in the same organization that also received it, could interact with the link.