detection.wiki

Detection rules › Panther

GSuite User Device Unlock Failures

Severity
medium
Log types
GSuite.ActivityEvent
Tags
GSuite, Credential Access:Brute Force
Reference
https://support.google.com/a/answer/6350074?hl=en
Source
github.com/panther-labs/panther-analysis

Someone failed to unlock a user's device multiple times in quick succession.

MITRE ATT&CK coverage

TacticTechniques
Credential AccessT1110 Brute Force

Rule body yaml

AnalysisType: rule
Filename: gsuite_mobile_device_screen_unlock_fail.py
RuleID: "GSuite.DeviceUnlockFailure"
DisplayName: "GSuite User Device Unlock Failures"
Enabled: true
LogTypes:
  - GSuite.ActivityEvent
Tags:
  - GSuite
  - Credential Access:Brute Force
Reports:
  MITRE ATT&CK:
    - TA0006:T1110
Severity: Medium
Description: >
  Someone failed to unlock a user's device multiple times in quick succession.
Reference: https://support.google.com/a/answer/6350074?hl=en
Runbook: >
  Verify that these unlock attempts came from the user, and not a malicious actor which has acquired the user's device.
SummaryAttributes:
  - actor:email
Tests:
  - Name: Normal Mobile Event
    ExpectedResult: false
    Log:
      {
        "id": { "applicationName": "mobile" },
        "actor": { "callerType": "USER", "email": "homer.simpson@example.io" },
        "type": "device_updates",
        "name": "DEVICE_SYNC_EVENT",
        "parameters": { "USER_EMAIL": "homer.simpson@example.io" },
      }
  - Name: Small Number of Failed Logins
    ExpectedResult: false
    Log:
      {
        "id": { "applicationName": "mobile" },
        "actor": { "callerType": "USER", "email": "homer.simpson@example.io" },
        "type": "device_updates",
        "name": "FAILED_PASSWORD_ATTEMPTS_EVENT",
        "parameters":
          {
            "USER_EMAIL": "homer.simpson@example.io",
            "FAILED_PASSWD_ATTEMPTS": 2,
          },
      }
  - Name: Multiple Failed Login Attempts with int Type
    ExpectedResult: true
    Log:
      {
        "id": { "applicationName": "mobile" },
        "actor": { "callerType": "USER", "email": "homer.simpson@example.io" },
        "type": "device_updates",
        "name": "FAILED_PASSWORD_ATTEMPTS_EVENT",
        "parameters":
          {
            "USER_EMAIL": "homer.simpson@example.io",
            "FAILED_PASSWD_ATTEMPTS": 100,
          },
      }
  - Name: Multiple Failed Login Attempts with String Type
    ExpectedResult: true
    Log:
      {
        "id": { "applicationName": "mobile" },
        "actor": { "callerType": "USER", "email": "homer.simpson@example.io" },
        "type": "device_updates",
        "name": "FAILED_PASSWORD_ATTEMPTS_EVENT",
        "parameters":
          {
            "USER_EMAIL": "homer.simpson@example.io",
            "FAILED_PASSWD_ATTEMPTS": "100",
          },
      }

Detection logic

Condition

id.applicationName eq "mobile"
name eq "FAILED_PASSWORD_ATTEMPTS_EVENT"

This rule also runs imperative logic the parser cannot express as a filter; the conditions above are the structured part it could extract.

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.

FieldKindValues
id.applicationNameeq
  • mobile
nameeq
  • FAILED_PASSWORD_ATTEMPTS_EVENT

Output fields

Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.

FieldSource
emailactor.email