Many of the recent attacks on our members such as “New Fax” have been the result of a “Pass-the-Cookie” attack on our Google workspaces. This is one of the most dangerous threats right now because it completely circumvents traditional Multi-Factor Authentication (MFA). If an attacker uses infostealer malware to grab the active session token directly from a user’s browser, they don’t need to spoof a login page or intercept an SMS code; they just drop the cookie into their own browser and walk right through the front door.
Here are the some adjustments you might consider making in your Google Workspace Admin console to mitigate this:
- Enable Device Bound Session Credentials (DBSC)
Google’s most direct and powerful countermeasure against cookie theft binds the user’s web session cookie to the specific device they authenticated from. If an attacker steals the cookie and tries to use it on a different machine, the session simply will not work.
Enable DBSC: Go to Security > Access and data control > Google Session control.
You can take this a step further by using Context-Aware Access (CAA) to strictly enforce that users must be on a DBSC-bound session to access core Workspace apps, blocking any fallback methods. - Slash the Web Session Duration
By default, Google Workspace web sessions can stay active for a very long time (sometimes 14 days or indefinitely). The longer a session lives, the larger the window of opportunity an attacker has to exploit a stolen cookie.
Reduce web-session duration: Go to Security > Access and data control > Google Session control.
Reduce the time limit. CISA’s Google Common Controls specifically recommend setting this to 12 hours. This ensures that even if a cookie is compromised, it expires quickly, and the user is forced to re-authenticate with MFA daily. - Lock Down with Context-Aware Access (CAA)
CAA is your Zero Trust engine. It ensures that possessing a valid cookie isn’t enough; the request must also match the right contextual parameters.
Locking down CAA: Go to Security > Access and data control > Context-Aware Access.
Create access levels that restrict core app access to Org-owned/managed devices, specific IP subnets, or designated geographic locations. If an attacker in a foreign country tries to use a stolen cookie from an unknown IP or an unmanaged endpoint, CAA will deny the connection outright. - Alert on “Suspicious Session Cookies”
Google Workspace actively monitors for heuristics indicating a cookie might have been stolen. When it detects an anomaly, it automatically terminates the session and logs the user out. You need to know the second this happens so your team can investigate the user’s endpoint for infostealer malware.
Setting alerts: Go to Reporting > Audit and investigation > User log events (or use the Security Investigation Tool).
Create a filter for the Event: “User signed out due to suspicious session cookie.” Set up an automated email alert for this specific event. - Restrict Chrome Extensions
Since cookies are overwhelmingly stolen by malware or malicious browser extensions operating on the endpoint, hardening the browser environment is a critical preventative step.
Go to Devices > Chrome > Apps & extensions.
Block the installation of unverified or third-party extensions. Move to a strict “Allowlist” model where users can only install extensions explicitly vetted and approved by your security team.
Summary: Implementing DBSC alongside a 12-hour session limit and strict Context-Aware Access will effectively neutralize the vast majority of Pass-the-Cookie attacks.