Triaging a Google Workspace account takeover, step by step

Two minutes of setup saves an hour of confusion later.

• Open an incident log. A shared doc or ticket where every action gets a timestamp, the person who did it, and why. You'll need it for the timeline, and so will anyone who reviews your work.
• Pick one time zone. The Admin console shows times in your browser's zone. Record everything in UTC so logs, alerts and exports line up.
• Don't use the compromised mailbox to talk to the user. The attacker may be reading it. Call them, or message them on a separate channel.

Goal: decide whether this is a real compromise, and find the moment it started. Move quickly; this phase should take minutes, not hours.

1. Read the alert, then confirm with the user

   Where: Security, then Alert center. Open the alert for the IP address, location, time and affected user.

   Ask the user out of band whether they were travelling, using a VPN, or recently entered their password somewhere after clicking a link. A "no" to the first two and a "yes" to the third settles it.

   Microsoft 365 equivalent: a risky sign-in in Entra ID Protection, or a Defender alert.

2. Pull the user's sign-in history

   Where: Reporting, then Audit and investigation, then User log events. Filter to the user and widen the date range to 30 days; the default is only 7.

   You're looking for:

   • Successful sign-ins from IPs, countries or networks the user has never used. Hosting providers and anonymizing VPNs are a strong signal.
   • A run of failed sign-ins ending in a success, which points to password spraying or guessing.
   • Password changes, 2-Step Verification changes, new passkeys or security keys, and account recovery email or phone changes that the user didn't make.

   The earliest malicious event is your T0. Every later search starts there.

3. Snapshot the account before you change anything

   Containment rewrites the account's current state. Capture it first, which takes about 10 minutes:

   • Export the log searches from step 2.
   • Record the user's recovery email and phone, 2-Step Verification methods, app passwords, connected third-party apps, and enrolled devices, all from the user's page in Directory.
   • Record their Gmail forwarding address, filters, delegates and send-as addresses. These aren't all visible in the Admin console; the open-source GAM tool reads them directly:

   gam user victim@example.com show forwards
   gam user victim@example.com show filters
   gam user victim@example.com show delegates
   gam user victim@example.com show tokens
   gam user victim@example.com show asps

   If the attacker is actively sending mail or deleting data, skip ahead and contain first. Evidence matters, but not more than stopping ongoing damage.

Goal: remove every way the attacker is currently signed in. Changing the password alone isn't enough, because existing sessions and app tokens keep working.

1. Suspend the account, or lock it down in place

   Where: Directory, then Users, then the user, then Suspend user.

   Suspending is the fastest full stop: it blocks sign-in, and Google resets the user's sign-in cookies and OAuth tokens when an account is suspended. Their data stays intact for the investigation.

   If the business can't afford to have the user offline, do all of these instead, in this order, from the user's Security section:

   • Reset the password to a long random one, and don't let the user choose it yet.
   • Reset sign-in cookies, which signs out every session on every device.
   • Revoke all app passwords and connected third-party apps.
   • Remove any 2-Step Verification method, passkey, or recovery option the user doesn't recognize.

   Microsoft 365 equivalent: block sign-in, reset the password, and revoke sessions with Revoke-MgUserSignInSession.

2. If the account had admin rights, treat it as a tenant compromise

   Remove the admin roles immediately, then search Admin log events from T0 onward for anything the account changed: new admins, new users, disabled 2-Step Verification enforcement, SSO or routing changes, or new domain-wide delegation grants. Escalate; this is no longer a single-user incident.

Goal: find the ways back in. Attackers expect the password to be reset, so they plant access that survives it.

1. Check third-party app grants

   Where: Audit and investigation, then OAuth log events, filtered to the user from T0.

   A new app authorized shortly after the malicious sign-in, especially one asking for full Gmail or Drive access, is a classic persistence method. It keeps working after a password reset if you don't revoke it. Note the app's client ID; you'll search for it across the whole organization in step 11.

