You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
min_stack_comments = "Bug fix in threshold rules."
7
+
updated_date = "2025/11/13"
6
8
7
9
[rule]
8
10
author = ["Elastic"]
@@ -18,26 +20,28 @@ false_positives = [
18
20
""",
19
21
]
20
22
from = "now-60m"
21
-
interval = "15m"
22
-
language = "esql"
23
+
index = ["filebeat-*", "logs-azure.signinlogs-*"]
24
+
interval = "30m"
25
+
language = "kuery"
23
26
license = "Elastic License v2"
24
-
name = "Microsoft Entra ID Exccessive Account Lockouts Detected"
27
+
name = "Microsoft Entra ID Excessive Account Lockouts Detected"
25
28
note = """## Triage and analysis
26
29
27
-
### Investigating Microsoft Entra ID Exccessive Account Lockouts Detected
30
+
### Investigating Microsoft Entra ID Excessive Account Lockouts Detected
28
31
29
32
This rule detects a high number of sign-in failures due to account lockouts (error code `50053`) in Microsoft Entra ID sign-in logs. These lockouts are typically caused by repeated authentication failures, often as a result of brute-force tactics such as password spraying, credential stuffing, or automated guessing. This detection is time-bucketed and aggregates attempts to identify bursts or coordinated campaigns targeting multiple users.
30
33
31
34
### Possible investigation steps
32
35
33
-
- Review `user_id_list` and `user_principal_name`: Check if targeted users include high-value accounts such as administrators, service principals, or shared inboxes.
34
-
- Check `error_codes` and `result_description`: Validate that `50053` (account locked) is the consistent failure type. Messages indicating "malicious IP" activity suggest Microsoft’s backend flagged the source.
35
-
- Analyze `ip_list` and `source_orgs`: Identify whether the activity originated from known malicious infrastructure (e.g., VPNs, botnets, or public cloud providers). In the example, traffic originates from `MASSCOM`, which should be validated.
36
-
- Inspect `device_detail_browser` and `user_agent`: Clients like `"Python Requests"` indicate scripted automation rather than legitimate login attempts.
37
-
- Evaluate `unique_users` vs. `total_attempts`: A high ratio suggests distributed attacks across multiple accounts, characteristic of password spraying.
38
-
- Correlate `client_app_display_name` and `incoming_token_type`: PowerShell or unattended sign-in clients may be targeted for automation or legacy auth bypass.
39
-
- Review `conditional_access_status` and `risk_state`: If Conditional Access was not applied and risk was not flagged, policy scope or coverage should be reviewed.
40
-
- Validate time range (`first_seen`, `last_seen`): Determine whether the attack is a short burst or part of a longer campaign.
36
+
Please note this is as threshold rule that aggregates multiple account lockouts over a specified time window. To properly investigate, pivot into the individual sign-in log events that contributed to the threshold being met.
37
+
38
+
- Review users impacted by pivoting searching for `user.name` in events where `azure.signinlogs.properties.status.error_code` is `50053`.
39
+
- Analyze source addresses associated with these lockouts. Identify whether the activity originated from known malicious infrastructure (e.g., VPNs, botnets, or public cloud providers).
40
+
- Inspect the user-agents involved in these account lockouts. Clients like `Python Requests` indicate scripted automation rather than legitimate login attempts. ROPC agents may suggest brute-forcing against legacy auth.
41
+
- A high ratio suggests distributed attacks across multiple accounts, characteristic of password spraying.
42
+
- Correlate client apps associated such as PowerShell or unattended sign-in clients may be targeted for automation or legacy auth bypass.
43
+
- Review conditional access state or risk state of the user involved. If Conditional Access was not applied and risk was not flagged, policy scope or coverage should be reviewed.
44
+
- Check for any successful sign-ins for the affected users around the same time frame to determine if any accounts were compromised prior to lockout.
41
45
42
46
### False positive analysis
43
47
@@ -55,6 +59,7 @@ This rule detects a high number of sign-in failures due to account lockouts (err
55
59
- Audit authentication methods in use, and enforce modern auth (OAuth, SAML) over legacy protocols.
56
60
- Strengthen Conditional Access policies to reduce exposure from weak locations, apps, or clients.
57
61
- Conduct credential hygiene audits to assess reuse and rotation for targeted accounts.
62
+
- If false positives are identified, create exceptions for known benign sources, users or user agents to reduce noise.
Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is
11
+
highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly
12
+
indicates that an attacker has stolen a device token and is using it to impersonate a legitimate user from a
13
+
different machine.
14
+
"""
15
+
false_positives = [
16
+
"""
17
+
Applications will tag the operating system as null when the device is not recognized as a managed device. In
18
+
environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
19
+
""",
20
+
]
21
+
from = "now-60m"
22
+
index = ["logs-okta.system-*"]
23
+
language = "kuery"
24
+
license = "Elastic License v2"
25
+
name = "Okta Multiple OS Names Detected for a Single DT Hash"
26
+
note = """## Triage and analysis
27
+
28
+
### Investigating Okta Multiple OS Names Detected for a Single DT Hash
29
+
30
+
This rule detects when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token token and is using it to impersonate a legitimate user from a different machine.
31
+
32
+
### Possible investigation steps
33
+
- Review the `okta.debug_context.debug_data.dt_hash` field to identify the specific device
34
+
trust hash associated with multiple operating systems.
35
+
- Examine the `user.email` field to determine which user account is associated with the suspicious activity
36
+
- Analyze the `source.ip` field to identify the IP addresses from which the different operating systems were reported. Look for any unusual or unexpected locations.
37
+
- Review the `user_agent.os.name` field to see the different operating systems reported for the
38
+
same dt_hash. This will help identify the nature of the anomaly.
39
+
- Check the `event.action` field to understand the context of the authentication events (e.g., MFA verification, standard authentication).
40
+
- Investigate the timeline of events to see when the different operating systems were reported for the same dt_hash. Look for patterns or sequences that may indicate malicious activity.
41
+
- Correlate this activity with other security events in your environment, such as failed login attempts, unusual access patterns, or alerts from endpoint security solutions.
42
+
43
+
### False positive analysis
44
+
- Applications will tag the operating system as null when the device is not recognized as a managed device
45
+
- In environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
46
+
47
+
### Response and remediation
48
+
- Immediately investigate the user account associated with the suspicious activity to determine if it has been compromised.
49
+
- If compromise is confirmed, reset the user's credentials and enforce multi-factor authentication (MFA)
50
+
- Revoke any active sessions associated with the compromised account to prevent further unauthorized access.
51
+
- Review and monitor the affected dt_hash for any further suspicious activity.
52
+
- Educate users about the importance of device security and the risks associated with device tokens.
53
+
- Implement additional monitoring for device token tokens and consider using conditional access policies to restrict access based on device compliance status.
54
+
"""
55
+
risk_score = 73
56
+
rule_id = "fb3ca230-af4e-11f0-900d-f661ea17fbcc"
57
+
severity = "high"
58
+
tags = [
59
+
"Domain: Identity",
60
+
"Data Source: Okta",
61
+
"Data Source: Okta System Logs",
62
+
"Use Case: Threat Detection",
63
+
"Tactic: Credential Access",
64
+
"Resources: Investigation Guide"
65
+
]
66
+
timestamp_override = "event.ingested"
67
+
type = "threshold"
68
+
69
+
query = '''
70
+
data_stream.dataset: "okta.system"
71
+
and not okta.debug_context.debug_data.dt_hash: "-"
0 commit comments