Okta user reported suspicious activity
An end user reported activity on their own account as suspicious (user.account.report_suspicious_activity_by_enduser).
What it detects
An end user reported activity on their own account as suspicious (user.account.report_suspicious_activity_by_enduser).
This is a human being telling you they received an authentication prompt they did not initiate — which means someone else had their password and reached the MFA step. It is the highest-quality signal in an identity log precisely because it does not come from a heuristic, and it is routinely the earliest warning of an MFA-fatigue push-bombing campaign. It should never be triaged as informational.
MITRE ATT&CK mapping
False positives and triage
Users occasionally report their own forgotten session or a prompt from a legitimate new device, so confirm with them. But treat the burden of proof as reversed here: the default assumption is that the password is compromised. Reset it, re-enroll the factors, and review that account's sign-ins around the report — a successful sign-in near the report time is a confirmed takeover, not a false positive.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/cloud/okta_user_reported_suspicious_activity.yaml, licensed under the Apache License 2.0.
id: cloud.okta.user_reported_suspicious_activity
version: 1.0.0
status: stable
severity: high
confidence: 0.75
platforms: [application]
mitre_techniques: [T1621, T1078.004]
description: |
An end user reported activity on their own account as suspicious
(`user.account.report_suspicious_activity_by_enduser`).
This is a human being telling you they received an authentication prompt they did
not initiate — which means someone else had their password and reached the MFA step.
It is the highest-quality signal in an identity log precisely because it does not
come from a heuristic, and it is routinely the earliest warning of an MFA-fatigue
push-bombing campaign. It should never be triaged as informational.
match:
provider: Okta
event_action_contains_any:
# Anchored on the END-USER variant. A bare `report_suspicious_activity` also
# matches `user.account.report_suspicious_activity_cleared_by_admin`, so the
# administrator CLOSING the report would re-raise the alert they just closed —
# caught by this rule's own negative fixture.
- report_suspicious_activity_by_enduser
correlation_keys: [user_name]
false_positive_guidance: |
Users occasionally report their own forgotten session or a prompt from a legitimate
new device, so confirm with them. But treat the burden of proof as reversed here:
the default assumption is that the password is compromised. Reset it, re-enroll the
factors, and review that account's sign-ins around the report — a successful sign-in
near the report time is a confirmed takeover, not a false positive.
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.