[Rule Tuning] Azure Entra Sign-in Brute Force against Microsoft 365 Accounts

[willem-dhaese]

Link to Rule

https://github.com/elastic/detection-rules/blob/main/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml

Rule Tuning Type

Contextual Tuning - Customizing rules based on specific environment factors.

Description

Hello,

The rule Azure Entra Sign-in Brute Force against Microsoft 365 Accounts is super noisy and very hard to troubleshoot. The calculated fields are not usable in the Kibana Alerts gui. There is no context available such as User Agent and Azure Resource. Some user agents are hard to translate into something we can work with.

We did multiple changes:

1. and user_agent.original != "Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0"
2. Changed the threshold from 20 to 100
3. Group by azure.signinlogs.properties.app_display_name and user_agent.original
4. We added highlighted fields azure.signinlogs.properties.user_principal_name, failed_login_count and login_source_count

from logs-azure.signinlogs*
// truncate the timestamp to a 30-minute window
| eval target_time_window = DATE_TRUNC(30 minutes, @timestamp)
| WHERE
  event.dataset == "azure.signinlogs"
  and event.category == "authentication"
  and to_lower(azure.signinlogs.properties.resource_display_name) rlike "(.*)365(.*)"
  and azure.signinlogs.category in ("NonInteractiveUserSignInLogs", "SignInLogs")
  and event.outcome != "success"
  and user_agent.original != "Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0"
  // for tuning review azure.signinlogs.properties.status.error_code
  // https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes
 
// keep only relevant fields
| keep target_time_window, event.dataset, event.category, event.outcome, azure.signinlogs.properties.user_principal_name, azure.signinlogs.properties.resource_display_name, azure.signinlogs.properties.app_display_name, azure.signinlogs.properties.client_app_used, azure.signinlogs.properties.user_type, azure.signinlogs.properties.device_detail.operating_system, azure.signinlogs.properties.authentication_requirement, source.ip, user_agent.original
 
// 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, azure.signinlogs.properties.user_principal_name, azure.signinlogs.properties.app_display_name, user_agent.original

I can understand the se changes are specific to our needs. But is there some way to put the calculated fields in an ECS field (to be created) which is actually mapped so we can add these fields to the Alerts table?

Is the "login_source_count = count(source.ip)" expected? login_source_count and failed_login_count are acutally alsways the same.. Is it possible this needs to be distinct count (unique) of source.ip?

Example Data

No response

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jvalente-salemstate]

Is the "login_source_count = count(source.ip)" expected? login_source_count and failed_login_count are acutally alsways the same.. Is it possible this needs to be distinct count (unique) of source.ip?

It looks like both count_distinct() and a lower threshold for failed_source_count than failed_login_count would be needed. Presently, both values certainly seem to be always to be identical, and using a distinct count alone will always have a less than or equal to value than failed_login_count due to the time bucketing. I'm unsure what a reasonable lower value would be, however.

I can understand the se changes are specific to our needs. But is there some way to put the calculated fields in an ECS field (to be created) which is actually mapped so we can add these fields to the Alerts table?

I agree here. user.name is captured in the original event, so capturing that or adding | eval user.name = azure.signinlogs.properties.user_principal_name to the query would also work.

STATS ... related.ip = values(source.ip) ... by ... might also be a good way to capture source addresses but the function is not GA, and it is possible there may be a very large number of IPs in the array.