It usually starts the same way for the security analyst who first spots it: a phishing email gets flagged for review, and the analyst pulls up the link expecting the usual tell-tale signs — a strange domain, a misspelled brand name, an IP address where a company name should be. Instead, the link resolves to firebasestorage.googleapis.com. A real Google domain. Nothing about it looks wrong, because technically, nothing about the hosting is wrong. Google’s infrastructure is doing exactly what it’s designed to do — serve whatever content someone with an account chose to upload.
That’s the moment researchers started piecing together a pattern that had been building quietly for months. Threat-intel teams tracking phishing kits like Sneaky2FA found it hosted on Firebase Cloud Storage and AWS CloudFront, wearing a convincing fake Microsoft 365 login page. Others tracking EvilProxy found it leaning on Google Sites — a tool most people associate with harmless internal wikis and personal portfolios, not credential theft. Each discovery on its own looked like an isolated abuse case. Put together, they revealed something researchers now call Trusted Infrastructure Phishing: attackers deliberately building their entire operation on top of the same cloud platforms that businesses already trust by default.
The financial sector felt it first and hardest, which makes sense — it’s where a stolen session token turns into a wire transfer fastest. But the kits behind this trend, Tycoon2FA, Sneaky2FA, and EvilProxy, don’t actually care what industry they land in. They’re built to harvest corporate email credentials wherever they can get a foothold, and a domain ending in .azurewebsites.net or .firebaseapp.com is a foothold that walks straight past the filters built to stop the old kind of phishing.
What makes this story worth telling isn’t just the cleverness of the technique — it’s what it reveals about the assumption underneath most phishing defenses: that trust can be tied to a domain name. That assumption quietly broke, and most awareness training hasn’t caught up yet.
Executive Summary
Security researchers are tracking a structural shift they’re calling Trusted Infrastructure Phishing: cybercriminals hosting entire phishing operations — delivery, credential capture, and everything in between — directly on legitimate, enterprise-grade cloud platforms like Microsoft Azure, Google Firebase, Google Cloud Storage, Amazon Web Services, and Cloudflare. Because the traffic originates from domains like azurewebsites.net, firebaseapp.com, or storage.googleapis.com — the same domains countless legitimate businesses use every day — traditional reputation-based filters and “does this link look sketchy” employee training both fail. Named phishing kits including Tycoon2FA, Sneaky2FA, and EvilProxy are being hosted this way, and they don’t just steal passwords — they act as adversary-in-the-middle (AiTM) proxies, sitting invisibly between a victim and the real login page, capturing the session token after multi-factor authentication succeeds. That means MFA alone no longer guarantees safety once someone has clicked through. Financial organizations are currently the most targeted, but the technique isn’t sector-specific — it targets whichever corporate email accounts it can filter its way into.
Quick Facts
| What’s happening | Attackers are hosting phishing infrastructure on trusted cloud platforms instead of attacker-owned domains |
| Platforms being abused | Microsoft Azure, Google Firebase, Google Cloud Storage, AWS, and Cloudflare |
| Named phishing kits | Tycoon2FA, Sneaky2FA, and EvilProxy — all adversary-in-the-middle (AiTM) kits |
| Primary target | Financial organizations and enterprise/corporate email accounts |
| Why it works | Traffic from trusted cloud domains bypasses reputation-based filters and looks legitimate to both software and employees |
| The real danger | AiTM kits steal session tokens after login, which can bypass MFA entirely once a victim clicks through |
| Broader context | Cloudflare’s 2026 Threat Report found 63% of tracked logins use already-compromised credentials, and 94% of login attempts now originate from bots |
How This Attack Maps to Known Techniques
| Tactic | Technique | MITRE ID |
| Resource Development | Acquiring infrastructure through legitimate web services | T1583.006 |
| Initial Access | Phishing via spearphishing links to hosted fake login pages | T1566.002 |
| Credential Access | Adversary-in-the-Middle proxy intercepting live login sessions | T1557 |
| Credential Access | Stealing web session cookies/tokens to bypass MFA | T1539 |
| Defense Evasion | Masquerading as a trusted brand or provider domain | T1036 |
Why “Check the Link Before You Click” Isn’t Enough Anymore
For years, phishing training has centered on spotting a fake domain — a misspelled company name, a strange top-level domain, a suspicious IP. Trusted Infrastructure Phishing breaks that model entirely, because the domain isn’t fake. It’s a real Microsoft, Google, or Amazon subdomain, just one that anyone can spin up a page on in minutes.
The second, more dangerous layer is that these kits don’t just steal a password — they sit in the middle of the actual login process. The victim types their real password into what looks like (and functionally is, for a moment) a real login flow, completes MFA normally, and the attacker silently captures the resulting session token. From that point, the attacker is logged in exactly as if they were the employee — no password needed again, no second MFA prompt to trigger suspicion.
This is why security teams describe it as a structural shift, not just a new campaign: it targets the trust businesses have already been trained to rely on, using the very providers that were supposed to be the safe default.
What Actually Helps Against This
✓ Move toward phishing-resistant MFA (FIDO2 security keys or passkeys) — these can’t be relayed through an AiTM proxy the way a one-time code can
✓ Enable conditional access policies that flag logins from unfamiliar devices or locations, even with a valid session
✓ Shorten session token lifespans so a stolen token has a smaller window of use
✓ Update phishing awareness training to include “the page can be 100% real-looking and still be fake” — not just misspelled URLs
✓ Deploy DMARC, DKIM, and SPF properly to reduce the odds these emails ever reach an inbox
