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

to-top