Phishing campaigns targeting enterprise users have been stealing live Google sessions since mid-August 2026 by combining legitimate Google links, real authentication prompts, and browser-built credential pages. Material Security’s threat research team identified the operation, dubbed Operation CloudFire, and helped remove hundreds of attacker-controlled domains while documenting how the campaign bypassed conventional reputation and link-scanning defenses.
The attackers used Google Calendar invitations and compromised sender accounts to deliver lures, then placed a live reverse proxy in front of Google’s sign-in page. Because victims entered their credentials and approved genuine authentication requests, the operators could capture authenticated Google sessions even when second-factor protections were enabled.
Google Calendar invitations served as the initial lure
The phishing messages arrived as Google Calendar invitations. They could be sent by BCC or from an organization the recipient already knew. The lures used familiar business and legal pretexts, including voicemail notifications, requests for proposals (RFPs) and requests for information (RFIs), court summonses, and non-payment notices.
Most links pointed to Google infrastructure. The common format used Google’s /url redirector, with the phishing destination supplied in a query parameter. Other variants used share.google, Google Drive file links, or an Intuit transaction notification link.
As a result, automated security systems saw legitimate domains, certificates, and reputation data when evaluating the message and its links.
Reverse proxy captured live Google sessions
The attackers placed a live reverse proxy in front of the real Google sign-in page. Victims entered their passwords, received genuine authentication prompts, and approved them while the operators monitored the session in real time.
Two-factor authentication did not prevent session capture because the proxy relayed each authentication step to Google as it arrived. This included SMS codes, authentication codes, Google’s Tap-Yes number matching, and phone-based account recovery prompts.
The campaign used the Nyasher framework, which has been publicly documented since February after hard-coded keys were found in its JavaScript.
Why conventional security controls missed the campaign
Reputation systems typically assess ownership and history: who registered a domain, what other content it hosts, and whether it has previously generated complaints. The campaign was designed to produce benign answers across those checks and used three layers.
- The first layer was Google’s redirector.
- The second layer was a Cloudflare Turnstile challenge. In some versions, it was a genuine widget served from Cloudflare’s own infrastructure.
- The third layer was the credential-capture page, which did not exist as a static website for scanners to retrieve.
After a visitor completed the challenge, JavaScript constructed the page inside the browser. This left automated crawlers with no page to download and proxy logs with nothing static to record. According to Material Security, the pages had not been scanned before the campaign was documented.
The infrastructure was disposable by design. The first observed campaign used numerous lure domains registered through multiple registrars, with most domains created several days before they were used. Receiving endpoints were staged between 1 and 20 days before the associated serving wave.
In one case, a wildcard certificate was issued 46 minutes before the relevant domain was registered. Blocking one component therefore cost the operator only a few dollars and an afternoon of work.
Detection required more than link reputation
Material Security tracked the campaign from its beginning, following changes to the lures, gates, and receiving endpoints. Since August, after campaigns were identified and detections were created, the company reported capturing more than 99% of malicious messages, with a reclassification rate of 0.01%.
The attackers continually modified their tactics, techniques, and procedures (TTPs), themes, and lure text to evade static analysis, machine-learning systems, and agent-based detection.
No single signal was sufficient. Reputation analysis could not identify the activity because the first link led to a Google URL and the final page did not exist until the victim’s browser built it. Link analysis alone also failed to capture the full chain.
Material Security instead evaluated technical indicators, the apparent intent of the message, the location where links ultimately resolved, and the relationship between the sender and recipient. Systems built around only one of these signals inherited that signal’s blind spots, which the operators deliberately mapped.
The location of analysis also mattered. Calendar invitations are not well suited to gateways designed primarily to inspect email in transit, yet many of these attacks arrived as invitations. Material Security treated calendar invitations as a threat surface in their own right, combining an account’s full history with technical indicators.
Compromised sessions extended beyond Gmail
Even when the password was not stolen, a hijacked session could leave evidence in Google Workspace audit logs. The potential impact extended beyond the inbox because an active Google session could provide access to Gmail, Drive, and the ability to grant OAuth access in the victim’s name.
Organizations must determine who monitors those logs and how quickly suspicious activity can be addressed. They also need the ability to cancel sessions and reset affected accounts, including revoking OAuth permissions, within an hour.
Many security programs cannot complete those steps that quickly, while an attacker using a live session may be able to perform numerous actions during that window.
Operation CloudFire targeted the attackers’ infrastructure
By late September, Material Security concluded that adjusting rules, retraining models, and updating agents would not be enough. Detection protected customers but did not disrupt operators preparing the next wave, prompting the threat research team to launch Operation CloudFire against the campaign’s infrastructure.
The team analyzed gateway and backend URLs when messages were sent and reported them through Cloudflare’s abuse-reporting system. Cloudflare’s exploit team examined the fake interstitials and proxied Google sign-in pages behind them, then applied phishing interstitials to the reported destinations.
This burned the attackers’ infrastructure. Operators had to register domains again, designate new gateways and endpoints, and re-authenticate the infrastructure before they could resume sending. The broader internet also benefited because anyone who clicked a reported link saw a warning instead of a credential form, regardless of whether they were a Material Security customer.
Operation CloudFire’s one-month figures
Material Security said the actual totals were higher because the figures came only from customers that agreed to share data. The company documented the following activity during one month of Operation CloudFire:
- 68,676 campaign messages blocked
- 2,112 unique malicious URLs analyzed
- 897 unique domains removed
- 8,570 unique compromised sender addresses across 6,354 root domains
- Message transmission followed US business hours
The number of senders helped the campaign appear credible. Each compromised address was controlled by the attackers before the first invitation was sent, and each account sent invitations to the victim’s saved contacts and other addresses.
Recipients saw a familiar name or domain at a legitimate time, and the links used domains with clean histories. Reputation systems therefore had little reason to raise an alert: ownership and historical scoring layers returned reassuring results.
Campaign activity shifted to Google Drive lures
The phishing themes later changed from calendar invitations to invitations to share Google Drive files and documents. Material Security did not observe comparable increases in other lures or TTPs, and activity associated with this group appeared scattered. The company said the campaign appeared to have ended.
Material Security described the development as an update to the existing campaign rather than a final resolution. Rebuilding the infrastructure was inexpensive, the Nyasher framework had been active since February, and the operator had shipped an unfinished Microsoft 365 branch alongside the live Google code.
The branch contains a stylesheet path, a second harness, and a title string that decodes into the Microsoft sign-in prompt. Those paths are currently unresolved, and adding branding requires the attackers to drop files rather than modify the code.
The operator has built a follow-on feature but has not activated it. Material Security interprets the rotating themes as continued iteration rather than abandonment and expects a future pivot using a similar approach against another brand.
The complete technical breakdown, including metrics and a timeline, is available in the companion white paper.
Sponsored and written by Material Security.
Source: www.bleepingcomputer.com