Azure Entra Sign-in Brute Force against Microsoft 365 Accounts
Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed interactive or non-interactive login attempts within a 30-minute window. Attackers may attempt to brute force user accounts to gain unauthorized access to Microsoft 365 services via different services such as Exchange, SharePoint, or Teams.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/09/06"
3integration = ["azure"]
4maturity = "production"
5min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
6min_stack_version = "8.13.0"
7updated_date = "2025/01/15"
8
9[rule]
10author = ["Elastic"]
11description = """
12Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed
13interactive or non-interactive login attempts within a 30-minute window. Attackers may attempt to brute force user
14accounts to gain unauthorized access to Microsoft 365 services via different services such as Exchange, SharePoint, or
15Teams.
16"""
17false_positives = [
18 """
19 Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication
20 settings may lead to false positives.
21 """,
22]
23from = "now-60m"
24language = "esql"
25interval = "10m"
26license = "Elastic License v2"
27name = "Azure Entra Sign-in Brute Force against Microsoft 365 Accounts"
28note = """## Triage and analysis
29
30> **Disclaimer**:
31> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
32
33### Investigating Azure Entra Sign-in Brute Force against Microsoft 365 Accounts
34
35Azure Entra ID, integral to Microsoft 365, manages user identities and access. Adversaries exploit this by attempting numerous login attempts to breach accounts, targeting services like Exchange and Teams. The detection rule identifies such threats by analyzing failed login patterns within a 30-minute window, flagging unusual activity from multiple sources or excessive failed attempts, thus highlighting potential brute-force attacks.
36
37### Possible investigation steps
38
39- Review the `azure.signinlogs.properties.user_principal_name` to identify the specific user account targeted by the brute-force attempts.
40- Examine the `source.ip` field to determine the origin of the failed login attempts and assess if multiple IP addresses are involved, indicating a distributed attack.
41- Check the `azure.signinlogs.properties.resource_display_name` to understand which Microsoft 365 services (e.g., Exchange, SharePoint, Teams) were targeted during the login attempts.
42- Analyze the `target_time_window` to confirm the timeframe of the attack and correlate it with other security events or alerts that may have occurred simultaneously.
43- Investigate the `azure.signinlogs.properties.status.error_code` for specific error codes that might provide additional context on the nature of the failed login attempts.
44- Assess the user's recent activity and any changes in behavior or access patterns that could indicate a compromised account or insider threat.
45
46### False positive analysis
47
48- High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery processes. To mitigate this, consider excluding known IP addresses associated with IT support or helpdesk operations.
49- Automated scripts or applications that frequently access Microsoft 365 services using non-interactive logins may be misidentified as brute force attempts. Identify and whitelist these applications by their user principal names or IP addresses.
50- Users traveling or working remotely may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exclusions for known travel patterns or use conditional access policies to manage these scenarios.
51- Bulk operations performed by administrators, such as batch account updates or migrations, can result in numerous failed logins. Exclude these activities by recognizing the specific user principal names or IP addresses involved in such operations.
52- Frequent logins from shared IP addresses, such as those from corporate VPNs or proxy servers, might be flagged. Consider excluding these IP ranges if they are known and trusted within the organization.
53
54### Response and remediation
55
56- Immediately isolate the affected user accounts by disabling them to prevent further unauthorized access.
57- Conduct a password reset for the compromised accounts, ensuring the new passwords are strong and unique.
58- Review and block the IP addresses associated with the failed login attempts to prevent further access attempts from these sources.
59- Enable multi-factor authentication (MFA) for the affected accounts and any other accounts that do not have it enabled to add an additional layer of security.
60- Monitor the affected accounts and related services for any unusual activity or signs of compromise post-remediation.
61- Escalate the incident to the security operations team for further investigation and to determine if there are broader implications or related threats.
62- Update and enhance detection rules and monitoring to identify similar brute-force attempts in the future, ensuring quick response to any new threats.
63
64This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."""
65references = [
66 "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying",
67 "https://github.com/0xZDH/o365spray"
68]
69risk_score = 47
70rule_id = "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc"
71severity = "medium"
72tags = [
73 "Domain: Cloud",
74 "Domain: SaaS",
75 "Data Source: Azure",
76 "Data Source: Entra ID",
77 "Data Source: Entra ID Sign-in",
78 "Use Case: Identity and Access Audit",
79 "Use Case: Threat Detection",
80 "Tactic: Credential Access",
81 "Resources: Investigation Guide",
82]
83timestamp_override = "event.ingested"
84type = "esql"
85
86query = '''
87from logs-azure.signinlogs*
88// truncate the timestamp to a 30-minute window
89| eval target_time_window = DATE_TRUNC(30 minutes, @timestamp)
90| WHERE
91 event.dataset == "azure.signinlogs"
92 and event.category == "authentication"
93 and to_lower(azure.signinlogs.properties.resource_display_name) rlike "(.*)365(.*)"
94 and azure.signinlogs.category in ("NonInteractiveUserSignInLogs", "SignInLogs")
95 and event.outcome != "success"
96 // for tuning review azure.signinlogs.properties.status.error_code
97 // https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes
98
99// keep only relevant fields
100| keep target_time_window, event.dataset, event.category, azure.signinlogs.properties.resource_display_name, azure.signinlogs.category, event.outcome, azure.signinlogs.properties.user_principal_name, source.ip
101
102// count the number of login sources and failed login attempts
103| stats
104 login_source_count = count(source.ip),
105 failed_login_count = count(*) by target_time_window, azure.signinlogs.properties.user_principal_name
106
107// filter for users with more than 20 login sources or failed login attempts
108| where (login_source_count >= 20 or failed_login_count >= 20)
109'''
110
111
112[[rule.threat]]
113framework = "MITRE ATT&CK"
114[[rule.threat.technique]]
115id = "T1110"
116name = "Brute Force"
117reference = "https://attack.mitre.org/techniques/T1110/"
118
119
120[rule.threat.tactic]
121id = "TA0006"
122name = "Credential Access"
123reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating Azure Entra Sign-in Brute Force against Microsoft 365 Accounts
Azure Entra ID, integral to Microsoft 365, manages user identities and access. Adversaries exploit this by attempting numerous login attempts to breach accounts, targeting services like Exchange and Teams. The detection rule identifies such threats by analyzing failed login patterns within a 30-minute window, flagging unusual activity from multiple sources or excessive failed attempts, thus highlighting potential brute-force attacks.
Possible investigation steps
- Review the
azure.signinlogs.properties.user_principal_name
to identify the specific user account targeted by the brute-force attempts. - Examine the
source.ip
field to determine the origin of the failed login attempts and assess if multiple IP addresses are involved, indicating a distributed attack. - Check the
azure.signinlogs.properties.resource_display_name
to understand which Microsoft 365 services (e.g., Exchange, SharePoint, Teams) were targeted during the login attempts. - Analyze the
target_time_window
to confirm the timeframe of the attack and correlate it with other security events or alerts that may have occurred simultaneously. - Investigate the
azure.signinlogs.properties.status.error_code
for specific error codes that might provide additional context on the nature of the failed login attempts. - Assess the user's recent activity and any changes in behavior or access patterns that could indicate a compromised account or insider threat.
False positive analysis
- High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery processes. To mitigate this, consider excluding known IP addresses associated with IT support or helpdesk operations.
- Automated scripts or applications that frequently access Microsoft 365 services using non-interactive logins may be misidentified as brute force attempts. Identify and whitelist these applications by their user principal names or IP addresses.
- Users traveling or working remotely may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exclusions for known travel patterns or use conditional access policies to manage these scenarios.
- Bulk operations performed by administrators, such as batch account updates or migrations, can result in numerous failed logins. Exclude these activities by recognizing the specific user principal names or IP addresses involved in such operations.
- Frequent logins from shared IP addresses, such as those from corporate VPNs or proxy servers, might be flagged. Consider excluding these IP ranges if they are known and trusted within the organization.
Response and remediation
- Immediately isolate the affected user accounts by disabling them to prevent further unauthorized access.
- Conduct a password reset for the compromised accounts, ensuring the new passwords are strong and unique.
- Review and block the IP addresses associated with the failed login attempts to prevent further access attempts from these sources.
- Enable multi-factor authentication (MFA) for the affected accounts and any other accounts that do not have it enabled to add an additional layer of security.
- Monitor the affected accounts and related services for any unusual activity or signs of compromise post-remediation.
- Escalate the incident to the security operations team for further investigation and to determine if there are broader implications or related threats.
- Update and enhance detection rules and monitoring to identify similar brute-force attempts in the future, ensuring quick response to any new threats.
This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources.
References
Related rules
- Azure Entra MFA TOTP Brute Force Attempts
- Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source
- Attempts to Brute Force a Microsoft 365 User Account
- Azure Storage Account Key Regenerated
- Entra ID Device Code Auth with Broker Client