Entra ID Excessive Account Lockouts Detected

Identifies a high count of failed Microsoft Entra ID sign-in attempts as the result of the target user account being locked out. Adversaries may attempt to brute-force user accounts by repeatedly trying to authenticate with incorrect credentials, leading to account lockouts by Entra ID Smart Lockout policies.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/07/01"
  3integration = ["azure"]
  4maturity = "production"
  5min_stack_version = "9.0.0"
  6min_stack_comments = "Bug fix in threshold rules."
  7updated_date = "2025/12/10"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Identifies a high count of failed Microsoft Entra ID sign-in attempts as the result of the target user account being
 13locked out. Adversaries may attempt to brute-force user accounts by repeatedly trying to authenticate with incorrect
 14credentials, leading to account lockouts by Entra ID Smart Lockout policies.
 15"""
 16false_positives = [
 17    """
 18    Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication
 19    settings may lead to false positives.
 20    """,
 21]
 22from = "now-60m"
 23index = ["filebeat-*", "logs-azure.signinlogs-*"]
 24interval = "30m"
 25language = "kuery"
 26license = "Elastic License v2"
 27name = "Entra ID Excessive Account Lockouts Detected"
 28note = """## Triage and analysis
 29
 30### Investigating Entra ID Excessive Account Lockouts Detected
 31
 32This 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.
 33
 34### Possible investigation steps
 35
 36Please 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.
 45
 46### False positive analysis
 47
 48- Misconfigured clients, scripts, or services with outdated credentials may inadvertently cause lockouts.
 49- Repeated lockouts from known internal IPs or during credential rotation windows could be benign.
 50- Legacy applications without modern auth support may repeatedly fail and trigger Smart Lockout.
 51- Specific known user agents (e.g., corporate service accounts).
 52- Internal IPs or cloud-hosted automation with expected failure behavior.
 53
 54### Response and remediation
 55
 56- Investigate locked accounts immediately. Confirm if the account was successfully accessed prior to lockout.
 57- Reset credentials for impacted users and enforce MFA before re-enabling accounts.
 58- Block malicious IPs or ASN at the firewall, identity provider, or Conditional Access level.
 59- Audit authentication methods in use, and enforce modern auth (OAuth, SAML) over legacy protocols.
 60- Strengthen Conditional Access policies to reduce exposure from weak locations, apps, or clients.
 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.
 63"""
 64references = [
 65    "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/",
 66    "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying",
 67    "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray",
 68    "https://www.sprocketsecurity.com/blog/exploring-modern-password-spraying",
 69    "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties",
 70    "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes",
 71    "https://github.com/0xZDH/Omnispray",
 72    "https://github.com/0xZDH/o365spray",
 73]
 74risk_score = 73
 75rule_id = "2d6f5332-42ea-11f0-b09a-f661ea17fbcd"
 76severity = "high"
 77tags = [
 78    "Domain: Cloud",
 79    "Domain: Identity",
 80    "Data Source: Azure",
 81    "Data Source: Entra ID",
 82    "Data Source: Entra ID Sign-in Logs",
 83    "Use Case: Identity and Access Audit",
 84    "Use Case: Threat Detection",
 85    "Tactic: Credential Access",
 86    "Resources: Investigation Guide",
 87]
 88timestamp_override = "event.ingested"
 89type = "threshold"
 90
 91query = '''
 92event.dataset: "azure.signinlogs" and event.category: "authentication"
 93    and azure.signinlogs.category: ("NonInteractiveUserSignInLogs" or "SignInLogs")
 94    and event.outcome: "failure"
 95    and azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication"
 96    and azure.signinlogs.properties.status.error_code: 50053
 97    and azure.signinlogs.properties.user_principal_name: (* and not "")
 98    and not source.as.organization.name: "MICROSOFT-CORP-MSN-as-BLOCK"
 99'''
100
101[rule.threshold]
102field = []
103value = 20
104
105[[rule.threshold.cardinality]]
106field = "user.name"
107value = 15
108
109
110[[rule.threat]]
111framework = "MITRE ATT&CK"
112[[rule.threat.technique]]
113id = "T1110"
114name = "Brute Force"
115reference = "https://attack.mitre.org/techniques/T1110/"
116[[rule.threat.technique.subtechnique]]
117id = "T1110.001"
118name = "Password Guessing"
119reference = "https://attack.mitre.org/techniques/T1110/001/"
120
121[[rule.threat.technique.subtechnique]]
122id = "T1110.003"
123name = "Password Spraying"
124reference = "https://attack.mitre.org/techniques/T1110/003/"
125
126[[rule.threat.technique.subtechnique]]
127id = "T1110.004"
128name = "Credential Stuffing"
129reference = "https://attack.mitre.org/techniques/T1110/004/"
130
131
132
133[rule.threat.tactic]
134id = "TA0006"
135name = "Credential Access"
136reference = "https://attack.mitre.org/tactics/TA0006/"

Triage and analysis

Investigating Entra ID Excessive Account Lockouts Detected

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.

Possible investigation steps

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.

  • Review users impacted by pivoting searching for user.name in events where azure.signinlogs.properties.status.error_code is 50053.
  • Analyze source addresses associated with these lockouts. Identify whether the activity originated from known malicious infrastructure (e.g., VPNs, botnets, or public cloud providers).
  • 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.
  • A high ratio suggests distributed attacks across multiple accounts, characteristic of password spraying.
  • Correlate client apps associated such as PowerShell or unattended sign-in clients may be targeted for automation or legacy auth bypass.
  • 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.
  • 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.

False positive analysis

  • Misconfigured clients, scripts, or services with outdated credentials may inadvertently cause lockouts.
  • Repeated lockouts from known internal IPs or during credential rotation windows could be benign.
  • Legacy applications without modern auth support may repeatedly fail and trigger Smart Lockout.
  • Specific known user agents (e.g., corporate service accounts).
  • Internal IPs or cloud-hosted automation with expected failure behavior.

Response and remediation

  • Investigate locked accounts immediately. Confirm if the account was successfully accessed prior to lockout.
  • Reset credentials for impacted users and enforce MFA before re-enabling accounts.
  • Block malicious IPs or ASN at the firewall, identity provider, or Conditional Access level.
  • Audit authentication methods in use, and enforce modern auth (OAuth, SAML) over legacy protocols.
  • Strengthen Conditional Access policies to reduce exposure from weak locations, apps, or clients.
  • Conduct credential hygiene audits to assess reuse and rotation for targeted accounts.
  • If false positives are identified, create exceptions for known benign sources, users or user agents to reduce noise.

References

Related rules

to-top