[New Rule] Entra ID / M365 - Unusual ROPC Auth and/or Legacy Clients

[terrancedejesus]

Pull Request

Issue link(s):

• https://github.com/elastic/ia-trade-team/issues/906

Adds a couple detections around ROPC auth and legacy authentication clients for Entra ID and M365. Originally we only had ROPC in Entra ID, that has been added for M365 UAL logs. Also tuned a rule to be either ROPC auth or BAV2ROPC which is the default user-agent by MSFT for ROPC from legacy apps to use OAuth.

M365 OAuth ROPC Grant via Legacy Authenticated Client

Detects a successful M365 Unified Audit Log UserLoggedIn where user_agent.original is BAV2ROPC, indicating a legacy basic-auth client (SMTP/IMAP/POP/EAS) translated by Entra into a single-factor ROPC grant that bypasses interactive MFA. Serves as a backstop to the Entra Sign-In ROPC rule since UAL is a separate ingestion pipeline that still captures this login when non-interactive sign-in logs aren't forwarded.

New: Entra ID User Sign-In via Unusual Legacy Authentication Client

New Terms rule that fires when a Member user is first seen (in 7 days) successfully authenticating via any Microsoft-defined legacy client_app_used protocol, which is unusual in modern-auth environments and common in password spraying / account takeover. Uses an explicit legacy inclusion-list (not a "not-modern" exclusion) specifically to avoid the high-volume Unknown service-principal bucket, and keys on client_app_used rather than app_id because legacy basic-auth records the app as the benign Office 365 Exchange Online.

Summary - What I changed

How To Test

Queries can be used in TRADE stack and others.

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

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially 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, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[Copilot]

Pull request overview

Adds new detections and a tuning update to improve coverage for Entra ID / M365 legacy-auth and ROPC-style sign-ins (including the BAV2ROPC user agent), with the goal of catching password-spray / account takeover activity across both Entra Sign-In Logs and M365 Unified Audit Logs.

Changes:

• Adds a new M365 UAL New Terms rule for successful UserLoggedIn events with user_agent.original: "BAV2ROPC" (legacy client translated into ROPC).
• Adds a new Entra ID New Terms rule for first-time-seen legacy client_app_used values (Authenticated SMTP/IMAP/POP/EAS/etc.).
• Tunes the existing Entra ID ROPC New Terms rule to also match BAV2ROPC and refreshes references/updated_date.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
rules/integrations/o365/initial_access_identity_ropc_grant_via_legacy_authenticated_client.toml	New M365 UAL New Terms rule to detect first-seen successful BAV2ROPC sign-ins.
rules/integrations/azure/initial_access_entra_id_unusual_ropc_login_attempt.toml	Tunes existing Entra ROPC rule to include BAV2ROPC and updates metadata/references.
rules/integrations/azure/initial_access_entra_id_unusual_legacy_auth_client_signin.toml	New Entra New Terms rule to detect first-seen successful legacy client sign-ins via client_app_used.

[bryans3c]

Some nits, LGTM!