What to check after a Google Workspace account is compromised

Resetting the password is not containment. The controls overlap, but no single one of them covers everything — and the persistence someone leaves behind survives all of them if you do not go looking for it specifically.

A staff account starts sending invoice fraud to the whole parent list, or a student account is quietly forwarding everything to an address nobody recognizes. The first instinct is right — reset the password — and it is also not enough on its own.

An attacker who has been in an account for even an hour has usually left something behind that a password reset does not touch. Working out what, and in what order to remove it, is the whole job.

The short answer

Contain first, investigate second. Google's own documented sequence starts with suspension, before any of the analysis.

The controls overlap, but no single action cleans up every route in. Suspension resets sign-in cookies and OAuth tokens. A password change is a separate credential change that invalidates access and refresh tokens. Neither can be relied on to clear app passwords — Google's own documentation contradicts itself there, so remove those yourself. Assuming any one of these covered the rest is the most common way an account stays compromised after it has been "fixed".

Then hunt for persistence. Filters, forwarding, delegation, and connected apps all survive a password change, and all of them are how someone gets back in or keeps reading.

Contain

Suspend the account. Google's guidance leads with this for a reason:

Suspend a user to prevent unauthorized access

Suspension is instant, total, and reversible. It also stops the account doing further damage to your reputation while you work out what happened, which in a district — where the recipients are parents — matters more than it does almost anywhere else.

Do it before you start reading logs. The investigation is not urgent in the way the sending is.

What each action actually revokes

This is the part that gets half-done, and it is worth being precise because the controls overlap unevenly.

Suspension resets sign-in cookies and OAuth tokens. Google says so directly: "Suspending a user resets the user's sign-in cookies and OAuth tokens." That is more than people expect, and it is why suspension is the right first move. Two caveats survive it, though. Resetting sign-in cookies "does not sign them out of apps, such as Gmail and Google Drive for desktop". And Google still lists revoking the user's OAuth 2.0 tokens as its own separate step in the same procedure — so treat suspension as containment, not as a completed revocation.

A password change is a separate credential change. Google documents its effect plainly: "the password change invalidates access tokens as well as refresh tokens." Two exceptions are documented and both matter in a compromise. Applications built on Apps Script are not included, even when the script accesses mail — and a malicious Apps Script trigger is a well-worn persistence technique. Gmail IMAP sessions are unaffected by the password change and expire only when their access token does.

App passwords are the one the documentation will not settle for you. Google currently says two different things. Its page on token revocation at password change says, of App Passwords, "Currently, there is no impact." Its page on resetting a user's password says "After a password reset, all ASPs are revoked and need to be regenerated" — ASP being the older name for the same credential. Both are live Google Workspace Admin Help pages, and they contradict each other.

You do not have to resolve that, and an incident is the wrong time to try. These are long-lived credentials that bypass the normal sign-in flow, and they are exactly the kind of thing left behind deliberately. Google's own compromised-account procedure lists "Remove App passwords that the user created" as a step in its own right. Review them and remove them explicitly, whatever you believe the password reset did.

So: do all of it. The controls overlap, but no single action should be assumed to have cleaned up every access or persistence mechanism. In particular, review the authorized OAuth applications explicitly rather than concluding from a suspension or a password reset that nothing is left — the point of the review is to find what was authorized, which tells you what the attacker set up, not merely to revoke it. In the Admin Console this lives under the user's Security section, in Connected Applications.

Then find the persistence

Once access is cut, look for what was left behind. In rough order of how often it turns up:

Mail filters. The classic. A rule that forwards everything matching a keyword, or — nastier — one that immediately archives and marks as read anything containing "invoice", "password", or the name of your finance officer, so the real user never sees the replies to what was sent from their account. Google's end-user security checklist tells people to confirm that

all your end-user filters and forwarding options are configured appropriately

which is a mild way of describing the most common backdoor there is.

Forwarding. Distinct from filters, configured elsewhere, and easy to miss if you only checked one of the two.

Delegation. If the attacker granted mailbox delegation to another account, that access persists and is not visible from the delegate's side of your admin view. Check what the compromised account granted, and separately, what it holds over anyone else's mailbox.

Connected applications. Covered above as a revocation step, but worth a second pass afterwards — you are looking for anything authorized around the time of the compromise, not just anything obviously malicious.

Recovery details and 2-step verification. A changed recovery phone or email, or a newly enrolled second factor, is a route back in that survives everything else you have done. This is the one people forget, and it is the one that turns a single incident into a recurring one.

Then work out the blast radius

Sign-in history. User log events hold sign-ins going back six months, which is usually far enough to answer "when did this actually start" — and the answer is frequently much earlier than the day somebody noticed.

Was the account an administrator? If so, review the admin audit log for configuration changes. An attacker with admin rights may have created accounts, changed sharing defaults, altered routing, or granted themselves roles. That is a materially bigger incident and should be treated as one.

Did it spread? Internal phishing from a real, trusted colleague's account converts far better than external phishing. Search delivery logs for what went out, and to whom, before you assume this was contained to one account.

What did they read? Drive, Calendar, and Groups log events exist for this. Availability varies by edition, and any statement about which logs you have should be checked against yours rather than assumed.

Cleaning up what was sent

If a message went to hundreds of internal recipients, removing it from mailboxes is a real capability that Google provides to administrators — but whether you have it depends on your edition. Domain-wide mail search and message remediation belong to the Security Investigation Tool, which is not available in every Google Workspace for Education edition. Find out which tier you are on before an incident, not during one: discovering mid-response that the button you were counting on is not there is a bad way to spend an afternoon.

Be careful here. Deleting mail from other people's mailboxes is a serious action with obvious potential for mistakes and for legitimate objection, and in a district it may intersect with records retention obligations. Know what your tooling actually does — whether it deletes the specific message by identifier or matches on a query — and prefer to review before acting rather than after.

K-12 specifics

Student accounts fail differently. Alongside external credential theft, consider credential sharing, passwords known by peers, and unattended signed-in devices. The technical response is the same; the follow-up is often a counseling matter rather than a technical one.

Parent-facing damage is the real cost. A staff account sending fraud to a parent distribution list is a communications incident before it is a security one. Have somebody drafting the notification while you are containing.

Shared devices complicate "sign out everywhere". A signed-in session on a library Chromebook is an access route that does not appear in any admin list as belonging to the compromised user.

Do not assume a single account. If credentials came from a phishing page, others in the same building may have entered theirs too. Look for the same pattern elsewhere before you close the incident.

What not to do

Do not delete the account. It destroys the evidence you are about to need, and it starts a twenty-day clock. Suspension achieves containment without any of that.

Do not reset the password and stop. Apps Script grants survive it, and what it does to app passwords is genuinely unsettled in Google's documentation — so go and remove those yourself rather than inferring it.

Do not skip the recovery details. Everything else you did is undone by an attacker who can still receive the reset code.

Do not treat "the sending stopped" as resolution. It stopped because you suspended the account.

Do not close it out without checking whether it started earlier than you think. Six months of sign-in data is there specifically so you do not have to guess.

Afterwards

Document what you found and when — dates, what was changed, what was removed, what you concluded about spread. If this ever becomes a data protection matter, that record is the difference between a manageable conversation and an unmanageable one.

Then treat the underlying cause rather than the account: if this was phishing that got past your filtering, one account is a sample, not the population. Strong second factors are the intervention that actually moves the needle, and they are considerably easier to justify to leadership the week after an incident than the week before.

Sources

A compromised account is not a product problem and no tool replaces the investigation. What tooling should do is make the containment steps fast and make sure none of them is skipped at four in the afternoon. What ORINEX Workspace does.