GCP Unusual Number of Failed Authentications From Ip

Status: production
Severity: low
Group by: _time, src
Author: Bhavin Patel, Splunk
Source: github.com/splunk/security_content

The following analytic identifies a single source IP failing to authenticate into Google Workspace with multiple valid users, potentially indicating a Password Spraying attack. It uses Google Workspace login failure events and calculates the standard deviation for source IPs, applying the 3-sigma rule to detect unusual failed authentication attempts. This activity is significant as it may signal an adversary attempting to gain initial access or elevate privileges. If confirmed malicious, this could lead to unauthorized access, data breaches, or further exploitation within the environment.

MITRE ATT&CK coverage

Tactic	Techniques
Resource Development	`T1586.003` Compromise Accounts: Cloud Accounts
Credential Access	`T1110.003` Brute Force: Password Spraying, `T1110.004` Brute Force: Credential Stuffing

Rules detecting the same action

Other rules on this platform that filter on the same API call or operation.

GCP Authentication Failed During MFA Challenge (Splunk)
GCP Multiple Failed MFA Requests For User (Splunk)
GCP Multiple Users Failing To Authenticate From Ip (Splunk)

Rule body splunk

name: GCP Unusual Number of Failed Authentications From Ip
id: bd8097ed-958a-4873-87d9-44f2b4d85705
version: 11
creation_date: '2022-09-26'
modification_date: '2026-05-13'
author: Bhavin Patel, Splunk
status: production
type: Anomaly
description: The following analytic identifies a single source IP failing to authenticate into Google Workspace with multiple valid users, potentially indicating a Password Spraying attack. It uses Google Workspace login failure events and calculates the standard deviation for source IPs, applying the 3-sigma rule to detect unusual failed authentication attempts. This activity is significant as it may signal an adversary attempting to gain initial access or elevate privileges. If confirmed malicious, this could lead to unauthorized access, data breaches, or further exploitation within the environment.
data_source:
    - Google Workspace
search: |-
    `gws_reports_login` event.type = login event.name = login_failure
      | bucket span=5m _time
      | stats  dc(user_name) AS unique_accounts values(user_name) as tried_accounts values(authentication_method) AS authentication_method
        BY _time, src
      | eventstats  avg(unique_accounts) as ip_avg , stdev(unique_accounts) as ip_std
        BY _time
      | eval  upperBound=(ip_avg+ip_std*3)
      | eval  isOutlier=if(unique_accounts > 10 and unique_accounts >= upperBound, 1, 0)
      | where isOutlier =1
      | `gcp_unusual_number_of_failed_authentications_from_ip_filter`
how_to_implement: You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. We would also recommend tuning the detection by adjusting the window `span` and `unique_accounts` threshold values according to your environment. Specifically, this analytic leverages the User log events.
known_false_positives: No known false positives for this detection. Please review this alert
references:
    - https://cloud.google.com/blog/products/identity-security/how-google-cloud-can-help-stop-credential-stuffing-attacks
    - https://www.slideshare.net/dafthack/ok-google-how-do-i-red-team-gsuite
    - https://attack.mitre.org/techniques/T1110/003/
    - https://www.blackhillsinfosec.com/wp-content/uploads/2020/05/Breaching-the-Cloud-Perimeter-Slides.pdf
drilldown_searches:
    - name: View the detection results for - "$tried_accounts$"
      search: '%original_detection_search% | search  tried_accounts = "$tried_accounts$"'
      earliest_offset: $info_min_time$
      latest_offset: $info_max_time$
    - name: View risk events for the last 7 days for - "$tried_accounts$"
      search: '| from datamodel Risk.All_Risk | search normalized_risk_object IN ("$tried_accounts$") | stats count min(_time) as firstTime max(_time) as lastTime values(search_name) as "Search Name" values(risk_message) as "Risk Message" values(analyticstories) as "Analytic Stories" values(annotations._all) as "Annotations" values(annotations.mitre_attack.mitre_tactic) as "ATT&CK Tactics" by normalized_risk_object | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`'
      earliest_offset: 7d
      latest_offset: "0"
intermediate_findings:
    entities:
        - field: tried_accounts
          type: user
          score: 20
          message: 'Unusual number of failed console login attempts (Count: $unique_accounts$) against users from IP Address - $src$'
threat_objects:
    - field: src
      type: ip_address
analytic_story:
    - GCP Account Takeover
asset_type: Google Cloud Platform tenant
mitre_attack_id:
    - T1110.003
    - T1110.004
    - T1586.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: threat
tests:
    - name: True Positive Test
      attack_data:
        - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1110.003/gcp_gws_multiple_login_failure/gws_login.json
          source: gws_login
          sourcetype: gws:reports:login
      test_type: unit

Stages and Predicates

Stage 1: `search`

`gws_reports_login` event.type = login event.name = login_failure

Stage 2: `bucket`

| bucket span=5m _time

Stage 3: `stats`

| stats  dc(user_name) AS unique_accounts values(user_name) as tried_accounts values(authentication_method) AS authentication_method
    BY _time, src

Stage 4: `eventstats`

| eventstats  avg(unique_accounts) as ip_avg , stdev(unique_accounts) as ip_std
    BY _time

Stage 5: `eval`

| eval  upperBound=(ip_avg+ip_std*3)

