Google Workspace MFA unenrolled
A Google Workspace administrator removed an account's second factor.
What it detects
A Google Workspace administrator removed an account's second factor.
UNENROLL_USER_FROM_STRONG_AUTH takes a protected account back to password-only. Nothing is created, no role is granted, and the account keeps working normally — the only change is that the control standing between a stolen password and the mailbox is gone. It is the cheapest possible persistence for an attacker who already holds an admin session, and the easiest to miss, because the tenant's MFA policy still reports as enabled.
Deliberately high confidence and single-event. Un-enrolling someone else's second factor is a deliberate administrative act with no accidental version, and it is rare enough in a healthy tenant that seeing each one is the right posture.
MITRE ATT&CK mapping
False positives and triage
Helpdesks do this legitimately, and often — someone loses a phone, and getting them working again means clearing the enrolment so they can re-register. That is the majority case and it has a ticket behind it.
Three things separate the other kind. WHO ran it: an account that administers Workspace every day is different from one that has never touched this setting. WHOSE factor was cleared: an executive, a finance account or another administrator raises the stakes sharply. And WHAT FOLLOWED: a genuine reset is followed within minutes by the same user re-enrolling from their own device, while this technique is followed by a sign-in and then nothing — the second factor is simply never put back. An account left password-only for days after an "accidental" reset is the finding, whatever the ticket says.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 80%. Source: rules/cloud/gws_mfa_unenrolled.yaml, licensed under the Apache License 2.0.
id: cloud.gws.mfa_unenrolled
version: 1.0.0
status: stable
severity: critical
confidence: 0.8
platforms: [application]
mitre_techniques: [T1556.006, T1098]
description: |
A Google Workspace administrator removed an account's second factor.
`UNENROLL_USER_FROM_STRONG_AUTH` takes a protected account back to
password-only. Nothing is created, no role is granted, and the account keeps
working normally — the only change is that the control standing between a stolen
password and the mailbox is gone. It is the cheapest possible persistence for an
attacker who already holds an admin session, and the easiest to miss, because
the tenant's MFA policy still reports as enabled.
Deliberately high confidence and single-event. Un-enrolling someone else's
second factor is a deliberate administrative act with no accidental version, and
it is rare enough in a healthy tenant that seeing each one is the right posture.
match:
provider: GoogleWorkspace
event_action_contains_any:
- UNENROLL_USER_FROM_STRONG_AUTH
- UNENROLL_USER_FROM_TITANIUM_STRONG_AUTH
- TURN_OFF_2_STEP_VERIFICATION
- ALLOW_STRONG_AUTHENTICATION
correlation_keys: [user_name, target_user_name]
false_positive_guidance: |
Helpdesks do this legitimately, and often — someone loses a phone, and getting
them working again means clearing the enrolment so they can re-register. That is
the majority case and it has a ticket behind it.
Three things separate the other kind. WHO ran it: an account that administers
Workspace every day is different from one that has never touched this setting.
WHOSE factor was cleared: an executive, a finance account or another
administrator raises the stakes sharply. And WHAT FOLLOWED: a genuine reset is
followed within minutes by the same user re-enrolling from their own device,
while this technique is followed by a sign-in and then nothing — the second
factor is simply never put back. An account left password-only for days after an
"accidental" reset is the finding, whatever the ticket says.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.