Skip to content

[Rule Tuning] Expand Scope of Entra ID Brute Force Sign-In Attempts #4777

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 11 commits into
base: main
Choose a base branch
from
Open

[Rule Tuning] Expand Scope of Entra ID Brute Force Sign-In Attempts #4777

wants to merge 11 commits into from

Conversation

terrancedejesus
Copy link
Contributor

@terrancedejesus terrancedejesus commented Jun 5, 2025 •
edited
Loading

Pull Request

Issue link(s):

Summary - What I changed

Adjusts the Azure Entra ID Password Spraying (Non-Interactive SFA) rule to expand scope and limit error codes while adding additional columns for finalized dataset to help with post-investigation. Please see development linked issue (not meta) for more details.

How To Test

  • Query can be used in TRADE stack

Checklist

  • Added a label for the type of pr: bug, enhancement, schema, maintenance, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
  • Added the meta:rapid-merge label if planning to merge within 24 hours
  • Secret and sensitive material has been managed correctly
  • Automated testing was updated or added to match the most common scenarios
  • Documentation and comments were added for features that require explanation

Contributor checklist

@terrancedejesus terrancedejesus linked an issue Jun 5, 2025 that may be closed by this pull request
[Rule Tuning] Expand Scope of Entra ID Brute Force Sign-In Attempts #4776
Open
@terrancedejesus terrancedejesus self-assigned this Jun 5, 2025
@terrancedejesus terrancedejesus added Integration: Azure azure related rules Rule: Tuning tweaking or tuning an existing rule Domain: Identity labels Jun 5, 2025
@github-actions GitHub Actions
Copy link
Contributor

github-actions bot commented Jun 5, 2025

Rule: Tuning - Guidelines

These guidelines serve as a reminder set of considerations when tuning an existing rule.

Documentation and Context

  • Detailed description of the suggested changes.
  • Provide example JSON data or screenshots.
  • Provide evidence of reducing benign events mistakenly identified as threats (False Positives).
  • Provide evidence of enhancing detection of true threats that were previously missed (False Negatives).
  • Provide evidence of optimizing resource consumption and execution time of detection rules (Performance).
  • Provide evidence of specific environment factors influencing customized rule tuning (Contextual Tuning).
  • Provide evidence of improvements made by modifying sensitivity by changing alert triggering thresholds (Threshold Adjustments).
  • Provide evidence of refining rules to better detect deviations from typical behavior (Behavioral Tuning).
  • Provide evidence of improvements of adjusting rules based on time-based patterns (Temporal Tuning).
  • Provide reasoning of adjusting priority or severity levels of alerts (Severity Tuning).
  • Provide evidence of improving quality integrity of our data used by detection rules (Data Quality).
  • Ensure the tuning includes necessary updates to the release documentation and versioning.

Rule Metadata Checks

  • updated_date matches the date of tuning PR merged.
  • min_stack_version should support the widest stack versions.
  • name and description should be descriptive and not include typos.
  • query should be inclusive, not overly exclusive. Review to ensure the original intent of the rule is maintained.

Testing and Validation

  • Validate that the tuned rule's performance is satisfactory and does not negatively impact the stack.
  • Ensure that the tuned rule has a low false positive rate.

@terrancedejesus terrancedejesus marked this pull request as ready for review June 5, 2025 17:04
@terrancedejesus terrancedejesus mentioned this pull request Jun 6, 2025
Closed
@terrancedejesus terrancedejesus requested a review from w0rk3r June 10, 2025 14:29
Aegrah
Aegrah approved these changes Jun 16, 2025
View reviewed changes
Copy link
Contributor

@Aegrah Aegrah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very cool rule/query @terrancedejesus !

rules/integrations/azure/credential_access_entra_id_brute_force_activity.toml
Comment on lines +111 to +113
AND azure.signinlogs.properties.authentication_requirement == "singleFactorAuthentication"
AND error_code != 50053
| WHERE azure.signinlogs.properties.status.error_code IN (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason you set error_code to azure.signinlogs.properties.status.error_code, and then use error_code in the first WHERE but azure.signinlogs.properties.status.error_code in the second?

rules/integrations/azure/credential_access_entra_id_brute_force_activity.toml
Comment on lines +103 to +104
country = source.geo.country_name,
user_agent = user_agent.original,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these EVAL's costly in terms of performance, or not at all?

rules/integrations/azure/credential_access_entra_id_brute_force_activity.toml
incoming_token_type, risk_state, session_id, user_id,
user_principal_name, result_description, result_signature, result_type

| WHERE bf_type != "other"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This excludes any other bf_type's from the results?

rules/integrations/azure/credential_access_entra_id_brute_force_activity.toml
incoming_token_type, risk_state, session_id, user_id,
user_principal_name, result_description, result_signature, result_type

| WHERE bf_type != "other"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we want to do any sorting/limiting at the end.

imays11
imays11 reviewed Jun 16, 2025
View reviewed changes
rules/integrations/azure/credential_access_entra_id_brute_force_activity.toml
AND azure.signinlogs.category IN ("NonInteractiveUserSignInLogs", "SignInLogs")
AND event.outcome == "failure"
AND azure.signinlogs.properties.authentication_requirement == "singleFactorAuthentication"
AND error_code != 50053
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this exclusion is necessary right? since you include the error_codes you want to evaluate in the next section

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@imays11 imays11 imays11 approved these changes

@Aegrah Aegrah Aegrah approved these changes

@DefSecSentinel DefSecSentinel Awaiting requested review from DefSecSentinel

@Samirbous Samirbous Awaiting requested review from Samirbous

@w0rk3r w0rk3r Awaiting requested review from w0rk3r

Assignees

@terrancedejesus terrancedejesus

Labels
backport: auto Domain: Cloud Domain: Identity Integration: Azure azure related rules Rule: Tuning tweaking or tuning an existing rule
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

[Rule Tuning] Expand Scope of Entra ID Brute Force Sign-In Attempts
3 participants
@terrancedejesus @imays11 @Aegrah