Why Your Cloud Provider's Good Reputation Won't Save You From Phishing

For years, security awareness training has leaned on a comforting shortcut: check the URL. If the address bar shows a Microsoft, Google or Amazon domain, you're probably safe. That heuristic is quietly collapsing. A wave of recent research shows attackers no longer need to imitate trusted cloud brands — they're increasingly operating inside them, borrowing the reputation, TLS certificates and mail-sending privileges of the very platforms your business relies on.

This isn't a new domain-spoofing trick with a lick of paint. It's a structural problem with how cloud services are designed: openness, self-service sign-ups and multi-tenant infrastructure are all features, not bugs. The same properties that make Azure, AWS or Microsoft 365 easy to adopt also make them attractive staging grounds for phishing. For Australian organisations that have spent the last decade migrating to the cloud, understanding how infrastructure hijacking works — and where the defensive burden now lies — has become essential.

What "infrastructure hijacking" actually means

The phrase covers a spectrum of techniques, but they share a common goal: get the phishing payload, landing page or credential-capture flow to originate from a domain and IP range that security tooling already trusts.

Kaspersky's Securelist team recently documented how phishers are abusing legitimate cloud infrastructure — spinning up short-lived resources on mainstream providers, hosting credential-harvesting pages behind provider-signed certificates, and routing traffic through services whose reputations are effectively unimpeachable. Because the traffic terminates on trusted cloud endpoints, email gateways and web proxies frequently wave it through.

Microsoft's threat intelligence team observed a variant of the same idea in a campaign it dubbed CaptiveCrunch, attributed to the Russia-linked group Midnight Blizzard. The operation targeted travellers worldwide, using captive-portal-style lures — the kind of "click to connect" screen you see on hotel or airport Wi-Fi — to deliver malware and steal credentials. The lures work partly because captive portals routinely take users to unfamiliar-looking URLs, so users' normal suspicion is switched off before the payload ever loads.

When the login page is real

Perhaps the most unsettling development is documented in Infosecurity Magazine's reporting on a Teams-themed phishing campaign that abused legitimate Microsoft login pages. Rather than build a convincing fake, the attackers routed victims through genuine Microsoft authentication flows and manipulated the OAuth consent process to hand permissions to an attacker-controlled application. The victim really did log in to Microsoft. The URL really was microsoftonline.com. The certificate was valid. And yet the outcome was account compromise.

That is the crux of the problem: when the login page is real, "check the URL" is no longer a defence.

Real-time hijacking, not just credential theft

Older phishing kits harvested a username and password and shipped them to a database for later use. The current generation is faster and more surgical. Research from CTM360, reported by The Hacker News, describes how insurance-sector phishing has evolved into real-time account hijacking: victims enter credentials into a proxied page, an attacker relays them immediately to the real service, prompts the user for the MFA code, and hijacks the resulting session within seconds.

This adversary-in-the-middle model — often powered by open-source toolkits — neuters most forms of multi-factor authentication that rely on one-time codes or push approvals. The victim sees a normal login. The attacker sees a live session cookie. From that point on, the defender is chasing an authenticated user, not an intruder.

Why the old defensive playbook is failing

Three assumptions baked into corporate security are being eroded at once:

Layer in the CaptiveCrunch tactic of targeting travellers — a demographic often using unfamiliar networks, unfamiliar devices, and juggling time zones — and you have a threat model that most awareness training simply doesn't cover.

What actually helps

If the traditional signals are unreliable, defenders have to move up the stack. A few shifts are worth prioritising, particularly for Australian organisations running heavily on Microsoft 365, Google Workspace or AWS.

1. Treat OAuth consent as a privileged action

The Teams-themed campaign exploited consent, not passwords. In Microsoft 365, that means restricting user consent for third-party apps, requiring admin approval for anything requesting sensitive scopes, and auditing existing app registrations. Most tenants have far more consented apps than anyone can remember approving.

2. Move toward phishing-resistant MFA

FIDO2 security keys and platform passkeys are bound to the legitimate domain by the browser. A relayed adversary-in-the-middle page simply cannot complete the handshake. This is the single biggest structural defence against the real-time hijacking pattern described by CTM360.

3. Watch sessions, not just logins

If attackers steal session tokens rather than passwords, detection has to shift to anomalies inside authenticated sessions: impossible-travel patterns, sudden mailbox rule changes, unusual OAuth token usage, or bursts of API calls from unfamiliar IPs. Conditional access policies that re-evaluate risk mid-session — rather than only at sign-in — matter more than ever.

4. Rewrite awareness training for the new reality

Telling staff to "check the URL" is now, at best, incomplete advice. Better guidance for 2025:

4. Assume your cloud tenant is part of someone else's attack chain

Every organisation with an Azure, AWS or Google Cloud footprint should assume its own infrastructure could be co-opted — via a compromised developer account, a forgotten trial subscription, or an over-permissive service principal. Regular reviews of guest accounts, service principals, orphaned resources and outbound abuse signals are no longer optional hygiene; they're a contribution to the wider ecosystem.

The uncomfortable shift

The through-line across all four of these reports — Securelist's cloud-abuse survey, Microsoft's CaptiveCrunch write-up, the Teams login-page campaign, and CTM360's real-time hijacking research — is that the perimeter of trust has moved inside the platforms themselves. The question is no longer "is this domain trustworthy?" but "is this action, in this session, from this device, consistent with what this user should be doing?"

That's a harder question, and it doesn't have a checkbox answer. But it's the right one. Cloud providers will continue to harden their platforms — Microsoft's public attribution of Midnight Blizzard is part of that work — yet the economics of self-service infrastructure guarantee that some abuse will always slip through. Reputation was a useful shortcut while it lasted. The organisations that fare best from here will be the ones that stop outsourcing trust to a logo in the address bar and start verifying behaviour instead.

Related on Bleen

Sources