The phishing page that doesn't exist until you show up: how a calendar invite and a live MFA proxy hijack Google sessions
Since mid-August, a phishing operation has been stealing live Google sessions from corporate users. Through mid-September, the lure domains came back clean in every commercial reputation feed Material's threat research team checked. Here is how it works and why it slips through.
The delivery
It arrives as a calendar invite, sometimes by BCC, often from an organization the recipient has dealt with before. The themes are dull on purpose: voicemail notifications, RFP and RFI requests, court summonses, missed payment notices.
The links inside are mostly legitimately Google. The first hop is Google's own /url redirector with the real destination in a query parameter. Other waves used share. google and Drive file links. At the moment a message gets scored, the domain, the certificate, and the reputation on display are all trusted. So what in your stack follows a Google-wrapped link to wherever it actually ends up?
The page
After Google comes a Cloudflare Turnstile challenge, in some builds the genuine widget. Then comes the page that captures the password, and it has no address to scan. A script builds it in memory after the visitor clears the challenge. A crawler has nothing to fetch and proxy logs have nothing to show.
Behind that page sits a live proxy in front of the real Google sign-in. The victim enters a password, gets a genuine prompt, and approves it, all inside a session the operator is watching. SMS codes, authenticator codes, number match, and phone-based recovery all get relayed to Google as they arrive. MFA does not stop it because the victim completes the MFA.
The infrastructure
It is built to be thrown away. Nine lure domains across five registrars, most registered days before use. One wildcard certificate was issued 46 minutes before the domain it covers was registered. Blocking any single piece costs the operator a few dollars and an afternoon. The framework behind it has been public since February under the name Nyasher.
Why reputation misses it
Reputation answers a question about ownership. Who registered this, what else has it hosted, has anyone complained. This campaign was assembled so every one of those questions returns a reassuring answer. A control that depends on one signal inherits that signal's blind spots.
The outcome is also a hijacked session instead of a stolen password, which means the evidence lands in Workspace logs, not the mail filter. Who is reading those logs, and how quickly? And once a session is live, it reaches mail, Drive, and the ability to grant OAuth access in the victim's name. How much of that can your team close inside an hour?
What comes next
The framework ships with an unfinished Microsoft 365 branch. None of its paths resolve yet, and adding the brand takes a file drop with no code changes. Expect that pivot.
If you run detection or response on Workspace, where does your coverage stop first: the link, the log, or the cleanup?
