Attempts to Brute Force a Microsoft 365 User Account

Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed login attempts or login sources within a 30-minute window. Attackers may attempt to brute force user accounts to gain unauthorized access to Microsoft 365 services.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/11/30"
  3integration = ["o365"]
  4maturity = "production"
  5updated_date = "2025/03/20"
  6
  7[rule]
  8author = ["Elastic", "Willem D'Haese", "Austin Songer"]
  9description = """
 10Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed login
 11attempts or login sources within a 30-minute window. Attackers may attempt to brute force user accounts to gain
 12unauthorized access to Microsoft 365 services.
 13"""
 14false_positives = [
 15    """
 16    Automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false
 17    positives.
 18    """,
 19]
 20from = "now-9m"
 21language = "esql"
 22license = "Elastic License v2"
 23name = "Attempts to Brute Force a Microsoft 365 User Account"
 24note = """## Triage and analysis
 25
 26> **Disclaimer**:
 27> 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.
 28
 29### Investigating Attempts to Brute Force a Microsoft 365 User Account
 30
 31Microsoft 365 is a cloud-based service that provides productivity tools and services. Adversaries may attempt to gain unauthorized access by brute-forcing user accounts, exploiting weak passwords. The detection rule identifies such attempts by analyzing audit logs for numerous failed logins or diverse login sources within a short timeframe, indicating potential brute-force activity.
 32
 33### Possible investigation steps
 34
 35- Review the audit logs for the specific user identified by o365.audit.UserId to gather additional context on the failed login attempts, including timestamps and source IP addresses.
 36- Analyze the source.ip field to identify any unusual or suspicious IP addresses, such as those originating from unexpected geographic locations or known malicious sources.
 37- Check the o365.audit.LogonError field for any patterns or specific errors that might provide insight into the nature of the failed login attempts.
 38- Investigate the o365.audit.ExtendedProperties.RequestType to determine if the login attempts were consistent with typical user behavior or if they suggest automated or scripted activity.
 39- Correlate the findings with other security events or alerts in the environment to assess if the brute-force attempts are part of a larger attack campaign or isolated incidents.
 40- Contact the affected user to verify if they experienced any issues accessing their account and to ensure they are aware of the potential security threat.
 41
 42### False positive analysis
 43
 44- High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery. To mitigate, consider excluding specific users or IP ranges known for such activities.
 45- Automated scripts or applications performing frequent logins for legitimate purposes may be misidentified as brute-force attempts. Identify and whitelist these scripts or applications by their user IDs or IP addresses.
 46- Users traveling or using VPNs may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exceptions for known travel patterns or VPN IP addresses.
 47- Shared accounts accessed by multiple users from different locations can appear as multiple login sources. Limit monitoring on shared accounts or establish a baseline of expected behavior to differentiate between normal and suspicious activity.
 48- Temporary spikes in login attempts due to system maintenance or updates can be mistaken for brute-force attacks. Schedule monitoring exclusions during planned maintenance windows to avoid false alerts.
 49
 50### Response and remediation
 51
 52- Immediately isolate the affected user account by disabling it to prevent further unauthorized access attempts.
 53- Notify the user and relevant IT security personnel about the potential compromise and provide guidance on secure password creation.
 54- Conduct a password reset for the affected user account, ensuring the new password adheres to strong password policies.
 55- Review and analyze the source IP addresses involved in the failed login attempts to identify any patterns or known malicious sources.
 56- Implement conditional access policies to restrict login attempts from suspicious or untrusted locations and devices.
 57- Monitor the affected account and related accounts for any unusual activity or further unauthorized access attempts.
 58- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional accounts or systems are affected."""
 59references = [
 60    "https://blueteamblog.com/7-ways-to-monitor-your-office-365-logs-using-siem",
 61    "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties",
 62]
 63risk_score = 47
 64rule_id = "26f68dba-ce29-497b-8e13-b4fde1db5a2d"
 65severity = "medium"
 66tags = [
 67    "Domain: Cloud",
 68    "Domain: SaaS",
 69    "Data Source: Microsoft 365",
 70    "Use Case: Identity and Access Audit",
 71    "Use Case: Threat Detection",
 72    "Tactic: Credential Access",
 73    "Resources: Investigation Guide",
 74]
 75timestamp_override = "event.ingested"
 76type = "esql"
 77
 78query = '''
 79from logs-o365.audit-*
 80// truncate the timestamp to a 30-minute window
 81| eval target_time_window = DATE_TRUNC(30 minutes, @timestamp)
 82| mv_expand event.category
 83| where event.dataset == "o365.audit"
 84  and event.category == "authentication"
 85
 86  // filter only on Entra ID or Exchange audit logs in O365 integration
 87  and event.provider in ("AzureActiveDirectory", "Exchange")
 88
 89  // filter only for UserLoginFailed or partial failures
 90  and event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword")
 91
 92  // ignore specific logon errors
 93  and not o365.audit.LogonError in (
 94    "EntitlementGrantsNotFound",
 95    "UserStrongAuthEnrollmentRequired",
 96    "UserStrongAuthClientAuthNRequired",
 97    "InvalidReplyTo",
 98    "SsoArtifactExpiredDueToConditionalAccess",
 99    "PasswordResetRegistrationRequiredInterrupt",
100    "SsoUserAccountNotFoundInResourceTenant",
101    "UserStrongAuthExpired",
102    "CmsiInterrupt"
103)
104
105  // ignore unavailable
106  and o365.audit.UserId != "Not Available"
107
108  // filters out non user or application logins based on target
109  and o365.audit.Target.Type in ("0", "2", "3", "5", "6", "10")
110
111  // filters only for logins from user or application, ignoring oauth:token
112  and to_lower(o365.audit.ExtendedProperties.RequestType) rlike "(.*)login(.*)"
113
114// keep only relevant fields
115| keep event.provider, event.dataset, event.category, o365.audit.UserId, event.action, source.ip, o365.audit.LogonError, o365.audit.ExtendedProperties.RequestType, o365.audit.Target.Type, target_time_window
116
117// count the number of login sources and failed login attempts
118| stats
119  login_source_count = count(source.ip),
120  failed_login_count = count(*) by target_time_window, o365.audit.UserId
121
122// filter for users with more than 20 login sources or failed login attempts
123| where (login_source_count >= 20 or failed_login_count >= 20)
124'''
125
126
127[[rule.threat]]
128framework = "MITRE ATT&CK"
129[[rule.threat.technique]]
130id = "T1110"
131name = "Brute Force"
132reference = "https://attack.mitre.org/techniques/T1110/"
133
134
135[rule.threat.tactic]
136id = "TA0006"
137name = "Credential Access"
138reference = "https://attack.mitre.org/tactics/TA0006/"
...
toml

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.