Stage 6: `eval`

| eval  isOutlier=if(unique_accounts > 10 and unique_accounts >= upperBound, 1, 0)

isOutlier =

ifunique_accounts > 10 AND unique_accounts >= upperBound1

else0

Stage 7: `where`

| where isOutlier =1

Stage 8: `search`

| `gcp_unusual_number_of_failed_authentications_from_ip_filter`

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

Field	Kind	Values
`event.name`	eq	`login_failure`
`event.type`	eq	`login`
`isOutlier`	eq	`1`
`sourcetype`	eq	`gws:reports:login`

`j` / `k`	Scroll down / up
`d` / `u`	Half-page down / up
`gg` / `G`	Top / bottom
`h` / `l`	History back / forward
`f`	Follow link (`Shift` = new tab)
`/`	Focus search
`?`	Toggle this help
`↑` / `↓`	Navigate search results
`Enter`	Open highlighted result
`Esc`	Close results / dialog

`type:`	`events` / `rules` / `providers`
`vendor:`	`sigma` / `elastic` / `splunk` / `kusto` / `chronicle` (vendor name alone also works: `sigma:`, `kql:`, `secops:`…)
`tactic:`	TA-id, slug, or name: `credential_access`, `TA0006`
`technique:`	technique or sub-technique ID: `T1003`, `T1003.001` (alias `tech:`)
`severity:`	`critical` / `high` / `medium` / `low` / `informational` (alias `sev:`)
`risk_score`	Numeric comparison on the Elastic risk score (0 to 100): `risk_score>50`, `risk_score<=20`, `risk_score=99` (alias `risk`; Elastic rules only)
`stages:`	Rules with exactly N pipeline stages
`correlation:`	`single_event` / `sequence` / `alternatives` / `alternatives_cross_log` / `all_required` / `correlated`
`with:`	Co-occurrence event-id; stacks (`with:4624 with:4769`) to require all, while a comma list in one occurrence (`with:4624,4769`) is an either-or group. Implies multi-event
`like:`	Structural neighbors of a rule slug (equivalents + subsumption stricter / broader): `like:comsvcs_lsass_memory_dump-splunk-sysmon`
`groupby:`	Entity-grouping substring match against `group_by_keys`: `groupby:user`, `groupby:host`
`uses:`	Rules whose predicate tree touches the field (any kind, any value): `uses:CommandLine`
`excludes:`	Rules with top-level `not()` clauses on the field (FP whitelists): `excludes:ParentImage`
`field:` / `value:`	Predicate search; narrows rule cards to those with a matching leaf and drives the indicator tier. Unquoted = substring, wildcards allowed (`value:mimikatz`)
`indicator:`	Shorthand for `field:F value:V`: `indicator:Image=*\powershell.exe`
`kind:`	Filter by predicate kind. Narrows rule cards to those carrying a matching predicate leaf (`vendor:elastic kind:cidr_match`) and drives the indicator tier: `contains` / `starts_with` / `ends_with` / `regex` / `cidr` / `eq` / `in` … (operator aliases `op:`/`match:`)
`has:` / `no:`	`sample`, `field`, `notes`, `refs`, `trace`, `thirdparty`, `rule`, `pattern`, `timewindow`, `threshold`, `newterms`, `sigma`/`elastic`/`splunk`/`kusto`/`chronicle`
`-op:val`	Exclude matches; works on most operators but not `type:`/`like:`/`has:`/`no:` (use `no:<flag>` to exclude a rule flag): `tactic:execution -vendor:splunk`. Standalone `-kind:`/`-field:`/`-value:` drop every rule carrying a matching predicate leaf (`type:rules -kind:is_null`)
`field:"…"` / `value:"…"`	Quoted value = anchored exact match (also allows spaces): `value:"net user"`
`a,b`	Comma = OR inside one operator (`vendor:sigma,elastic`, `severity:high,critical`); repeating a facet merges the same way. `field:`/`value:` never split (literal commas)
`vendors:` / `stage:`	Singular and plural spellings fold to the canonical operator and value: `tactics:` = `tactic:`, `type:event` = `type:events`, `correlation:sequences` = `correlation:sequence`, `has:thresholds` = `has:threshold`
`"quoted phrase"`	Exact-match a multi-word phrase (free text)

GCP Unusual Number of Failed Authentications From Ip

MITRE ATT&CK coverage

Rules detecting the same action

Rule body splunk

Stages and Predicates

Stage 1: `search`

Stage 2: `bucket`

Stage 3: `stats`

Stage 4: `eventstats`

Stage 5: `eval`

Stage 6: `eval`

Stage 7: `where`

Stage 8: `search`

Indicators

Keyboard shortcuts

Search operators

GCP Unusual Number of Failed Authentications From Ip

MITRE ATT&CK coverage

Rules detecting the same action

Rule body splunk

Stages and Predicates

Stage 1: search

Stage 2: bucket

Stage 3: stats

Stage 4: eventstats

Stage 5: eval

Stage 6: eval

Stage 7: where

Stage 8: search

Indicators

Stage 1: `search`

Stage 2: `bucket`

Stage 3: `stats`

Stage 4: `eventstats`

Stage 5: `eval`

Stage 6: `eval`

Stage 7: `where`

Stage 8: `search`