What Happened
A phishing operation has been stealing live Google sessions from corporate users since mid-August 2026. Reporting credits the Threat Research team at Material Security with spotting the campaign, and the team says it has since taken down hundreds of attacker domains in an effort it calls Operation CloudFire. Google session hijacking is the short version: the operator goes after a session that is already signed in. Every check defenders normally lean on to judge a link came back clean, and the operator designed it that way on purpose.
That is the point of taking a session instead of a password. In general, a live session is already authenticated, so whoever holds it acts as the user without a password prompt and without a fresh MFA challenge. For a client, that means an intruder working inside mail, files and calendar as a real employee. For you, it means a quiet problem that surfaces when someone notices the wrong thing moved.
There is no product version to patch here. It is abuse of how people sign in and how they trust a link that arrives from a familiar place.
What a Stolen Session Costs an MSP
The cost lands in hours, not in a licence. The work is administrative before it is technical: killing sessions, walking through mail rules and sharing settings, working out what the attacker reached, and answering the client's questions while they wait.
Hypothetically, if a hijack ends with deleted or damaged data, restore work lands on top of that cleanup. Clients remember whether their mailbox and files came back. They rarely remember how the link got past the filter.
The other cost is trust. A client who learns their tenant was accessed through a link that looked fine will ask what else looks fine. That conversation is easier when you already have a written answer for how you handle session theft and how you get data back.
Timeline
- Mid-August 2026: the phishing operation has been stealing live Google sessions from corporate users since this point, according to the reporting.
- November 12, 2026: reporting describes the campaign and Operation CloudFire. Material Security's Threat Research team says it has taken down hundreds of attacker domains.
Who Is Affected
The reported targets are corporate users, meaning people signing in to work accounts with live Google sessions. The sources do not name sectors, company sizes or a count of victims.
For an MSP, the practical read is any client running Google as their mail and file platform. The campaign does not need a specific industry. It needs a user with a session and a reason to click.
Staff in finance, admin and executive roles tend to carry the most access and the most invitations, but the reporting does not single out roles and neither should your response. Treat every Google account in the tenant as in scope.
Technical Details
The sources give the following, and nothing beyond it is confirmed about this incident.
- CVE: none. No CVE identifier is given in the reporting.
- Product: Google. The sessions taken are live Google sessions.
- Versions: none stated in the reporting.
- Attack vector: phishing delivered through calendar invites and live proxies, as described in the reporting.
Why Google Session Hijacking Is Hard to Spot
In general, link reputation answers a narrow question: is this address known to be bad? It does not judge what happens after a user clicks, and it does not see a sign-in that completes normally.
In general, a session thief does not need to break authentication. They need the user to complete it. That is why an MFA prompt is not a reliable tripwire for this class of attack when the attacker is relaying the sign-in in real time.
Calendar invites are their own problem. In general, they arrive from a name the user recognises, they sit in a place people treat as internal, and they are clicked with far less caution than an unexpected email.
Catch rate aside, the response does not change. Assume a stolen session is live until you kill it, and assume the attacker added a way back in until you have checked.
What MSPs Should Do
If a client's Google session is taken, the first hour sets the tone. These are standard steps for session theft in general.
- Kill the session first. Revoke the user's active sessions and tokens, reset the password, and force a fresh sign-in from a device you trust.
- Hunt for persistence. Check mail filters and forwarding rules, delegates, calendar sharing, recovery email and phone changes, app passwords, and third-party app access granted to the account.
- Check the blast radius. A stolen session is rarely a one-user event. Look for other accounts that received the same invite or link.
- Review sign-in activity for the session window, including unfamiliar devices and locations, so you know how far the access went.
- Warn users about invites. Tell staff that a calendar invite is a delivery method like any other and should not get more trust than email.
- Move toward phishing-resistant sign-in as a standing practice. Passkeys and hardware security keys are harder to relay in real time than one-time codes.
- Report and block. Report the message to Google, block the sending domain, and note the sender pattern so client filters can catch the next wave.
- Restore data from backup if anything was removed or damaged, and confirm the copy you restore is clean before it goes back.
How EnterProtect Helps
EnterProtect gives MSPs backup, recovery and vulnerability scanning. Backup keeps clean, restorable copies of client data, so a hijack that ends with files deleted or locked does not leave you with nothing to put back.
Recovery is the part the client notices. Getting the account and the data back in place lets the business keep working while you finish the cleanup and the conversation about what happened.
As a standing practice, vulnerability scanning keeps an eye on exposed versions across the estate, so the software your clients run does not sit unpatched for months at a time.
Backup is not a fix for a stolen session. It is the floor under the cleanup. Once the access is gone and the sessions are revoked, having a clean copy is what makes a restore possible.
Frequently Asked Questions
What Is Google Session Hijacking?
It is phishing that targets a signed-in session rather than a password. In this campaign, reported since mid-August 2026, the operator steals live Google sessions from corporate users using calendar invites and live proxies. Once a session is taken, the attacker is already authenticated as that user.
Is There a CVE for This Campaign?
No. The reporting does not attach a CVE identifier to this campaign and lists no affected product version. It abuses the sign-in and link-trust path rather than a patched software flaw.
Does MFA Stop This Attack?
MFA is not a complete answer to session theft, because the session is taken around the sign-in rather than the password alone. Phishing-resistant methods such as passkeys and hardware keys are harder to relay in real time and are worth adopting as a standing practice. Treat MFA as one layer, not a wall.
What Should I Do First If a Client's Google Session Is Stolen?
Revoke the user's sessions and reset credentials so the stolen session stops working. Then audit the account for filter, forwarding, sharing and app access changes that may have been added. Warn other users who may have received the same invite.
Are Calendar Invites a Phishing Risk?
Yes. Calendar invites arrive from a name the user recognises, and people treat them differently from mail, so they get opened more readily. In general, an invite is a delivery method like any other and deserves the same suspicion as an unexpected email.
Do Link Scanners Catch This?
According to the reporting, every check defenders normally lean on to judge a link came back clean, and the operator designed it that way on purpose. Link reputation is a signal, not a guarantee. Layer user reporting, sign-in hardening and session review on top of it.
Sources
- Calendar Invites and Live Proxies: Inside a Google Session Hijacking Campaign (Hackernews)