New

The executive guide to generative AI

Read more
About usPartnersSupport|Login
« Attempted Private Key Access Attempts to Brute Force an Okta User Account »
Elastic Docs ›Elastic Security Solution [8.17] ›Detections and alerts ›Prebuilt rule reference

Attempts to Brute Force a Microsoft 365 User Account

edit

Attempts to Brute Force a Microsoft 365 User Account

edit

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.

Rule type: esql

Rule indices: None

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: SaaS
  • Data Source: Microsoft 365
  • Use Case: Identity and Access Audit
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Resources: Investigation Guide

Version: 312

Rule authors:

  • Elastic
  • Willem D’Haese
  • Austin Songer

Rule license: Elastic License v2

Investigation guide

edit

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 Attempts to Brute Force a Microsoft 365 User Account

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.

Possible investigation steps

  • 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.

False positive analysis

  • 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.

Response and remediation

  • 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.

Rule query

edit
from logs-o365.audit-*
// truncate the timestamp to a 30-minute window
| eval target_time_window = DATE_TRUNC(30 minutes, @timestamp)
| mv_expand event.category
| where event.dataset == "o365.audit"
  and event.category == "authentication"

  // filter only on Entra ID or Exchange audit logs in O365 integration
  and event.provider in ("AzureActiveDirectory", "Exchange")

  // filter only for UserLoginFailed or partial failures
  and event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword")

  // ignore specific logon errors
  and not o365.audit.LogonError in (
    "EntitlementGrantsNotFound",
    "UserStrongAuthEnrollmentRequired",
    "UserStrongAuthClientAuthNRequired",
    "InvalidReplyTo",
    "SsoArtifactExpiredDueToConditionalAccess",
    "PasswordResetRegistrationRequiredInterrupt",
    "SsoUserAccountNotFoundInResourceTenant",
    "UserStrongAuthExpired",
    "CmsiInterrupt"
)

  // ignore unavailable
  and o365.audit.UserId != "Not Available"

  // filters out non user or application logins based on target
  and o365.audit.Target.Type in ("0", "2", "3", "5", "6", "10")

  // filters only for logins from user or application, ignoring oauth:token
  and to_lower(o365.audit.ExtendedProperties.RequestType) rlike "(.*)login(.*)"

// keep only relevant fields
| 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

// count the number of login sources and failed login attempts
| stats
  login_source_count = count(source.ip),
  failed_login_count = count(*) by target_time_window, o365.audit.UserId

// filter for users with more than 20 login sources or failed login attempts
| where (login_source_count >= 20 or failed_login_count >= 20)

Framework: MITRE ATT&CKTM

« Attempted Private Key Access Attempts to Brute Force an Okta User Account »

On this page

Was this helpful?
Feedback