Google Workspace User Login with Unusual ASN

  1[metadata]
  2creation_date = "2026/05/14"
  3integration = ["google_workspace"]
  4maturity = "production"
  5updated_date = "2026/05/14"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects the first time a Google Workspace user successfully signs in from a given source ASN within a 14-day historical
 11window. Most users have a stable set of egress ASNs (home ISP, corporate VPN, mobile carrier). A new ASN for a user is a
 12meaningful anomaly as it surfaces ISP changes and travel, but also catches AiTM phishing-kit relays whose egress ASN was
 13never previously associated with the user.
 14"""
 15false_positives = [
 16    """
 17    Legitimate first-time use of a new network: ISP change, new VPN provider, travel to a region using a different
 18    mobile carrier, new home office.
 19    """,
 20    """
 21    Carrier-grade NAT or load-balanced corporate egress that occasionally routes through alternate ASNs.
 22    """
 23]
 24from = "now-130m"
 25index = ["logs-google_workspace.login*", "logs-google_workspace.token*"]
 26interval = "10m"
 27language = "kuery"
 28license = "Elastic License v2"
 29name = "Google Workspace User Login with Unusual ASN"
 30note = """## Triage and analysis
 31
 32### Investigating Google Workspace User Login with Unusual ASN
 33
 34This rule emits when a user signs in successfully from an ASN that has not been observed for that user in the prior 14 days. Most legitimate users cluster around a small number of egress ASNs (corporate VPN, home ISP, primary mobile carrier). New ASNs are not all malicious, but new ASNs that match hosting providers, anonymization networks, or geographies inconsistent with the user's profile are high-fidelity suspicious.
 35
 36### Possible investigation steps
 37
 38- Inspect `source.as.organization.name` and `source.as.number`. Categorize: residential ISP (low concern absent other indicators), corporate VPN (validate against tenant baseline), mobile carrier (validate by region), hosting provider / VPS (Clouvider, Host Telecom, Alibaba, OVH, M247, DigitalOcean, Vultr) - high concern for interactive sign-ins.
 39- Inspect `source.geo.country_name` and `source.geo.region_name`. New geo + known travel is fine. New geo + unexpected travel needs user confirmation.
 40- Pull the user's full `google_workspace.login` history across the lookback. Is this a one-off sign-in or sustained activity from the new ASN?
 41- Cross-reference `logs-google_workspace.token` for any `event.action: "authorize"` events from the same `user.email` immediately following the sign-in. An OAuth grant minted from the new ASN within seconds of sign-in is the AiTM kit signature.
 42- Cross-reference `logs-google_workspace.device` for any `DEVICE_REGISTER_UNREGISTER_EVENT` with `account_state: "REGISTERED"` from the same user near the same time. New device + new ASN is a stronger compromise signal than either alone.
 43- Confirm with the user whether they signed in from a new network intentionally.
 44
 45### False positive analysis
 46
 47- Users on rotating VPN exits, hotspot sharing, or coffee-shop Wi-Fi will produce new ASNs legitimately.
 48- Mobile users in unfamiliar regions (travel, conference attendance) will geo-resolve to new ASNs.
 49- Engineering teams using cloud workstations (Cloud Workstations, Codespaces, etc.) will egress through hosting ASNs even for legitimate sign-ins. Tune by allowlisting your tenant's known cloud-workstation egress.
 50- For high-noise tenants, expand `history_window_start` to 14 days to reduce false-positive rate at the cost of slower-to-fire detection for genuinely new ASNs.
 51
 52### Response and remediation
 53
 54- If the new ASN is a hosting provider and the user has not knowingly used such a network: treat as likely AiTM. Suspend user, revoke OAuth tokens, reset password, clear recovery info, sign out all sessions.
 55- If the new ASN is benign (verified ISP change, travel, new VPN): add to the user's baseline. Consider broader hardening (require MFA re-verification on new-network sign-in via Workspace Context-Aware Access).
 56"""
 57references = [
 58    "https://any.run/malware-trends/tycoon/",
 59    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
 60]
 61risk_score = 21
 62rule_id = "1f489c86-d9c4-40de-9316-931721ca9b45"
 63setup = """## Setup
 64
 65### Important Information Regarding Google Workspace Event Lag Times
 66- Google Workspace Reports API ingestion lag commonly runs in the 30-minute to 3-hour range. This rule's 130-minute lookback gives partial coverage but will miss events delayed beyond that envelope.
 67- See https://support.google.com/a/answer/7061566 for Google's published guidance on event availability.
 68- Check your integration's Login lag time to ensure it is configured to meet the needs of this rule.
 69"""
 70severity = "low"
 71tags = [
 72    "Domain: Cloud",
 73    "Domain: Identity",
 74    "Data Source: Google Workspace",
 75    "Data Source: Google Workspace Audit Logs",
 76    "Data Source: Google Workspace User Log Events",
 77    "Use Case: Threat Detection",
 78    "Use Case: Identity and Access Audit",
 79    "Tactic: Initial Access",
 80    "Tactic: Credential Access",
 81    "Resources: Investigation Guide",
 82]
 83timestamp_override = "event.ingested"
 84type = "new_terms"
 85
 86query = '''
 87data_stream.dataset: ("google_workspace.login" or "google_workspace.token") and
 88    event.action: ("login_success" or "authorize") and
 89    source.as.number: * and
 90    user.email: *
 91'''
 92
 93
 94[[rule.threat]]
 95framework = "MITRE ATT&CK"
 96[[rule.threat.technique]]
 97id = "T1078"
 98name = "Valid Accounts"
 99reference = "https://attack.mitre.org/techniques/T1078/"
100[[rule.threat.technique.subtechnique]]
101id = "T1078.004"
102name = "Cloud Accounts"
103reference = "https://attack.mitre.org/techniques/T1078/004/"
104
105
106
107[rule.threat.tactic]
108id = "TA0001"
109name = "Initial Access"
110reference = "https://attack.mitre.org/tactics/TA0001/"
111[[rule.threat]]
112framework = "MITRE ATT&CK"
113[[rule.threat.technique]]
114id = "T1528"
115name = "Steal Application Access Token"
116reference = "https://attack.mitre.org/techniques/T1528/"
117
118[[rule.threat.technique]]
119id = "T1557"
120name = "Adversary-in-the-Middle"
121reference = "https://attack.mitre.org/techniques/T1557/"
122
123
124[rule.threat.tactic]
125id = "TA0006"
126name = "Credential Access"
127reference = "https://attack.mitre.org/tactics/TA0006/"
128
129[rule.investigation_fields]
130field_names = [
131    "@timestamp",
132    "user.email",
133    "user.name",
134    "source.ip",
135    "source.as.number",
136    "source.as.organization.name",
137    "source.geo.country_name",
138    "source.geo.region_name",
139    "google_workspace.login.type",
140    "google_workspace.login.challenge_method",
141]
142
143[rule.new_terms]
144field = "new_terms_fields"
145value = ["user.email", "source.as.number"]
146[[rule.new_terms.history_window_start]]
147field = "history_window_start"
148value = "now-7d"