MFA denied then approved
Two multi-factor challenges refused, then one accepted, for the same account.
What it detects
Two multi-factor challenges refused, then one accepted, for the same account.
This is the quiet version of push bombing, and the one a volume threshold cannot see. An attacker who sends thirty prompts is loud; an attacker who sends three and waits looks like nothing at all. What gives both away is the SHAPE rather than the count — a person who denies a prompt has decided it was not them, and a decision like that does not usually reverse twice in ten minutes.
Deliberately vendor-neutral. It matches on the normalized category and outcome rather than a provider string, so it works on Okta, Entra and Google Workspace alike. That matters more than the technique: the pack's other MFA-fatigue rule is provider: AzureAD, which means a customer on Okta or Workspace has had no MFA-fatigue detection at all, whatever their volume.
MITRE ATT&CK mapping
False positives and triage
Mistyped codes are the benign twin: a user fumbles a TOTP twice and gets it right on the third go, which is exactly this shape. Two denials is the threshold because one is routine; it is not proof.
Separate them on ADDRESS and INTERVAL. A fumbled code is three attempts from one place inside a minute; this technique is prompts arriving over minutes, often with the attempts originating somewhere the user is not. Compare the source of the failures with the source of the success — if they differ, the person who approved and the person who asked are not the same, which is the whole finding. Then ask the user. An approval they do not remember making means the attacker already had the password, so the response is the account, not the prompt.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/mfa_denied_then_approved.yaml, licensed under the Apache License 2.0.
id: multi.authentication.mfa_denied_then_approved
version: 1.0.0
status: stable
severity: critical
confidence: 0.7
platforms: [application]
mitre_techniques: [T1621, T1078]
description: |
Two multi-factor challenges refused, then one accepted, for the same account.
This is the quiet version of push bombing, and the one a volume threshold
cannot see. An attacker who sends thirty prompts is loud; an attacker who sends
three and waits looks like nothing at all. What gives both away is the SHAPE
rather than the count — a person who denies a prompt has decided it was not
them, and a decision like that does not usually reverse twice in ten minutes.
Deliberately vendor-neutral. It matches on the normalized category and outcome
rather than a provider string, so it works on Okta, Entra and Google Workspace
alike. That matters more than the technique: the pack's other MFA-fatigue rule
is `provider: AzureAD`, which means a customer on Okta or Workspace has had no
MFA-fatigue detection at all, whatever their volume.
sequence:
# Ten minutes: long enough to cover a real prompt-and-wait cadence, short enough
# that a denial in the morning and a sign-in after lunch are not joined up.
within_seconds: 600
group_by: [user_name]
order: strict
steps:
- id: challenge_refused
match:
event_category: authentication
event_outcome: failure
event_action_contains_any: [mfa, factor, strong_auth, verify]
- id: challenge_refused_again
match:
event_category: authentication
event_outcome: failure
event_action_contains_any: [mfa, factor, strong_auth, verify]
- id: challenge_accepted
match:
event_category: authentication
event_outcome: success
correlation_keys: [user_name, source_ip]
false_positive_guidance: |
Mistyped codes are the benign twin: a user fumbles a TOTP twice and gets it
right on the third go, which is exactly this shape. Two denials is the threshold
because one is routine; it is not proof.
Separate them on ADDRESS and INTERVAL. A fumbled code is three attempts from one
place inside a minute; this technique is prompts arriving over minutes, often
with the attempts originating somewhere the user is not. Compare the source of
the failures with the source of the success — if they differ, the person who
approved and the person who asked are not the same, which is the whole finding.
Then ask the user. An approval they do not remember making means the attacker
already had the password, so the response is the account, not the prompt.
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.