Learn
Playbook
If you think a Google Workspace account has been compromised, the fastest way to confirm it is to check four logs in the Admin console, in this order: the login audit log for unusual sign-in activity, the OAuth token log for unauthorized app grants, the Gmail log search for forwarding or filter rules, and the Drive audit log for mass downloads or external sharing changes. Google recommends reviewing Admin Audit Logs, OAuth app authorizations, Gmail forwarding rules, and Drive sharing changes immediately once compromise is suspected, because some events take hours to appear and standard log retention is capped at six months. This guide walks through exactly what to look for, in what order, and when to stop investigating and call in professional help.
TL;DR
Google Workspace gives you four relevant logs: login audit, admin audit, Drive audit, and Gmail log search. Each answers a different question, so check them in a deliberate sequence rather than scrolling randomly.
The clearest signals of account takeover are logins from unfamiliar locations or odd hours, new OAuth app grants, newly created forwarding or filter rules, added delegates, and changed recovery details.
Evidence has a shelf life. Most logs retain for six months, email log search is limited to 30 days, and console exports cap at 100,000 rows.
Once takeover looks confirmed, contain fast: force password reset, sign out all sessions, revoke OAuth tokens, and remove any delegation before you do anything else.
If there’s any sign of lateral movement, data exfiltration, or you’re not confident in your read of the logs, that’s the point to bring in a professional incident response team rather than continue solo.
About the Author: ShiftControl is purpose-built for Google Workspace and built for operators rather than IT teams, so companies without a dedicated IT hire can still run access control, provisioning, SaaS spend management, and app-permission visibility. ShiftControl’s founders spent years running the actual Admin console for a company that scaled from 100 to over 700 employees across seven offices. This walkthrough reflects the same investigation sequence they used when something looked wrong at 2 a.m. and there was no security team to call.
What Audit Logs Actually Exist in the Google Workspace Admin Console?
The Google Workspace Admin console splits its audit data into separate logs by activity type, and knowing which one answers which question saves real time during an investigation. You access all of them through Reporting > Audit and investigation in the Admin console.
Login audit log: Records every sign-in attempt, successful or failed, including IP address, location, device, and login type (password, SSO, 2FA). This is your first stop for a suspected account takeover, because it tells you whether someone else has actually been getting in.
Admin audit log: Records changes made by anyone with admin privileges, including role changes, password resets, and org unit moves. Critical if the compromised account has any admin rights, since an attacker with admin access can quietly grant themselves more.
Drive audit log: Tracks file views, downloads, sharing changes, and permission edits. This is where you’d see if someone exported a large batch of files or made a folder externally shared.
Gmail log search: A narrower, search-based tool for tracing delivery of individual email messages. Note that this is limited to a 30-day retention window, considerably shorter than the other logs.
OAuth token audit events: Nested inside the login and admin logs rather than a separate tab, these show which third-party apps a user has granted access to, and with what scopes.
None of these logs unify automatically. You’re reading four separate views into the same account’s behavior, which is exactly why an unstructured approach to reading them wastes time you don’t have.
What Are the Actual Signs of a Compromised Google Workspace Account?
Building on the log types above, the next question is what you’re actually looking for once you open them. Certain patterns show up consistently in confirmed account takeovers.
Signal | Where to find it | Why it matters |
|---|---|---|
Impossible travel (logins from two distant locations within an implausible time window) | Login audit log | A physical impossibility means one login isn’t the real user |
Multiple failed logins followed by a success | Login audit log | Classic pattern of a brute-force or credential-stuffing attempt that eventually landed |
New device or browser authenticating, especially on an admin account | Login audit log | Attackers typically authenticate from unfamiliar hardware before doing anything else |
Newly created Gmail forwarding rule or filter | User log events (or Admin audit log if made by an admin) | A common technique to quietly siphon incoming mail (invoices, resets, internal comms) without alerting the account owner |
Unauthorized OAuth app authorization | OAuth token events | Attackers often connect a third-party app to maintain persistent access even after a password reset |
Added account delegation | User log events (or Gmail log events) | Delegation grants another mailbox full access to send and read as the compromised user, and it survives a password change |
Changed recovery phone or email | Login audit log (or User log events) | Usually one of the first things an attacker does, to lock the real owner out of self-service recovery |
Sudden bulk file downloads or new external sharing | Drive audit log | Signals exfiltration rather than just unauthorized access |
The mechanism behind why forwarding rules and delegation matter so much is worth understanding, not just memorizing. A password reset closes the front door. But a forwarding rule or a delegated mailbox is a second door the attacker built themselves, and it stays open regardless of what happens to the password. This is why containment steps later in this guide treat those two items as first-priority, not afterthoughts.
In What Order Should You Actually Investigate?
Knowing what to look for is only half the problem. Without a sequence, it’s easy to burn 40 minutes tabbing between logs without a clear answer. Here’s a practical order, built around confirming compromise as fast as possible and then scoping its extent.
Check the login audit log first. Filter by the specific user and look at the last 7-14 days. You’re answering one question: has anyone besides the legitimate user been signing in? Note IP addresses, timestamps, and device fingerprints for anything unfamiliar.
Cross-reference login times against the user’s actual working hours and location. A login at 3 a.m. local time, or from a country the employee has never traveled to, is a stronger signal than an unfamiliar IP alone (some legitimate logins come from VPNs or mobile carriers that rotate IPs).
Pull OAuth token events for the account. Look for any third-party app authorization that wasn’t sanctioned, especially anything granted around the same timestamp as a suspicious login.
Search Gmail logs for new forwarding rules and filters created in the suspicious window. Pay attention to filters that forward, delete, or archive mail matching finance or HR keywords, a common pattern in business email compromise.
Check the admin audit log for delegation changes, recovery detail edits, or role changes on the account. If the account has any admin privileges, this step is not optional.
Check the Drive audit log for sharing changes and download volume in the same window. This tells you how far the exposure goes, not just whether someone got in.
Document what you found, with timestamps, before you start remediation. Once you reset the password and kill the sessions, the attacker’s own future activity stops generating new log entries, but you’ll want a clear record of what happened for compliance purposes and any post-incident review.
Running the steps in this order matters because each one either confirms or rules out the next. If the login log shows nothing unusual, you’re likely dealing with a false alarm or a different kind of issue entirely, and you can stop before spending time on OAuth and Drive logs that probably won’t show anything either.
Why Does Log Retention Timing Actually Matter Here?
Every step above assumes the evidence is still there to read, and that assumption has a real expiration date. Google Workspace retains most audit logs (Admin, Login, Drive) for six months, but Gmail log search is limited to a 30-day window. Exports through the Admin console are capped at 100,000 rows, and only Enterprise Plus customers can push that up to 30 million rows via export to Sheets.
Two practical consequences follow from this. First, if you suspect an account has been compromised for a while, don’t assume you’ll be able to trace the full timeline. If the initial breach happened five months ago and mail-related evidence lived only in Gmail log search, it’s already gone. Second, once you do spot something suspicious, export or screenshot the relevant log entries before you start remediation. Compliance frameworks that require audit trail evidence, including SOC 2’s Trust Services Criteria and HIPAA’s technical safeguard requirements, expect you to be able to produce this documentation later, and you can’t reconstruct a log after the retention window closes.
This retention ceiling is also the core limitation of relying on Google’s native logging alone. Native Workspace logs can’t be searched across multiple log types simultaneously, and there’s no unified timeline view, which is why the log-by-log manual sequence in this guide is necessary in the first place. Third-party audit tools address this by extending retention and giving cross-platform visibility, but if you’re reading this mid-incident, you’re working with what the Admin console gives you right now.
What Should You Do the Moment Compromise Looks Confirmed?
Once the logs above show a consistent pattern, that’s not the end of the investigation, it’s the point where speed matters more than thoroughness. Containment actions, in order:
Force a password reset immediately, and require it to happen on next sign-in rather than sending a reset link to the account (an attacker with mailbox access could intercept the reset email).
Sign the user out of all active sessions from the Admin console. A password change alone does not terminate sessions already in progress.
Revoke OAuth tokens for any unauthorized third-party app you identified in the earlier check. This closes the persistent-access door that a plain password reset leaves open.
Remove any delegation added to the account. Check this even if you didn’t find suspicious delegation in your initial pass, since it’s a common second door.
Reverse any forwarding rules or filters created during the suspicious window, and check whether any inbox rules were set to auto-delete or archive incoming security alerts (a common attacker move to suppress warning emails).
Reset recovery phone and email details back to values the actual user confirms.
Enforce MFA on the account if it wasn’t already required. This is a good moment to check whether MFA is enforced organization-wide, not just for the affected user.
If the investigation surfaces signs of lateral movement (the attacker touching other accounts), large-scale data exfiltration, or ransomware indicators, or if you’re simply not confident you’ve fully scoped the exposure, this is the point to stop self-serving the investigation and bring in dedicated incident response. Digital forensics and legal exposure questions go beyond what a log review in the Admin console can answer. ShiftControl includes IR-1 incident response through Blackpanda in the standard subscription, giving 24/7 access to responders when a self-serve investigation reaches its limit.
Frequently Asked Questions
How do I check if my Google Workspace account is compromised?
Start with the login audit log in the Admin console (Reporting > Audit and investigation) and filter by the account in question. Look for logins from unfamiliar IPs, locations, or devices, and cross-reference timestamps against the user’s normal working pattern. Then check OAuth token grants, Gmail forwarding rules, and Drive sharing changes for the same window.
How long does Google Workspace keep audit logs?
Most audit logs (Admin, Login, Drive) retain for six months. Gmail log search is limited to a 30-day window, which is significantly shorter, so email-related evidence disappears faster than login or file activity evidence.
What’s the difference between the login audit log and the admin audit log?
The login audit log tracks sign-in attempts and authentication events for any user. The admin audit log tracks configuration changes made by anyone with admin privileges, such as role changes, password resets, and delegation. You need both if the compromised account has any administrative access.
Can I export Google Workspace audit logs for evidence?
Yes, through the Admin console, capped at 100,000 rows for standard exports. Enterprise Plus customers can export up to 30 million rows to Google Sheets. Export or document relevant entries before starting remediation, since active sessions and rules change once you begin containment.
What are the clearest signs of account takeover in the logs?
Impossible travel between logins, repeated failed attempts followed by a success, new devices authenticating on admin accounts, unauthorized OAuth app grants, newly created mail forwarding rules, added delegation, and changed recovery details.
Do I need a dedicated security team to do this investigation?
No, but you do need someone with the right admin privileges. Access to these logs requires specific privileges, such as the Reports or Audit and Investigation privilege, to be granted in the Admin console. The sequence above is designed for an operator without a dedicated security function, provided they have that access. The point to escalate to professional incident response is when you find signs of lateral movement, exfiltration, or ransomware, or when you’re uncertain about the scope of what you’re seeing.
Does resetting the password alone fix a compromised account?
No. A password reset closes one door but leaves OAuth tokens, mailbox delegation, and forwarding rules intact unless you remove them separately. Attackers frequently set these up specifically because they survive a password change.
About ShiftControl
ShiftControl is purpose-built for Google Workspace and built for operators rather than IT teams, so companies without a dedicated IT hire can still run access control, provisioning, SaaS spend management, and app-permission visibility from one place. Setup takes about 10 minutes through a single Google Workspace login, no implementation project required. ShiftControl is one platform for four jobs: provisioning and access, SaaS spend management, app-permission visibility, and incident response, and it includes IR-1 incident response through Blackpanda in the standard subscription. ShiftControl is SOC 2 compliant, ISO-compliant, and has signed the CISA Secure by Design Pledge.
If reading through four separate Admin console logs during a live incident feels like more friction than your team has time for, ShiftControl brings access control, SaaS visibility, and incident response into one place, so the next time something looks wrong, you’re not starting from a blank Admin console.
