Detect Credential Stuffing in Okta System Log
MITRE ATT&CK: T1110.004T1110.001
Sigma Rule
title: Okta Credential Stuffing / Password Spray
id: 8a1f3c62-9d24-4e71-b053-2c6f1a9e7d07
status: experimental
description: >
Detects a high volume of failed Okta sign-ins from a single source in a short
window — the signature of automated credential stuffing or password spraying.
A subsequent SUCCESS or an account lockout from the same source confirms impact.
references:
- https://attack.mitre.org/techniques/T1110/004/
author: LogTriage
date: 2026/07/01
logsource:
product: okta
service: okta
detection:
selection:
eventType:
- 'user.session.start'
- 'user.authentication.auth_via_mfa'
outcome.result: 'FAILURE'
timeframe: 10m
condition: selection | count() by client.ipAddress >= 10
falsepositives:
- Single user retrying a forgotten password (low volume)
- Misconfigured SSO/SCIM integration (allowlist its IP)
level: high
tags:
- attack.credential_access
- attack.t1110.004
What this rule detects
Credential stuffing against Okta looks the same as anywhere else, just in Okta’s event vocabulary: a
burst of user.session.start events with outcome.result = FAILURE from one source IP, often
ending in a user.account.lock — or worse, a SUCCESS marking a takeover.
This Sigma rule fires when a single source produces 10+ failed sign-ins within 10 minutes.
Detection logic
Key on eventType (user.session.start, user.authentication.auth_via_mfa) + outcome.result: FAILURE, aggregated by client.ipAddress. The threshold/window are conservative to keep noise low —
tune to your tenant. The strongest confirmation is a SUCCESS or account-lock from the same source
right after the burst, which turns “guessing” into “got in / triggered defenses.”
LogTriage’s credential-stuffing detector groups the failures and the follow-on success into one session and raises severity when it sees the success.
Validated against a real sample
Validated against okta_credential_stuffing.json (shipped with LogTriage): 10 user.session.start
FAILURE events from one source, an auth_via_mfa attempt, and a user.account.lock. The rule fires
on that sample and stays silent on the matching benign login log.
False positives
A single user fat-fingering a password is low-volume and self-resolves. A misconfigured SSO/SCIM integration can spray stale credentials — allowlist its source IP. Confirm with the follow-on SUCCESS/lock signal before treating as a live compromise.
Frequently Asked Questions
- Why count by source IP and not by user?
- Credential stuffing sprays many accounts from one source, testing one or two passwords each. Counting failures per source IP catches the campaign even when no single account crosses a per-user lockout threshold — which is exactly how attackers stay under by-user detections.
- How do I confirm compromise vs. a noisy failure burst?
- Look for a user.session.start with outcome SUCCESS, or a user.account.lock event, from the same source right after the failures. LogTriage's session grouper correlates the failure burst with the follow-on success automatically and escalates severity.
- Does MFA make this irrelevant?
- No — attackers who get a valid password still generate the failed-then-succeeded pattern, and MFA-fatigue/push-bombing shows up as auth_via_mfa events. Detecting the credential-stuffing burst is your early warning before the MFA step is even reached.
Related Resources
See this detection run on a real report
Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.