You Tapped Approve. The Attacker Got Your Session.
The calendar invite looked ordinary: a meeting request, sent by an organization you had already traded email with. The link rode Google’s own redirect services. The sign-in page that opened was Google’s real page, the password prompt was genuine, and the approval tap on your phone was a real Google prompt. Every check you know how to make would have passed — and the attacker still walked away with your live Google session.
That is the campaign Material Security’s Threat Research team has been dismantling since mid-August 2026. In a takedown effort the team calls Operation CloudFire, researchers have taken down hundreds of attacker domains and, in a single month, blocked 68,676 campaign messages. The senders were not lookalike accounts: Material counted 8,570 unique compromised sender addresses across 6,354 root domains — real accounts, at real organizations, already in conversation with their targets.
An invite, a click, a man in the middle
The lures arrive as Google Calendar invites, some sent by BCC, dressed in mundane pretexts — a voicemail notification, a request for proposal, a missed payment notice. Click, and the link often travels through Google’s own /url redirector, share.google or Drive file links before landing on a page that assembles itself in the browser after clearing a Cloudflare Turnstile check. That is one reason the campaign slipped past defenses: through mid-September, Material found the lure domains came back clean in every commercial reputation feed it checked.
What waits at the end of the click is not a fake login page. It is a live reverse proxy — a server sitting in front of Google’s genuine sign-in, passing everything in both directions in real time. You type your password; the proxy hands it to Google. Google sends a second-factor challenge; you answer it; the proxy hands that over too. The kit behind the campaign, a phishing framework known as Nyasher that has been publicly documented since February, handles every factor Google offers: SMS codes, authenticator app codes, the tap-yes number match, even phone-based account recovery. When Google completes the sign-in, the session it creates belongs to the operator watching on the other side.
What a stolen session buys
A session is the signed-in state your browser keeps so you do not type your password all day — and it is exactly what the attacker steals. Material notes that a hijacked Google session reaches the victim’s mail and Drive, and carries the power to grant OAuth access in the victim’s name, opening the door to every connected service that trusts the account. No malware ever touches the victim’s machine; the whole attack is a conversation the victim willingly had with Google, with a relay in the middle.
The campaign has seemingly ended, Material says, after the lures shifted from Calendar invites to Google Drive file and document share notifications. Once detections were in place, they caught more than 99 percent of the malicious messages, with a reclassification rate of just 0.01 percent. One warning for what comes next: inside the Nyasher kit, researchers found an unfinished Microsoft 365 branch — the same relay, pointed at a different sign-in page. None of those paths resolve today.
What to do now
The principle is uncomfortable but simple: any factor you can type or tap can be relayed. SMS codes, app codes and push approvals all crossed this proxy untouched, because the victim genuinely approved a genuine sign-in. Phishing-resistant factors are the structural fix — passkeys and hardware security keys sign for one specific site only, so there is nothing reusable for a middleman to pass along. Material is careful to note it did not test passkeys against this kit; the direction, though, is the one CISA’s guidance points as well, and any MFA still beats none.
Beyond that: never approve a sign-in prompt you did not start — an unexpected tap-yes request is an attack in progress, not a glitch. Set Google Calendar to add invitations only from senders you know, and report invites that arrive out of nowhere. For Workspace admins, a hijacked session leaves its trail in the audit logs: review signed-in devices and sessions for accounts that handle sensitive mail, and treat a session appearing where it should not be as an incident, not an oddity. We have covered the same stolen-session pattern from the other side of the wire in the SilentAir campaign that diverted text messages and 2FA codes, and in the LLMjacking wave built on stolen cloud credentials. The lesson keeps repeating: the session is the credential now. Guard it like one.