Microsoft 365 is a cloud-based service that provides productivity tools and services. Adversaries may attempt to gain unauthorized access by brute-forcing user accounts, exploiting weak passwords. The detection rule identifies such attempts by analyzing audit logs for numerous failed logins or diverse login sources within a short timeframe, indicating potential brute-force activity.

  • Review the audit logs for the specific user identified by o365.audit.UserId to gather additional context on the failed login attempts, including timestamps and source IP addresses.
  • Analyze the source.ip field to identify any unusual or suspicious IP addresses, such as those originating from unexpected geographic locations or known malicious sources.
  • Check the o365.audit.LogonError field for any patterns or specific errors that might provide insight into the nature of the failed login attempts.
  • Investigate the o365.audit.ExtendedProperties.RequestType to determine if the login attempts were consistent with typical user behavior or if they suggest automated or scripted activity.
  • Correlate the findings with other security events or alerts in the environment to assess if the brute-force attempts are part of a larger attack campaign or isolated incidents.
  • Contact the affected user to verify if they experienced any issues accessing their account and to ensure they are aware of the potential security threat.
  • High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery. To mitigate, consider excluding specific users or IP ranges known for such activities.
  • Automated scripts or applications performing frequent logins for legitimate purposes may be misidentified as brute-force attempts. Identify and whitelist these scripts or applications by their user IDs or IP addresses.
  • Users traveling or using VPNs may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exceptions for known travel patterns or VPN IP addresses.
  • Shared accounts accessed by multiple users from different locations can appear as multiple login sources. Limit monitoring on shared accounts or establish a baseline of expected behavior to differentiate between normal and suspicious activity.
  • Temporary spikes in login attempts due to system maintenance or updates can be mistaken for brute-force attacks. Schedule monitoring exclusions during planned maintenance windows to avoid false alerts.
  • Immediately isolate the affected user account by disabling it to prevent further unauthorized access attempts.
  • Notify the user and relevant IT security personnel about the potential compromise and provide guidance on secure password creation.
  • Conduct a password reset for the affected user account, ensuring the new password adheres to strong password policies.
  • Review and analyze the source IP addresses involved in the failed login attempts to identify any patterns or known malicious sources.
  • Implement conditional access policies to restrict login attempts from suspicious or untrusted locations and devices.
  • Monitor the affected account and related accounts for any unusual activity or further unauthorized access attempts.
  • Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional accounts or systems are affected.

References

Related rules

to-top