Google Workspace Suspicious Login and 2SV Changes: A Guide
Investigate a Google Workspace suspicious login: is_suspicious, hosting ASNs, new countries, impossible travel, failed-login bursts, 2SV and recovery changes.
TL;DR. In the Login (User) log, check four signals for the suspected account: Google's own flag (suspicious_login, is_suspicious=true, account-disabled warnings), a successful sign-in from a hosting ASN, a new country or impossible travel, and bursts of failures. Then check what the session did to the account: 2sv_disable, recovery_email_edit, recovery_phone_edit. A successful sign-in from a VPS right after the user clicked a link is the footprint of adversary-in-the-middle phishing.
The sign-in is where the timeline of a Workspace compromise starts, and usually where its only clear network indicators are. This post covers what the Login log records, how to read it, and where the pitfalls are.
What the Login log records
The Login (and user accounts) events are documented in Google's Login audit activity events appendix. The ones that matter for a takeover:
| Event | Meaning |
|---|---|
login_success, login_failure | Sign-in outcome, with login_type, login_challenge_method, is_suspicious |
login_challenge, login_verification | 2SV or risk challenge presented / passed |
suspicious_login, suspicious_login_less_secure_app, suspicious_programmatic_login | Google's risk engine blocked or flagged the attempt |
user_signed_out_due_to_suspicious_session_cookie | Google detected a suspicious session cookie and signed the user out |
account_disabled_password_leak, account_disabled_hijacked, gov_attack_warning | Account warnings |
risky_sensitive_action_allowed / _blocked | A sensitive action after a risky sign-in |
2sv_disable, 2sv_enroll, titanium_unenroll, passkey_removed | 2SV and Advanced Protection changes |
recovery_email_edit, recovery_phone_edit, password_edit | Account recovery and password changes |
Every record also carries the IP address. In the Reports API, it also carries networkInfo with the IP's ASN and a region code. That network data is what makes the next three checks possible.
Signal 1: Google already flagged it
Start with the cheapest evidence. Google's own risk engine decides when a sign-in is "outside the normal pattern" (about suspicious login alerts). A login_success with is_suspicious = true means the attempt went through anyway. user_signed_out_due_to_suspicious_session_cookie is particularly interesting in AiTM cases: the session was stolen, and Google noticed.
These flags aren't exhaustive. Many AiTM sign-ins are not flagged, because the victim really did pass the challenge.
Signal 2: a hosting network
AiTM kits (Evilginx-style reverse proxies) sit between the victim and Google. The victim types the password and approves the prompt on the proxied page. Google sees the sign-in coming from the proxy's server, typically a VPS at DigitalOcean, OVH, Hetzner, Vultr, AWS and similar. MITRE tracks this as T1557 Adversary-in-the-Middle, leading to T1078.004 Cloud Accounts.
The analyzer checks the ASN of each successful sign-in (and SAML sign-in) against a reviewed list of hosting providers and flags matches as high severity. Before you escalate, rule out your own infrastructure: corporate VPN concentrators, cloud-hosted virtual desktops and security proxies all egress from these networks.
Signal 3: geography
- New country. After a baseline of at least three sign-ins from known countries, a success from a country never seen for that user. Medium severity alone: people travel.
- Impossible travel. Two successful sign-ins whose countries are more than 500 km apart at an implied speed above 900 km/h. One of the two sessions is not the user, or a VPN is involved.
Both depend on a region code per event. The Reports API provides it. Many console CSV exports don't. Without it, these checks can't run. See audit log limitations.
Signal 4: failure bursts
Ten or more login_failure events in ten minutes against one account point to password guessing or spraying (T1110). On its own, that's a medium finding. It becomes important when a success from the same IP follows.
Then: what did the session change?
After the sign-in, attackers make their access durable:
2sv_disable(ortitanium_unenrollfor Advanced Protection) makes the next sign-in easier. MITRE: T1556.006 Multi-Factor Authentication. An admin can do the same through the Admin log (TURN_OFF_2_STEP_VERIFICATION,UNENROLL_USER_FROM_STRONG_AUTH).recovery_email_edit/recovery_phone_editlet the attacker take the account back after you reset the password. Always check the new values with the user.
The analyzer flags both families and, if they follow a risky sign-in on the same account, raises the "risky sign-in → security change" chain to critical.
Why 2SV didn't stop it, and what does
SMS codes, authenticator codes and phone prompts are all relayable: the victim completes them on the attacker's proxy. Phishing-resistant methods (security keys and passkeys based on FIDO2/WebAuthn) are bound to the real origin and don't work through a proxy. CISA's phishing-resistant MFA fact sheet explains the difference. Google lets admins enforce security keys per organizational unit or group. Start with finance and admins. See also 2-step verification.
Response
- Reset the user's sign-in cookies to kill the stolen session.
- Check what followed: OAuth grants, forwarding, filters. See the investigation guide.
- Reset the password after removing persistence, and restore 2SV and the recovery options.
- Pivot on the attacker's IPs in the analyzer's Entities tab to find other accounts they reached.
Next in this series: Gmail forwarding rules set by attackers. If your Workspace signs in through Okta, the IdP side of the same sign-in is covered on oktaforensics.com.
FAQ
Why did an attacker get in despite 2-step verification?
Adversary-in-the-middle phishing kits proxy the real Google sign-in page. The victim enters the password and approves the prompt or types the code, and the kit keeps the resulting session. Only phishing-resistant methods such as security keys and passkeys are bound to the real site and resist this.
Is a login from a VPS or cloud provider always malicious?
No. Corporate VPNs, secure web gateways and some remote-desktop services egress from cloud networks. Confirm the IP against your own infrastructure first. For an ordinary user with no such setup, a successful sign-in from a hosting provider is a strong takeover signal.