[New Rule] ConsentFix Detections

[terrancedejesus]

Pull Request

Issue link(s):

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

Summary

What is ConsentFix?

OAuth code theft attack targeting Microsoft 365/Entra ID. Attacker sends victim a phishing link that redirects to legitimate Microsoft OAuth authorization. Victim authenticates and gets redirected to localhost with the auth code in the URL. Attacker tricks victim into sharing that code via a fake error page, Signal, WhatsApp, etc. Attacker then exchanges the code for tokens from their own infrastructure.

The attack uses first-party Microsoft apps like Azure CLI, VSCode, and PowerShell because they use localhost redirect URIs and are trusted by default in all tenants. These apps cannot be blocked or deleted.

Why Legacy AAD Matters

Attackers intentionally target Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) instead of Microsoft Graph. It's deprecated, rarely used legitimately, and most detection rules only watch Graph.

Detection Rules

Rule	Data Source	Type	What It Catches
Entra ID OAuth Phishing via First-Party Microsoft Application	Azure Sign-in Logs	Query	Dev tools hitting Graph/AAD, any FOCI app hitting legacy AAD
M365 Identity OAuth Phishing via First-Party Microsoft Application	O365 Audit Logs	Query	Same logic, O365 data source, looks for OAuth2:Authorize + Redirect
M365 Identity OAuth Flow by First-Party Microsoft App from Multiple IPs	O365 Audit Logs	ESQL	Same user, same app, OAuth2:Authorize from IP A then OAuth2:Token from IP B
Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource	Azure Sign-in Logs	New Terms	First time a user+app+resource combo is seen in 14 days
Microsoft Graph Request User Impersonation by Unusual Client	Graph Activity Logs	New Terms	First time an app_id + user_principal_object_id combo hits Graph
Entra ID OAuth Phishing via VSCode Client	Azure Sign-in Logs	Query	VSCode specific detection (original rule)
M365 Identity OAuth Phishing via VSCode Client	O365 Audit Logs	Query	VSCode specific detection (original rule)
Microsoft Graph Email Access by Unusual Public Client	Graph Activity Logs	New Terms	Unusual public client accessing mail endpoints
Entra ID Single Session from Multiple Addresses	Azure Sign-in Logs	ESQL	Same session_id used from multiple IPs
Entra ID User Signed in from Unusual Device	Azure Sign-in Logs	New Terms	First time device seen for user

Split Detection Logic
In many cases, we can focus on FOCI to AAD and/or graph. FOCI to graph can be extremely noisy and benign, thus we only limit some high-fidelity ones to this while any FOCI to AAD should warrant an investigation.

Developer tools (3 apps) flagged for Graph OR Legacy AAD:

• Azure CLI: 04b07795-8ddb-461a-bbee-02f9e1bf7b46
• VSCode: aebc6443-996d-45c2-90f0-388ff96faa56
• Azure PowerShell: 1950a258-227b-4e31-a9cf-717495945fc2

Any FOCI app (35 apps) flagged for Legacy AAD only. Full list includes Teams, Outlook, Office, OneDrive, etc. Only flagged when hitting the deprecated legacy AAD resource.

References

• https://pushsecurity.com/blog/consentfix
• https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/
• https://github.com/secureworks/family-of-client-ids-research

How To Test

Please see the related issue for more details on emulation and testing.

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.

[Aegrah]

LGTM, only small suggestions for performance