Okta MFA push bombing
Okta sent a burst of verification pushes to one account.
What it detects
Okta sent a burst of verification pushes to one account.
Push bombing works on attrition. The attacker already has the password; what stands between them and the account is a prompt on someone's phone. So they trigger it again, and again, until the person taps approve to make it stop — often assuming a glitch, often at night.
Okta records every prompt it sends as system.push.send_factor_verify_push, and those records succeed whether or not the human approves, so counting them measures the ATTACK rather than its outcome. A real sign-in produces one.
Keyed on the send events rather than on failures, which is what makes it work before the account is taken: the failures only appear if the user keeps refusing, and the whole point of the technique is that eventually they stop.
MITRE ATT&CK mapping
False positives and triage
A user whose phone is offline or whose Okta Verify has lost its push token can generate a genuine burst — they tap "send again" until something arrives, and the log looks identical. Two things separate it. First, the ADDRESS: legitimate retries come from wherever the user is signing in, while push bombing usually shows the prompts triggered from one address and the sign-in attempts from another. Second, what FOLLOWS: a user with a broken phone gives up or calls the helpdesk, whereas this technique ends either in user.account.lock or in a successful authentication that no one initiated.
Ask the user directly before treating an approval as compromise — and if they did not approve it, treat every session for that account as hostile, because the attacker had the password already.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/okta_mfa_push_bombing.yaml, licensed under the Apache License 2.0.
id: cloud.identity.okta_mfa_push_bombing
version: 1.0.0
status: stable
severity: high
confidence: 0.7
platforms: [application]
mitre_techniques: [T1621, T1078]
description: |
Okta sent a burst of verification pushes to one account.
Push bombing works on attrition. The attacker already has the password; what
stands between them and the account is a prompt on someone's phone. So they
trigger it again, and again, until the person taps approve to make it stop —
often assuming a glitch, often at night.
Okta records every prompt it sends as `system.push.send_factor_verify_push`,
and those records succeed whether or not the human approves, so counting them
measures the ATTACK rather than its outcome. A real sign-in produces one.
Keyed on the send events rather than on failures, which is what makes it work
before the account is taken: the failures only appear if the user keeps
refusing, and the whole point of the technique is that eventually they stop.
match:
provider: Okta
event_action: system.push.send_factor_verify_push
threshold:
# Four prompts in two minutes. A person retries a legitimate sign-in once or
# twice; four is the tool. The corpus capture that motivated this fires four
# inside fifty-five seconds.
count: 4
window_seconds: 120
group_by: [user_name]
correlation_keys: [user_name, source_ip]
false_positive_guidance: |
A user whose phone is offline or whose Okta Verify has lost its push token can
generate a genuine burst — they tap "send again" until something arrives, and
the log looks identical. Two things separate it. First, the ADDRESS: legitimate
retries come from wherever the user is signing in, while push bombing usually
shows the prompts triggered from one address and the sign-in attempts from
another. Second, what FOLLOWS: a user with a broken phone gives up or calls the
helpdesk, whereas this technique ends either in `user.account.lock` or in a
successful authentication that no one initiated.
Ask the user directly before treating an approval as compromise — and if they
did not approve it, treat every session for that account as hostile, because the
attacker had the password already.
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.