[Rule Tuning] Attempts to Brute Force a Microsoft 365 User Account

[ZsomborBenedek]

Link to rule

https://github.com/elastic/detection-rules/blob/259efaf7165be7105a2fb990e3b7146ad6997f8f/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml

Description

The aggregation should be based on the o365.audit.UserKey field as it represents the unique users. Currently the user.id is used, which can be the same for multiple user, e.g. "Not Available". This transforms the results in a way which causes a lot of false positives.

Change from this:

[rule.threshold]
field = ["user.id"]
value = 10

To this:

[rule.threshold]
field = ["o365.audit.UserKey"]
value = 10

Example Data

Screenshot (user Ids redacted for privacy):

[willemdh]

I can agree there is an issue, but if o365.audit.UserKey is the unique user identifier why isn't that field copied to user.id ?

[terrancedejesus]

@ZsomborBenedek - Thank you for creating this issue. I did some quick triaging and noticed that there are 3 specific fields in ES docs that hold user information: o365.audit.UserKey, o365.audit.UserId and o365.audit.Actor.ID. All of these seem to contain values that indicate whom the user or application is. While the integration does not specify what ECS field user.id derives from, my assumption is o365.audit.UserId based on a 1:1 in my testing stack and data.

This rule indeed needs tuned and could potentially benefit from being changes to ES|QL for better aggregations and some additional functionality.

Looking at MSFT documentation, we can probably tune some FPs with o365.audit.UserType, focusing solely on specific user types.

When time permits, I'll replicate brute forcing in my test environment and get a rule tuning in for this.