This rule detects when a Google Workspace user signs in from a source ASN that has not been observed for that user in the prior 14 days. It uses historical ASN baselines to surface anomalies that may indicate travel, ISP changes, or adversary activity such as AiTM relays. The detection queries logs-google_workspace.login and logs-google_workspace.token to identify successful logins and OAuth authorizations, focusing on a 130-minute window with a 14-day historical context for the user. The rule triggers on a new ASN for the user (new_terms: user.email + source.as.number) that isn’t present in the user’s 14-day history, and it surfaces related indicators such as immediate token authorization events and new device registrations. Correlation with geographic data (source.geo.country_name, source.geo.region_name) helps distinguish legitimate travel from suspicious activity. The rule maps to MITRE ATT&CK Initial Access (T1078 and T1078.004 Cloud Accounts) and Credential Access (T1528, T1557) through cross-references to token events and potential AiTM usage. Investigation_fields include relevant fields like user.email, source.as.number, and source.geo.* to aid triage. False positives include legitimate ISP changes, travel, or corporate NAT that routes through different ASNs, and cloud-workstation egress. Triage steps suggest validating the ASN against the tenant baseline, reviewing the user’s full login history, checking for subsequent authorize events, and verifying any new devices. Remediation for likely AiTM or risk is to suspend the user, revoke OAuth tokens, reset passwords, clear recovery info, and sign out all sessions; if the ASN is benign, add it to the user’s baseline and consider re-verifying MFA on new networks.