Operation CloudFire: Sophisticated Phishing Campaign Bypassed MFA with Live Session Hijacking
A highly advanced phishing operation, dubbed **Operation CloudFire** by **Material Security**, has been actively harvesting live **Google** sessions from corporate users since mid-August 2026. This campaign masterfully exploited trust indicators and bypassed multi-factor authentication (MFA) by employing a real-time reverse proxy in front of genuine **Google** sign-in pages, making traditional defenses ineffective.

Since mid-August 2026, a sophisticated phishing operation has been observed harvesting live **Google** sessions from corporate users. What makes this campaign particularly insidious is its ability to bypass virtually every signal defenders typically rely on, intentionally constructed by the threat actor.
**Material Security**'s Threat Research team identified this campaign and has successfully taken down hundreds of domains used by the attackers, naming their counter-offensive **Operation CloudFire**.
## The Lure: Deceptive Google Calendar Invites
The initial attack vector often begins with **Google Calendar** invites, frequently delivered via BCC and originating from organizations the recipient has previously corresponded with. The pretexts are mundane yet effective: voicemail notifications, RFP/RFI requests, court summonses, or missed payment notices.
Most malicious links initially point to legitimate **Google** URLs, typically using **Google**'s own `/url` redirector with the true destination embedded in a query parameter. Other variants utilized `share.google` and **Drive** file links. One observed variant even leveraged **Intuit** transaction notification links. Crucially, when these messages are analyzed, the domain, certificate, and displayed reputation consistently appear legitimate and trusted.
## The Capture: Real-time Reverse Proxy Hijacking
Upon clicking a malicious link, victims are directed to a live reverse proxy positioned in front of a genuine **Google** sign-in page. The victim inputs their password, receives a real MFA prompt, and approves it โ all while the attacker silently observes and captures the session in real-time.
The attacker's server relays SMS codes, authenticator codes, **Google**'s Tap-Yes number matching, and phone-based account recovery codes to **Google** as they arrive. This sophisticated mechanism ensures that none of the standard second-factor controls prevent the session from being captured. The framework facilitating this, known as **Nyasher**, has been publicly documented since February, following the discovery of a hardcoded key in its JavaScript.

## Why Traditional Controls Failed
Reputation systems primarily assess domain ownership, historical hosting, and reported abuses. This campaign was meticulously designed to present consistently benign answers across three layers of deception:
1. **Google's Redirector**: The initial link uses a legitimate **Google** URL.
2. **Cloudflare Turnstile Challenge**: Some builds incorporate a genuine **Cloudflare Turnstile** widget served from **Cloudflare**'s own infrastructure.
3. **Dynamic Password Capture Page**: The actual password-capture page has no static website to scan. It is constructed in the browser via JavaScript only after the visitor clears the challenge, rendering traditional crawlers and proxy logs ineffective.
**Material Security** notes that, to their knowledge, these dynamically generated pages had not been scanned prior to this campaign's documentation. The infrastructure itself is designed for disposability. The campaign employed numerous lure domains across multiple registrars, often registered just days before use. Receiving endpoints were staged one to twenty days in advance of their operational wave. In one instance, a wildcard certificate was issued just 46 minutes before its covering domain was registered. Blocking any single component incurs minimal cost and effort for the attacker.
## Defending Against the Evolving Threat
**Material Security** has continuously tracked **Operation CloudFire**, adapting to shifts in lures, gates, and receiving endpoints. Since identifying the campaign and implementing detections in August, **Material** has achieved over 99% blocking of malicious messages, with an impressive reclassification rate of 0.01%.
This success stems from a multi-signal approach, recognizing that no single indicator is sufficient. Reputation alone, or link analysis in isolation, would have failed given the legitimate initial **Google** URLs and dynamically generated final pages. **Material** scores technical indicators, message intent, actual link resolutions, and sender relationships, allowing any one of these to trigger a detection.
Furthermore, the location of analysis is critical. Calendar invites, a primary vector for this campaign, are often poorly handled by traditional email gateways designed for in-transit mail inspection. **Material** treats calendar invites as a distinct threat surface, leveraging full account history alongside technical signals for comprehensive context.
## The Impact of a Hijacked Session
A hijacked session, unlike a stolen password, provides direct access to **Workspace** audit logs, email, **Drive**, and the ability to grant **OAuth** access under the victim's name. This extends the blast radius significantly beyond the inbox.
Defenders must critically assess their incident response capabilities: Who is reviewing these logs, and how quickly can they act? The ability to revoke sessions, contain **OAuth** grants, and reset affected accounts within an hour is paramount, as attackers with live sessions can cause substantial damage in a short timeframe.
## Operation CloudFire: Targeting Infrastructure
By late September, **Material** concluded that detection alone was insufficient. While protecting customers, it did not address the root cause โ the active threat actor preparing subsequent waves. Thus, **Material Security**'s Threat Research team launched **Operation CloudFire** to directly target the campaign's infrastructure.
The team analyzed gateway and backend URLs as messages were sent, reporting them through **Cloudflare**'s abuse reporting system. **Cloudflare**'s abuse team validated the fake interstitial and proxied **Google** sign-in page, then applied its own phishing interstitial to those destinations. This had two key effects:
1. **Infrastructure Burn**: The attacker's infrastructure was compromised, forcing them to re-register, re-point, and re-certify each reported gateway and endpoint before resuming operations.
2. **Broader Internet Benefit**: Anyone clicking a reported link, regardless of their **Material** customer status, encountered a warning instead of a credential form.
## Campaign Statistics Over One Month
These figures represent data from customers who opted to share information with **Material**, indicating the true totals are likely higher. Over one month of **Operation CloudFire**, **Material** recorded:
* 68,676 campaign messages blocked
* 2,112 unique malicious URLs analyzed
* 897 unique domains taken down
* 8,570 unique compromised sender addresses across 6,354 root domains
* Send cadence that followed US business hours

The high number of compromised sender addresses underscores the campaign's credibility. Each sender account was controlled by the attacker before the first invite, and invites were sent to victims' saved contacts and other addresses. Recipients saw familiar names or domains with clean histories at plausible times, rendering reputation feeds ineffective.
## Current Status and Future Outlook
The phishing themes have recently shifted from calendar invites to **Google Drive** file and document share invites. While **Material** has not observed a corresponding rise in other lures or TTPs, and activity from this group appears to have dispersed, the campaign's conclusion is a status update, not a final verdict.


Rebuilding the infrastructure is inexpensive, the **Nyasher** framework has been public since February, and the operator previously shipped an unfinished **Microsoft 365** branch alongside the live **Google** code. This branch includes a stylesheet path, a second harness, and a title string that decodes to a **Microsoft** sign-in prompt. Although these paths are currently inactive, adding the **Microsoft** brand merely requires dropping in a file, not changing code.
**Material Security** interprets the theme rotation as iteration, not retirement, and anticipates the next pivot to closely resemble this one, albeit with a different brand target. Teams actively hunting for this activity are encouraged to consult the companion whitepaper for a full technical breakdown, including indicators and a timeline.