Detection rules › Panther
GSuite User Two Step Verification Change
A user disabled two step verification for themselves.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Persistence | T1556 Modify Authentication Process |
| Defense Impairment | T1556 Modify Authentication Process |
| Credential Access | T1556 Modify Authentication Process |
Rule body yaml
AnalysisType: rule
Filename: gsuite_two_step_verification.py
RuleID: "GSuite.TwoStepVerification"
DisplayName: "GSuite User Two Step Verification Change"
Enabled: true
LogTypes:
- GSuite.ActivityEvent
Tags:
- GSuite
- Defense Evasion:Modify Authentication Process
Reports:
MITRE ATT&CK:
- TA0005:T1556
Severity: Low
Description: >
A user disabled two step verification for themselves.
Reference: https://support.google.com/mail/answer/185839?hl=en&co=GENIE.Platform%3DDesktop&sjid=864417124752637253-EU
Runbook: >
Depending on company policy, either suggest or require the user re-enable two step verification.
SummaryAttributes:
- actor:email
Tests:
- Name: Two Step Verification Enabled
ExpectedResult: false
Log:
{
"id": { "applicationName": "user_accounts" },
"actor": { "callerType": "USER", "email": "some.user@somedomain.com" },
"kind": "admin#reports#activity",
"type": "2sv_change",
"name": "2sv_enroll",
}
- Name: Two Step Verification Disabled
ExpectedResult: True
Log:
{
"id": { "applicationName": "user_accounts" },
"actor": { "callerType": "USER", "email": "some.user@somedomain.com" },
"kind": "admin#reports#activity",
"type": "2sv_change",
"name": "2sv_disable",
}
Detection logic
Condition
id.applicationName eq "user_accounts"
type eq "2sv_change"
name eq "2sv_disable"
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 |
|---|---|---|
id.applicationName | eq |
|
name | eq |
|
type | eq |
|
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.
| Field | Source |
|---|---|
email | actor.email |