2. Check mail rules and routing

   Compare the snapshot from step 3 against what the user says they set up. Watch for:

   • Forwarding to an external address.
   • Filters that forward, delete, or archive messages containing words like "invoice", "payment", "wire", or the names of the user's usual contacts. Attackers use these to hide replies from the real user during invoice fraud.
   • New delegates or send-as addresses.

3. Check sign-in methods and devices

   Look for security keys, passkeys, authenticator apps, or recovery details added after T0, and for new devices in Devices or Device log events. A phone the attacker enrolled keeps syncing mail until you remove the account from it.

Goal: answer the question leadership will ask first: what did they see, take, or send?

1. Review email sent from the account

   Where: Security, then Security center, then Investigation tool, with Gmail log events as the data source. Availability depends on your Workspace edition.

   Filter to messages sent by the user after T0. Internal phishing is common: the attacker uses a trusted internal sender to hit colleagues. Check replies inside existing finance or vendor threads, which is how invoice fraud usually works.

   If you find a malicious message, the investigation tool can find every copy across your organization and delete them all at once. To analyze a suspicious message's headers, paste them into the header analyzer.

2. Review file access and exports

   • Drive log events: downloads, files shared outside the organization, and files switched to "anyone with the link".
   • Takeout log events: any Google Takeout export after T0. An attacker exporting a whole account is a serious exfiltration event and should be escalated immediately.

   If the account could reach customer records or financial data, bring in legal and compliance now. Notification requirements can start the clock earlier than you'd expect.

3. Check whether anyone else was hit

   Take what you found and search the whole organization:

   • The attacker's IP addresses, across User log events for everyone.
   • The OAuth client ID from step 6, across OAuth log events.
   • The forwarding destination and the phishing email's subject or sender.

   The same app or IP on several accounts means a campaign, not a single compromise. Run steps 3 through 10 for each affected user.

Goal: give the account back to the user with nothing of the attacker's left in it.

1. Remove everything the attacker added

   • Delete malicious forwarding, filters, delegates and send-as addresses.
   • Block malicious apps for the whole organization, not just this user. Where: Security, then Access and data control, then API controls.
   • Remove the account from unknown devices. Where: Devices, then the device, then Wipe account.
   • Undo any external shares or public links the attacker created.

2. Restore access and keep watching

   Unsuspend the account and set a new password with the user on the phone. Have them re-enroll 2-Step Verification, preferably with a passkey or security key. Then create an activity rule that alerts on this user's sign-ins from new locations for the next 30 days.

Goal: make sure the same attack doesn't work twice.

1. Close the gap that let them in

   • Password phished or reused: enforce 2-Step Verification, and require passkeys or security keys for admins and high-risk roles. Codes sent by text or typed in by hand can be phished; hardware-backed keys can't.
   • Malicious app consent: restrict third-party apps in API controls so users can only authorize apps you've reviewed.
   • Mail forwarded out: disable automatic forwarding to external addresses in Gmail's end-user access settings unless there's a business need.
   • Sign-in from an unmanaged device: use Context-Aware Access to require managed or compliant devices for sensitive apps. It's available in Enterprise editions and Cloud Identity Premium.

2. Write the timeline

   One page: how they got in, T0, when you detected it, when you contained it, what they accessed, what you changed, and what you're changing so it doesn't happen again. The gap between T0 and detection is the number to shrink next time.

Most of the concepts carry over; the names and menus don't.

• Incident log open, times in UTC
• User contacted out of band
• 30-day sign-in history reviewed, T0 found
• Account state and logs exported
• Account suspended, or cookies, tokens and app passwords reset
• Admin roles removed and admin logs reviewed, if applicable
• OAuth grants reviewed and malicious apps blocked
• Forwarding, filters, delegates and send-as cleaned
• Unknown sign-in methods and devices removed
• Sent mail reviewed and malicious copies deleted
• Drive shares and Takeout exports reviewed
• Indicators searched across the organization
• Legal and compliance informed, if data was exposed
• Account restored with phishing-resistant 2SV
• 30-day monitoring rule in place
• Timeline written and root cause fixed