Since mid-August 2026, a phishing operation has been stealing live Google sessions from corporate users. Every check defenders normally lean on to judge a link came back clean, and the operator designed it that way on purpose.
The Threat Research team at Material Security spotted the campaign and has since taken down hundreds of attacker domains in an effort the team calls Operation CloudFire. Here’s what the researchers found.
The lure: Google Calendar invites
The messages show up as Google Calendar invites. Some arrive by BCC, and many come from an organization the recipient has already traded email with. The pretexts are deliberately boring: voicemail notifications, RFP and RFI requests, court summonses, and missed payment notices. Nothing about them stands out in a busy inbox.
Most of the links point to Google itself. The usual pattern runs through Google’s own /url redirector, with the real destination tucked into a query parameter. Other waves used share.google and Drive file links the same way, and one variant leaned on Intuit transaction notification links. Whenever a message gets scored, the domain, certificate, and reputation on display are all legitimate.
The capture: a reverse proxy in front of Google sign-in
Once a victim clicks through, the attacker runs a live reverse proxy in front of the real Google sign-in page. The victim types a password, gets a genuine prompt, and approves it while the operator watches in real time. The server passes each second factor along to Google as it comes in, whether that’s an SMS code, an authenticator code, Google’s Tap-Yes number matching, or phone-based account recovery. None of those controls stop the session from being captured.
The framework behind it, known as Nyasher, has been publicly documented since February, after researchers found a hardcoded key in its JavaScript.
Why the usual controls stay quiet
Reputation systems answer questions about ownership. They ask who registered a domain, what else it has hosted, and whether anyone has complained about it. This campaign was built so every one of those answers came back harmless.
It works in three layers. The first is Google’s redirector, which gives the initial hop a trusted Google URL. The second is a Cloudflare Turnstile challenge, and in some builds it’s the real widget served from Cloudflare’s own infrastructure. The third is the password capture page, and that’s where things get tricky for defenders. There’s no static site to scan. JavaScript builds the page in the browser after the visitor clears the challenge, so a crawler has nothing to fetch and a proxy log has nothing to record. As far as the researchers know, nobody had scanned those pages before the campaign was documented.
The infrastructure is also meant to be thrown away. Early waves used many lure domains spread across several registrars, and most were registered just days before use. Receiving endpoints went live one to twenty days ahead of the wave they served. One wildcard certificate was issued 46 minutes before the domain it covers was even registered. Blocking any single piece costs the operator a few dollars and an afternoon.
What stopping it took
Researchers tracked the campaign from the start, following each variant as lures, gates, and endpoints rotated. Once detections were in place, they caught more than 99% of the malicious messages, with a reclassification rate of 0.01%. It’s been steady work, since the attacker kept changing tactics, themes, and lure text to slip past static, machine learning, and agentic detections.
What worked was refusing to let any one signal make the call. Reputation alone wouldn’t have caught this. Neither would link analysis, since the first hop is a Google URL and the final page doesn’t exist until a browser builds it. Instead, the detection approach weighs technical indicators alongside the apparent intent of the message, where its links actually end up, and the sending relationship behind it. Any one of those can be enough to act on. A detection built around a single signal inherits that signal’s blind spots, and this operator has put real effort into mapping them.
Where the analysis happens matters too. Gateways built to inspect mail in transit aren’t a great fit for calendar invites, and much of this campaign arrives as invites. Calendar invites need to be treated as a threat surface of their own, with the account’s full history used as context next to the technical signals.
Where the damage lands
A hijacked session leaves its trail in Google Workspace audit logs. A live session reaches mail, Drive, and the ability to grant OAuth access in the victim’s name, so the blast radius goes well past the inbox.
That raises a couple of hard questions for security teams. Who’s actually reviewing those audit logs, and how fast can they act on what they find? Could the team revoke sessions, contain OAuth grants, and reset the affected account within an hour? Plenty of programs can’t, and an attacker holding a live session can do a lot in an hour.
Operation CloudFire: going after the infrastructure
By late September, the researchers decided that tuning rules, retraining models, and updating agents wouldn’t solve this alone. Detection protects customers, but it does nothing about an operator who’s already prepping the next wave. So the team went after the infrastructure.
Analysts pulled the gateway and backend URLs as messages were being sent and reported them through Cloudflare’s abuse reporting system. Cloudflare’s abuse team confirmed the fake interstitial and the proxied Google sign-in page behind it, then put its own phishing warning in front of those destinations.
That had two effects. First, the attacker’s infrastructure got burned. Every reported gateway and endpoint had to be re-registered, re-pointed, and re-certified before the operator could send again. Second, it protected people well beyond any one company’s customers. Anyone who clicked a reported link saw a warning page instead of a credential form.
One month by the numbers
These figures only cover organizations that agreed to share data, so the real totals are higher. Over one month of Operation CloudFire, researchers 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
The messages also followed a clear rhythm, with sends tracking US business hours.
 |
| Message delivery by time of day |
The sender count explains how the campaign earned trust. The attacker controlled each compromised account before the first invite went out, and each one sent invites to the account owner’s saved contacts, among others. Recipients saw a name or domain they knew, on a domain with a clean history, at a sensible time of day. Reputation feeds had no reason to flag any of it.
Where things stand now
The phishing themes have moved from calendar invites to Google Drive file and document share invites. Researchers haven’t seen a matching jump in other lures or tactics, and activity from this group seems to have scattered. For now, the campaign looks finished.
 |
| Messages detected by week |
 |
| Domains registered by interval |
That’s a snapshot, and it could change fast. Rebuilding the infrastructure is cheap, and the framework has been public since February. The operator also shipped an unfinished Microsoft 365 branch alongside the live Google code. It includes a stylesheet path, a second harness, and a title string that decodes to a Microsoft sign-in prompt. None of those paths resolve today, and adding the new brand would only mean dropping in a file, with no code changes. The follow-on is built and waiting.
The researchers see the theme rotation as ongoing iteration and expect the next pivot to look a lot like this one, just with a different brand on it.
The full technical breakdown, including indicators of compromise and a timeline, is in the companion whitepaper. Teams hunting for this activity in their own environments should start there.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/QtXgosw
via IFTTT
No comments:
Post a Comment