detection.wiki

Detection rules › Panther

GSuite Login Type

Severity
medium
Log types
GSuite.ActivityEvent
Tags
GSuite, Configuration Required, Initial Access:Valid Accounts
Reference
https://support.google.com/a/answer/9039184?hl=en&sjid=864417124752637253-EU
Source
github.com/panther-labs/panther-analysis

A login of a non-approved type was detected for this user.

MITRE ATT&CK coverage

TacticTechniques
Initial AccessT1078 Valid Accounts

Rule body yaml

AnalysisType: rule
Filename: gsuite_login_type.py
RuleID: "GSuite.LoginType"
DisplayName: "GSuite Login Type"
Enabled: false
LogTypes:
  - GSuite.ActivityEvent
Tags:
  - GSuite
  - Configuration Required
  - Initial Access:Valid Accounts
Reports:
  MITRE ATT&CK:
    - TA0001:T1078
Severity: Medium
Description: >
  A login of a non-approved type was detected for this user.
Reference: https://support.google.com/a/answer/9039184?hl=en&sjid=864417124752637253-EU
Runbook: >
  Correct the user account settings so that only logins of approved types are available.
SummaryAttributes:
  - actor:email
Tests:
  - Name: Login With Approved Type
    ExpectedResult: false
    Log:
      {
        "id": { "applicationName": "login" },
        "actor": { "email": "some.user@somedomain.com" },
        "type": "login",
        "name": "login_success",
        "parameters": { "login_type": "saml" },
      }
  - Name: Login With Unapproved Type
    ExpectedResult: true
    Log:
      {
        "id": { "applicationName": "login" },
        "actor": { "email": "some.user@somedomain.com" },
        "type": "login",
        "name": "login_success",
        "parameters": { "login_type": "turbo-snail" },
      }
  - Name: Non-Login event
    ExpectedResult: false
    Log:
      {
        "id": { "applicationName": "logout" },
        "actor": { "email": "some.user@somedomain.com" },
        "type": "login",
        "name": "login_success",
        "parameters": { "login_type": "saml" },
      }
  - Name: Saml Login Event
    ExpectedResult: false
    Log:
      {
        "actor": { "email": "some.user@somedomain.com" },
        "id":
          {
            "applicationName": "saml",
            "time": "2022-05-26 15:26:09.421000000",
          },
        "ipAddress": "10.10.10.10",
        "kind": "admin#reports#activity",
        "name": "login_success",
        "parameters":
          {
            "application_name": "Some SAML Application",
            "initiated_by": "sp",
            "orgunit_path": "/SomeOrgUnit",
            "saml_status_code": "SUCCESS_URI",
          },
        "type": "login",
      }

Detection logic

Condition

type eq "login"
name ne "logout"
not (parameters.login_type in ["exchange", "google_password", "reauth", "saml"] or id.applicationName in "saml")

Exclusions

Top-level NOT(...) conjuncts: predicates this rule actively suppresses.

FieldKindExcluded values
id.applicationNameeqsaml
parameters.login_typeinexchange, google_password, reauth, saml

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
namene
  • logout
typeeq
  • login

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