Detection rules › Elastic
Okta Admin Console Login Failure
Identifies failed login attempts to the Okta Admin Console. Adversaries may attempt to gain unauthorized access to administrator portals during reconnaissance or privilege escalation phases. Repeated failures may indicate brute force attacks, credential spraying, or attempts to use compromised credentials. Monitoring Admin Console access failures provides visibility into potential account takeover attempts targeting administrative accounts.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Initial Access | T1078.004 Valid Accounts: Cloud Accounts |
| Credential Access | T1110 Brute Force |
Rule body elastic
[metadata]
bypass_bbr_timing = true
creation_date = "2026/02/03"
integration = ["okta"]
maturity = "production"
updated_date = "2026/03/24"
[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies failed login attempts to the Okta Admin Console. Adversaries may attempt to gain unauthorized access to
administrator portals during reconnaissance or privilege escalation phases. Repeated failures may indicate brute force
attacks, credential spraying, or attempts to use compromised credentials. Monitoring Admin Console access failures
provides visibility into potential account takeover attempts targeting administrative accounts.
"""
from = "now-9m"
index = ["logs-okta.system-*"]
language = "kuery"
license = "Elastic License v2"
name = "Okta Admin Console Login Failure"
note = """## Triage and analysis
### Investigating Okta Admin Console Login Failure
This rule detects failed authentication attempts specifically targeting the Okta Admin Console. The Admin Console provides privileged access to manage Okta configurations, users, and policies, making it a high-value target for adversaries.
Threat actors like ShinyHunters have been observed probing for valid admin credentials as part of their attack chain. Failed Admin Console access attempts often precede successful compromise through vishing (voice phishing) or credential harvesting.
#### Possible investigation steps:
- Identify the user involved by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
- Review the `okta.outcome.reason` field to understand why the authentication failed (e.g., invalid credentials, MFA failure, policy violation).
- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
- Check if the source IP is associated with known malicious activity, VPN/proxy services, or unusual geolocations.
- Examine the `okta.request.ip_chain` field to determine if the actor used a proxy or VPN.
- Correlate with other failed login attempts from the same IP or user to identify patterns.
- Review if the targeted user has administrative privileges that would make them a high-value target.
- Check for any recent vishing or phishing reports targeting users in your organization.
### False positive analysis:
- Administrators may legitimately mistype passwords or have MFA issues.
- Automated systems or scripts may fail authentication due to expired credentials.
- Users may accidentally attempt to access the Admin Console without proper permissions.
### Response and remediation:
- If repeated failures are observed from the same IP, consider blocking the IP address at the network perimeter.
- Alert the targeted administrator about the failed access attempts.
- If the user reports not attempting to access the Admin Console, treat this as a potential account compromise attempt.
- Review and strengthen MFA requirements for Admin Console access.
- Consider implementing conditional access policies to restrict Admin Console access to trusted networks.
- If vishing is suspected, remind users of social engineering awareness and verification procedures.
"""
references = [
"https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft",
"https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
"https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 21
rule_id = "f960e8a4-31c1-4a6e-b172-8f5c8e5c8c2a"
severity = "low"
tags = [
"Domain: Identity",
"Use Case: Identity and Access Audit",
"Data Source: Okta",
"Data Source: Okta System Logs",
"Tactic: Initial Access",
"Tactic: Credential Access",
"Resources: Investigation Guide",
"Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset: "okta.system"
and event.category: "authentication"
and okta.target.alternate_id: "Okta Admin Console"
and okta.outcome.result: "FAILURE"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"
[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1110"
name = "Brute Force"
reference = "https://attack.mitre.org/techniques/T1110/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
Stages and Predicates
Stage 1: query
event.dataset: "okta.system"
and event.category: "authentication"
and okta.target.alternate_id: "Okta Admin Console"
and okta.outcome.result: "FAILURE"
Indicators
Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.
| Field | Kind | Values |
|---|---|---|
event.category | eq |
|
event.dataset | eq |
|
okta.outcome.result | eq |
|
okta.target.alternate_id | eq |
|