Material Security/Bleeping Computer
Click here to read the entire article
Since mid-August 2026, a phishing operation has been harvesting live Google sessions from corporate users. Every signal defenders usually rely on to judge a link returned a reassuring answer, and the operator built the chain that way on purpose.
Material Security’s Threat Research team identified the campaign and has taken down hundreds of domains used by attackers in what they have dubbed Operation CloudFire. Here’s what they learned along the way.
The lure: Google Calendar invites
The messages arrive as Google Calendar invites, sometimes delivered by BCC and often sent from an organization the recipient has already corresponded with. The pretexts are mundane: voicemail notifications, RFP and RFI requests, court summonses, and missed payment notices.
Most links point to Google itself. The typical pattern is Google’s own /url redirector with the real destination in a query parameter, though other waves used share.google and Drive file links for the same purpose. One variant used Intuit transaction notification links.
In every case, when the message is scored, the domain, certificate, and reputation displayed are legitimate and trusted.
The capture: Reverse proxy in front of a Google sign-in page
The attacker runs a live reverse proxy in front of the genuine Google sign-in page. The victim enters a password, receives a real prompt, and approves it, all while the operator watches the session in real time.
The server relays SMS codes, authenticator codes, Google’s Tap-Yes number matching, and phone-based account recovery to Google as each one arrives, so none of the second-factor controls stop the session from being captured.
The framework behind this, Nyasher, has been documented publicly since February, after a hardcoded key was found in its JavaScript.
Why the controls don’t fire
Reputation systems answer a question about ownership: who registered the domain, what else it has hosted, and whether anyone has complained about it. This campaign was assembled so that those answers were consistently benign, and it has three layers.
The first layer is Google’s redirector. The second is a Cloudflare Turnstile challenge, which in some builds is the genuine widget served from Cloudflare’s own infrastructure. The third layer is the password-capture page itself, which has no static website to scan.
The Javascript constructs it in the browser after the visitor clears the challenge, so a crawler has nothing to fetch and a proxy log has nothing to record. To Material’s knowledge, no one had scanned those pages before the campaign was documented.
The infrastructure is disposable by design. The initially observed campaign used many lure domains across multiple registrars, most registered only days before use. Receiving endpoints were staged one to twenty days ahead of the wave they served.
One wildcard certificate was issued 46 minutes before the domain it covers was registered. Blocking any single component costs the operator a few dollars and an afternoon of work.