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
[Rule Tuning] Tuning Azure Entra Sign-in Brute Force against Microsoft 365 Accounts (#4737)
* rule tuning 'Potential Microsoft 365 Brute Force via Entra ID Sign-Ins'
* updated lookback windows, date truncation times
* updated investigation guide
min_stack_comments = "Elastic ES|QL values aggregation is more performant in 8.16.5 and above."
7
8
8
9
[rule]
9
10
author = ["Elastic"]
10
11
description = """
11
-
Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed
12
-
interactive or non-interactive login attempts within a 30-minute window. Attackers may attempt to brute force user
13
-
accounts to gain unauthorized access to Microsoft 365 services via different services such as Exchange, SharePoint, or
14
-
Teams.
12
+
Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in
13
+
Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive
14
+
authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or
15
+
password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as
16
+
Exchange Online, SharePoint, or Teams.
15
17
"""
16
18
false_positives = [
17
19
"""
@@ -23,46 +25,50 @@ from = "now-60m"
23
25
interval = "10m"
24
26
language = "esql"
25
27
license = "Elastic License v2"
26
-
name = "Azure Entra Sign-in Brute Force against Microsoft 365 Accounts"
28
+
name = "Potential Microsoft 365 Brute Force via Entra ID Sign-Ins"
27
29
note = """## Triage and analysis
28
30
29
-
> **Disclaimer**:
30
-
> 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.
31
-
32
-
### Investigating Azure Entra Sign-in Brute Force against Microsoft 365 Accounts
31
+
### Investigating Potential Microsoft 365 Brute Force via Entra ID Sign-Ins
33
32
34
-
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.
33
+
Identifies brute-force authentication activity against Microsoft 365services using Entra ID sign-in logs. This detection groups and classifies failed sign-in attempts based on behavior indicative of password spraying, credential stuffing, or password guessing. The classification (`bf_type`) is included for immediate triage.
35
34
36
35
### Possible investigation steps
37
36
38
-
- Review the `azure.signinlogs.properties.user_principal_name` to identify the specific user account targeted by the brute-force attempts.
39
-
- 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.
40
-
- 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.
41
-
- 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.
42
-
- 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.
43
-
- Assess the user's recent activity and any changes in behavior or access patterns that could indicate a compromised account or insider threat.
37
+
- Review `bf_type`: Classifies the brute-force behavior (`password_spraying`, `credential_stuffing`, `password_guessing`).
38
+
- Examine `user_id_list`: Review the identities targeted. Are they admins, service accounts, or external identities?
- Check `ip_list` and `source_orgs`: Determine if requests came from known VPNs, hosting providers, or anonymized infrastructure.
41
+
- Validate `unique_ips` and `countries`: Multiple countries or IPs in a short window may indicate credential stuffing or distributed spray attempts.
42
+
- Compare `total_attempts` vs `duration_seconds`: High volume over a short duration supports non-human interaction.
43
+
- Inspect `user_agent.original` via `device_detail_browser`: Clients like `Python Requests` or `curl` are highly suspicious.
44
+
- Investigate `client_app_display_name` and `incoming_token_type`: Identify non-browser-based logins, token abuse or commonly mimicked clients like VSCode.
45
+
- Review `target_resource_display_name`: Confirm the service being targeted (e.g., SharePoint, Exchange). This may be what authorization is being attempted against.
46
+
- Pivot using `session_id` and `device_detail_device_id`: Determine if a single device is spraying multiple accounts.
47
+
- Check `conditional_access_status`: If "notApplied", determine whether conditional access is properly scoped.
48
+
- Correlate `user_principal_name` with successful sign-ins: Investigate surrounding logs for lateral movement or privilege abuse.
44
49
45
50
### False positive analysis
46
51
47
-
- 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.
48
-
- 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.
49
-
- 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.
50
-
- 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.
51
-
- 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.
52
+
- Developer automation (e.g., CI/CD logins) or mobile sync errors may create noisy but benign login failures.
53
+
- Red team exercises or pentesting can resemble brute-force patterns.
54
+
- Legacy protocols or misconfigured service principals may trigger repeated login failures from the same IP or session.
52
55
53
56
### Response and remediation
54
57
55
-
- Immediately isolate the affected user accounts by disabling them to prevent further unauthorized access.
56
-
- Conduct a password reset for the compromised accounts, ensuring the new passwords are strong and unique.
57
-
- Review and block the IP addresses associated with the failed login attempts to prevent further access attempts from these sources.
58
-
- 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.
59
-
- Monitor the affected accounts and related services for any unusual activity or signs of compromise post-remediation.
60
-
- Escalate the incident to the security operations team for further investigation and to determine if there are broader implications or related threats.
61
-
- Update and enhance detection rules and monitoring to identify similar brute-force attempts in the future, ensuring quick response to any new threats.
62
-
63
-
This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."""
58
+
- Notify identity or security operations teams to investigate further.
59
+
- Lock or reset affected user accounts if compromise is suspected.
60
+
- Block the source IP(s) or ASN temporarily using conditional access or firewall rules.
61
+
- Review tenant-wide MFA and conditional access enforcement.
62
+
- Audit targeted accounts for password reuse across systems or tenants.
63
+
- Enable lockout or throttling policies for repeated failed login attempts.
Copy file name to clipboardExpand all lines: rules/integrations/o365/credential_access_microsoft_365_potential_user_account_brute_force.toml
+6-5Lines changed: 6 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
creation_date = "2020/11/30"
3
3
integration = ["o365"]
4
4
maturity = "production"
5
-
updated_date = "2025/05/09"
5
+
updated_date = "2025/05/20"
6
6
min_stack_version = "8.17.0"
7
7
min_stack_comments = "Elastic ES|QL values aggregation is more performant in 8.16.5 and above."
8
8
@@ -19,7 +19,8 @@ false_positives = [
19
19
positives.
20
20
""",
21
21
]
22
-
from = "now-9m"
22
+
from = "now-60m"
23
+
interval = "10m"
23
24
language = "esql"
24
25
license = "Elastic License v2"
25
26
name = "Potential Microsoft 365 User Account Brute Force"
@@ -29,7 +30,7 @@ note = """## Triage and Analysis
29
30
30
31
Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords.
31
32
32
-
### Investigation Steps
33
+
### Possible investigation steps
33
34
34
35
- Review `user_id_list`: Enumerates the user accounts targeted. Look for naming patterns or privilege levels (e.g., admins).
35
36
- Check `login_errors`: A consistent error such as `"InvalidUserNameOrPassword"` confirms a spray-style attack using one or a few passwords.
@@ -39,13 +40,13 @@ Identifies brute-force authentication activity targeting Microsoft 365 user acco
39
40
- Cross-reference with successful logins: Pivot to surrounding sign-in logs (`azure.signinlogs`) or risk detections (`identityprotection`) for any account that eventually succeeded.
40
41
- Check for multi-factor challenges or bypasses: Determine if any of the accounts were protected or if the attack bypassed MFA.
41
42
42
-
### False Positive Analysis
43
+
### False positive analysis
43
44
44
45
- IT administrators using automation tools (e.g., PowerShell) during account provisioning may trigger false positives if login attempts cluster.
45
46
- Penetration testing or red team simulations may resemble spray activity.
46
47
- Infrequent, low-volume login testing tools like ADFS testing scripts can exhibit similar patterns.
47
48
48
-
### Response Recommendations
49
+
### Response and remediation
49
50
50
51
- Initiate an internal incident ticket and inform the affected identity/IT team.
51
52
- Temporarily disable impacted user accounts if compromise is suspected.
0 commit comments