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.
0 commit comments