From 8b293e78675ace89bca1683bab14e32c551b68e8 Mon Sep 17 00:00:00 2001 From: terrancedejesus Date: Wed, 17 Dec 2025 11:18:21 -0500 Subject: [PATCH 1/4] adjusting/adding consentfix detections --- ...ss_by_unusual_public_client_via_graph.toml | 3 +- ...ingle_session_from_multiple_addresses.toml | 3 +- ..._code_grant_unusual_app_resource_user.toml | 232 ++++++++++++++++++ ...via_first_party_microsoft_application.toml | 204 +++++++++++++++ ...a_id_oauth_phishing_via_vscode_client.toml | 133 ---------- ...ph_first_occurrence_of_client_request.toml | 5 +- ...id_user_signed_in_from_unusual_device.toml | 36 +-- ...on_entra_id_susp_oauth2_authorization.toml | 91 ++++++- ...via_first_party_microsoft_application.toml | 196 +++++++++++++++ ...tity_oauth_phishing_via_vscode_client.toml | 120 --------- 10 files changed, 743 insertions(+), 280 deletions(-) create mode 100644 rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml create mode 100644 rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml delete mode 100644 rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_vscode_client.toml create mode 100644 rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml delete mode 100644 rules/integrations/o365/initial_access_identity_oauth_phishing_via_vscode_client.toml diff --git a/rules/integrations/azure/collection_graph_email_access_by_unusual_public_client_via_graph.toml b/rules/integrations/azure/collection_graph_email_access_by_unusual_public_client_via_graph.toml index 8b1d5135143..7a574219237 100644 --- a/rules/integrations/azure/collection_graph_email_access_by_unusual_public_client_via_graph.toml +++ b/rules/integrations/azure/collection_graph_email_access_by_unusual_public_client_via_graph.toml @@ -2,7 +2,7 @@ creation_date = "2025/05/06" integration = ["azure"] maturity = "production" -updated_date = "2025/12/10" +updated_date = "2025/12/17" [rule] author = ["Elastic"] @@ -61,6 +61,7 @@ references = [ "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", "https://github.com/dirkjanm/ROADtools", "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/", + "https://pushsecurity.com/blog/consentfix", ] risk_score = 47 rule_id = "e882e934-2aaa-11f0-8272-f661ea17fbcc" diff --git a/rules/integrations/azure/initial_access_entra_id_graph_single_session_from_multiple_addresses.toml b/rules/integrations/azure/initial_access_entra_id_graph_single_session_from_multiple_addresses.toml index afc9dd67b72..67c5edccbc2 100644 --- a/rules/integrations/azure/initial_access_entra_id_graph_single_session_from_multiple_addresses.toml +++ b/rules/integrations/azure/initial_access_entra_id_graph_single_session_from_multiple_addresses.toml @@ -2,7 +2,7 @@ creation_date = "2025/05/08" integration = ["azure"] maturity = "production" -updated_date = "2025/12/10" +updated_date = "2025/12/17" [rule] author = ["Elastic"] @@ -64,6 +64,7 @@ references = [ "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", "https://github.com/dirkjanm/ROADtools", "https://attack.mitre.org/techniques/T1078/004/", + "https://pushsecurity.com/blog/consentfix", ] risk_score = 47 rule_id = "0d3d2254-2b4a-11f0-a019-f661ea17fbcc" diff --git a/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml b/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml new file mode 100644 index 00000000000..ee883ca87e5 --- /dev/null +++ b/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml @@ -0,0 +1,232 @@ +[metadata] +creation_date = "2025/12/17" +integration = ["azure"] +maturity = "production" +updated_date = "2025/12/17" + +[rule] +author = ["Elastic"] +description = """ +Identifies the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client +application, target resource, and user principal in Microsoft Entra ID. This rule uses split detection logic: (1) +Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing either Microsoft Graph or legacy AAD +are flagged for first-time usage by a user. (2) Any FOCI (Family of Client IDs) application accessing legacy Windows +Azure Active Directory for the first time by a user is flagged, as this deprecated resource is rarely accessed +legitimately. This pattern is indicative of OAuth phishing attacks like ConsentFix, where attackers steal authorization +codes and exchange them for tokens from attacker-controlled infrastructure. +""" +from = "now-9m" +index = ["filebeat-*", "logs-azure.signinlogs-*"] +language = "kuery" +license = "Elastic License v2" +name = "Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource" +note = """## Triage and analysis + +### Investigating Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource + +This rule identifies the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application ID, target resource ID, and user principal in Microsoft Entra ID. This is a New Terms rule that only fires when a user has not been observed using this specific app+resource combination in the last 14 days. + +**Why This Matters for ConsentFix Detection:** + +ConsentFix and similar OAuth phishing attacks exploit first-party Microsoft applications (Azure CLI, VS Code, Azure PowerShell) because: +- They are trusted by default in all tenants +- They can request permissions without admin approval +- They cannot be deleted or blocked + +When an attacker steals an OAuth authorization code and exchanges it for tokens, the resulting sign-in event shows: +- The victim's UPN +- The first-party app ID (e.g., Azure CLI) +- A target resource (often legacy AAD for stealth) + +If a user has never used Azure CLI to access Windows Azure Active Directory before, this is highly suspicious. + +**Detection Logic 1 - Developer Tools → Graph or Legacy AAD (First-Time)**: +- **Azure CLI**: `04b07795-8ddb-461a-bbee-02f9e1bf7b46` +- **Visual Studio Code**: `aebc6443-996d-45c2-90f0-388ff96faa56` +- **Azure PowerShell**: `1950a258-227b-4e31-a9cf-717495945fc2` + +**Detection Logic 2 - Any FOCI App → Legacy AAD Only (First-Time)**: +Any of the 38 FOCI family applications (Microsoft Office, Teams, Outlook, OneDrive, etc.) accessing legacy Windows Azure Active Directory for the first time by a user is suspicious because this deprecated API is rarely used legitimately. + +### Sensitive Target Resources: +- **Windows Azure Active Directory (Legacy)**: `00000002-0000-0000-c000-000000000000` - Deprecated, rarely legitimate +- **Microsoft Graph**: `00000003-0000-0000-c000-000000000000` - Common but verify context + +### Possible investigation steps + +- Review `azure.signinlogs.properties.user_principal_name` to identify the affected user. +- Confirm the `azure.signinlogs.properties.app_id` matches a first-party Microsoft application. If it's Azure CLI or Azure PowerShell and the user doesn't typically use these tools, this is suspicious. +- Check `azure.signinlogs.properties.resource_id` to identify what resource was accessed. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access by developer tools is unusual. +- Analyze `source.ip` and `source.geo.*` for geographic anomalies. ConsentFix attackers exchange codes from different IPs than the victim. +- Review `azure.signinlogs.properties.is_interactive` - if this is a non-interactive sign-in shortly after an interactive one from a different IP, it may indicate token replay. +- Check `azure.signinlogs.properties.session_id` and correlate with other sign-in events to identify the full OAuth flow sequence. +- Look for subsequent Graph API or AAD API activity from the same session or user from unusual locations. + +### False positive analysis + +- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code for the first time to access specific resources. +- Users onboarding to new development environments or tools. +- Automation scripts that run with user-delegated permissions for the first time. + +### Response and remediation + +- Contact the user to confirm if they initiated the OAuth flow and used the detected application. +- If unauthorized, immediately revoke all refresh tokens for the user via Entra ID. +- Review recent activity from the same session ID for signs of data access or enumeration. +- Block the source IP if confirmed malicious. +- Implement Conditional Access policies to restrict OAuth flows for these applications. +- Educate users about OAuth phishing and the risks of pasting authorization codes. +""" +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://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow", + "https://github.com/secureworks/family-of-client-ids-research", +] +risk_score = 47 +rule_id = "c8e5f6a2-1234-4d5e-9f8a-b7c6d5e4f3a2" +severity = "medium" +tags = [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Initial Access", + "Tactic: Credential Access", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "new_terms" + +query = ''' +event.dataset: "azure.signinlogs" and + event.outcome: "success" and + azure.signinlogs.properties.user_type: "Member" and + ( + ( + azure.signinlogs.properties.app_id: ( + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "1950a258-227b-4e31-a9cf-717495945fc2" + ) and + azure.signinlogs.properties.resource_id: ( + "00000002-0000-0000-c000-000000000000" or + "00000003-0000-0000-c000-000000000000" + ) + ) or + ( + azure.signinlogs.properties.app_id: ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "844cca35-0656-46ce-b636-13f48b0eecbd" or + "87749df4-7ccf-48f8-aa87-704bad0e0e16" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "22098786-6e16-43cc-a27d-191a01a1e3b5" or + "4e291c71-d680-4d0e-9640-0a3358e31177" or + "57336123-6e14-4acc-8dcf-287b6088aa28" or + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0" or + "66375f6b-983f-4c2c-9701-d680650f588f" or + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or + "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a569458c-7f2b-45cb-bab9-b7dee514d112" or + "b26aadf8-566f-4478-926f-589f601d9c74" or + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "eb539595-3fe1-474e-9c1d-feb3625d1be5" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "be1918be-3fe3-4be9-b32b-b542fc27f02e" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3" or + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) and + azure.signinlogs.properties.resource_id: "00000002-0000-0000-c000-000000000000" + ) + ) +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1078" +name = "Valid Accounts" +reference = "https://attack.mitre.org/techniques/T1078/" +[[rule.threat.technique.subtechnique]] +id = "T1078.004" +name = "Cloud Accounts" +reference = "https://attack.mitre.org/techniques/T1078/004/" + + +[[rule.threat.technique]] +id = "T1566" +name = "Phishing" +reference = "https://attack.mitre.org/techniques/T1566/" +[[rule.threat.technique.subtechnique]] +id = "T1566.002" +name = "Spearphishing Link" +reference = "https://attack.mitre.org/techniques/T1566/002/" + + + +[rule.threat.tactic] +id = "TA0001" +name = "Initial Access" +reference = "https://attack.mitre.org/tactics/TA0001/" +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1528" +name = "Steal Application Access Token" +reference = "https://attack.mitre.org/techniques/T1528/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "azure.signinlogs.properties.user_principal_name", + "azure.signinlogs.properties.app_id", + "azure.signinlogs.properties.app_display_name", + "azure.signinlogs.properties.resource_id", + "azure.signinlogs.properties.resource_display_name", + "azure.signinlogs.properties.is_interactive", + "azure.signinlogs.properties.session_id", + "azure.signinlogs.properties.incoming_token_type", + "source.ip", + "source.geo.country_name", + "source.geo.city_name", + "user_agent.original", +] + +[rule.new_terms] +field = "new_terms_fields" +value = [ + "azure.signinlogs.properties.user_principal_name", + "azure.signinlogs.properties.app_id", + "azure.signinlogs.properties.resource_id", +] +[[rule.new_terms.history_window_start]] +field = "history_window_start" +value = "now-14d" + + diff --git a/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml b/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml new file mode 100644 index 00000000000..ff6dbdadeb2 --- /dev/null +++ b/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml @@ -0,0 +1,204 @@ +[metadata] +creation_date = "2025/04/23" +integration = ["azure"] +maturity = "production" +updated_date = "2025/12/17" + +[rule] +author = ["Elastic"] +description = """ +Detects potentially suspicious OAuth authorization activity in Microsoft Entra ID where first-party Microsoft +applications from the FOCI (Family of Client IDs) group are used to request access to Microsoft Graph or legacy Azure AD +resources. This rule uses split detection logic: (1) Developer tools like Azure CLI, Visual Studio Code, and Azure +PowerShell accessing either Microsoft Graph or legacy AAD are flagged, as these are commonly abused in phishing +campaigns like ConsentFix. (2) Any FOCI family application accessing legacy Windows Azure Active Directory +(00000002-0000-0000-c000-000000000000) is flagged, as this deprecated resource is rarely accessed legitimately and +attackers use it for stealth. First-party apps are trusted by default in all tenants, allowed to request permissions +without admin approval, and cannot be deleted or blocked - making them ideal for OAuth phishing attacks. +""" +from = "now-9m" +index = ["filebeat-*", "logs-azure.signinlogs-*"] +language = "kuery" +license = "Elastic License v2" +name = "Entra ID OAuth Phishing via First-Party Microsoft Application" +note = """## Triage and analysis + +### Investigating Entra ID OAuth Phishing via First-Party Microsoft Application + +This rule identifies successful Entra ID sign-ins where first-party Microsoft applications from the FOCI (Family of Client IDs) group are used in potentially suspicious OAuth flows. The rule uses split detection logic: + +**Detection Logic 1 - Developer Tools → Graph or Legacy AAD:** +- **Visual Studio Code** (`aebc6443-996d-45c2-90f0-388ff96faa56`) +- **Azure CLI** (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`) +- **Azure PowerShell** (`1950a258-227b-4e31-a9cf-717495945fc2`) + +These developer tools accessing Microsoft Graph or legacy AAD are flagged because they use localhost redirect URIs, making them ideal for OAuth code theft attacks like ConsentFix. + +**Detection Logic 2 - Any FOCI App → Legacy AAD Only:** +Any of the 38 FOCI family applications accessing legacy Windows Azure Active Directory (`00000002-0000-0000-c000-000000000000`) is suspicious because this deprecated API is rarely used legitimately. Attackers intentionally target legacy AAD to evade detection rules focused on Microsoft Graph. + +**FOCI Family Applications** (partial list - see Secureworks research for full list): +- Microsoft Office, Teams, Outlook Mobile, OneDrive, SharePoint +- Microsoft Edge, Power BI, Intune Company Portal, Microsoft Authenticator +- And 30+ other Microsoft first-party applications + +**ConsentFix Attack Pattern**: Victims land on compromised high-reputation websites via search engines, are shown a fake Cloudflare Turnstile, and tricked into completing a legitimate Microsoft OAuth flow. The redirect URL contains a localhost URI with an authorization code that victims are socially engineered to paste back into the attacker's page. The attacker then uses Azure CLI to exchange the code for tokens and access legacy AAD/Intune resources. + +### Possible investigation steps + +- Review `azure.signinlogs.properties.user_principal_name` to identify the affected user and determine if they are a high-value target (privileged roles, executives, IT admins). +- Analyze `source.ip` and `source.geo.*` for geographic anomalies. ConsentFix attackers exchange codes from different IPs than the victim's location. +- Check `azure.signinlogs.properties.app_id` and `azure.signinlogs.properties.app_display_name` to confirm which first-party application was used. Azure CLI access by non-developers is suspicious. +- Examine `azure.signinlogs.properties.resource_id` to identify the target resource: + - `00000002-0000-0000-c000-000000000000` = Windows Azure Active Directory (legacy) - unusual for most users + - `00000003-0000-0000-c000-000000000000` = Microsoft Graph - common but verify context +- Review `azure.signinlogs.properties.is_interactive` - non-interactive sign-ins shortly after interactive ones from different IPs indicate token replay. +- Check `azure.signinlogs.properties.session_id` to correlate with other sign-in events and identify the full OAuth flow sequence. +- Look at `user_agent.original` for suspicious patterns (automation tools, headless browsers, unusual browser/OS combinations). +- Search for subsequent Graph API or AAD API activity from the same session or user from unusual locations. +- Check `azure.signinlogs.properties.device_detail` to determine if the sign-in came from a managed/compliant device. + +### False positive analysis + +- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code to access Microsoft Graph or Azure AD. +- Legitimate Visual Studio Code extensions that sync or query Graph API data (calendars, tasks, cloud-hosted notebooks). +- Enterprise automation or CI/CD pipelines using these tools with user-delegated permissions. +- Users working from multiple locations (VPN, travel) may show different IPs. +- Corporate proxies or VPNs may show unexpected IP addresses. +- Consider excluding known developer machines, managed devices, or specific user groups that regularly use these tools. +- Add exceptions for specific source IPs tied to corporate infrastructure or known developer environments. + +### Response and remediation + +- Contact the user immediately to confirm if they initiated the OAuth flow and used the detected application. +- If unauthorized, revoke all refresh tokens for the user via Microsoft Entra ID portal or PowerShell. +- Review the user's recent Microsoft Graph activity (email access, file downloads, Teams messages) for signs of data exfiltration. +- Block the source IP if confirmed malicious. +- Check for any devices registered during this session and remove unauthorized device registrations. +- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices only. +- Educate users about OAuth phishing and the risks of pasting authorization codes into websites. +- Consider blocking localhost redirect URIs for OAuth flows where possible. +- Monitor for follow-on activity such as privilege escalation, lateral movement, or data access. +""" +references = [ + "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema", + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://pushsecurity.com/blog/consentfix", + "https://github.com/secureworks/family-of-client-ids-research", +] +risk_score = 47 +rule_id = "14fa0285-fe78-4843-ac8e-f4b481f49da9" +severity = "medium" +tags = [ + "Domain: Cloud", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Resources: Investigation Guide", + "Tactic: Initial Access", +] +timestamp_override = "event.ingested" +type = "query" + +query = ''' +event.dataset: "azure.signinlogs" and +event.action: "Sign-in activity" and +event.outcome: "success" and +( + ( + azure.signinlogs.properties.app_id: ( + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "1950a258-227b-4e31-a9cf-717495945fc2" + ) and ( + azure.signinlogs.properties.resource_id: ("00000003-0000-0000-c000-000000000000" or "00000002-0000-0000-c000-000000000000") or + azure.signinlogs.properties.resource_display_name: ("Microsoft Graph" or "Windows Azure Active Directory") + ) + ) or + ( + azure.signinlogs.properties.app_id: ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "844cca35-0656-46ce-b636-13f48b0eecbd" or + "87749df4-7ccf-48f8-aa87-704bad0e0e16" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "22098786-6e16-43cc-a27d-191a01a1e3b5" or + "4e291c71-d680-4d0e-9640-0a3358e31177" or + "57336123-6e14-4acc-8dcf-287b6088aa28" or + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0" or + "66375f6b-983f-4c2c-9701-d680650f588f" or + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or + "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a569458c-7f2b-45cb-bab9-b7dee514d112" or + "b26aadf8-566f-4478-926f-589f601d9c74" or + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "eb539595-3fe1-474e-9c1d-feb3625d1be5" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "be1918be-3fe3-4be9-b32b-b542fc27f02e" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3" or + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) and ( + azure.signinlogs.properties.resource_id: "00000002-0000-0000-c000-000000000000" or + azure.signinlogs.properties.resource_display_name: "Windows Azure Active Directory" + ) + ) +) +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1078" +name = "Valid Accounts" +reference = "https://attack.mitre.org/techniques/T1078/" +[[rule.threat.technique.subtechnique]] +id = "T1078.004" +name = "Cloud Accounts" +reference = "https://attack.mitre.org/techniques/T1078/004/" + + +[[rule.threat.technique]] +id = "T1566" +name = "Phishing" +reference = "https://attack.mitre.org/techniques/T1566/" +[[rule.threat.technique.subtechnique]] +id = "T1566.002" +name = "Spearphishing Link" +reference = "https://attack.mitre.org/techniques/T1566/002/" + + + +[rule.threat.tactic] +id = "TA0001" +name = "Initial Access" +reference = "https://attack.mitre.org/tactics/TA0001/" +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1528" +name = "Steal Application Access Token" +reference = "https://attack.mitre.org/techniques/T1528/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + diff --git a/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_vscode_client.toml b/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_vscode_client.toml deleted file mode 100644 index 0883f2c5acc..00000000000 --- a/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_vscode_client.toml +++ /dev/null @@ -1,133 +0,0 @@ -[metadata] -creation_date = "2025/04/23" -integration = ["azure"] -maturity = "production" -updated_date = "2025/12/10" - -[rule] -author = ["Elastic"] -description = """ -Detects potentially suspicious OAuth authorization activity in Microsoft Entra ID where the Visual Studio Code -first-party application (client_id = aebc6443-996d-45c2-90f0-388ff96faa56) is used to request access to Microsoft Graph -resources. While this client ID is legitimately used by Visual Studio Code, threat actors have been observed abusing it -in phishing campaigns to make OAuth requests appear trustworthy. These attacks rely on redirect URIs such as VSCode's -Insiders redirect location, prompting victims to return an OAuth authorization code that can be exchanged for access -tokens. This rule may help identify unauthorized use of the VS Code OAuth flow as part of social engineering or -credential phishing activity. -""" -from = "now-9m" -index = ["filebeat-*", "logs-azure.signinlogs-*"] -language = "kuery" -license = "Elastic License v2" -name = "Entra ID OAuth Flow by Visual Studio Code to Microsoft Graph" -note = """## Triage and analysis - -### Investigating Entra ID OAuth Flow by Visual Studio Code to Microsoft Graph - -### Possible investigation steps - -- Identify the source IP address from which the failed login attempts originated by reviewing `source.ip`. Determine if the IP is associated with known malicious activity using threat intelligence sources or if it belongs to a corporate VPN, proxy, or automation process. -- Analyze affected user accounts by reviewing `azure.signinlogs.properties.user_principal_name` to determine if they belong to privileged roles or high-value users. Look for patterns indicating multiple failed attempts across different users, which could suggest a password spraying attempt. -- Examine the authentication method used in `azure.signinlogs.properties.authentication_details` to identify which authentication protocols were attempted and why they failed. Legacy authentication methods may be more susceptible to brute-force attacks. -- Review the authentication error codes found in `azure.signinlogs.properties.status.error_code` to understand why the login attempts failed. Common errors include `50126` for invalid credentials, `50053` for account lockouts, `50055` for expired passwords, and `50056` for users without a password. -- Correlate failed logins with other sign-in activity by looking at `event.outcome`. Identify if there were any successful logins from the same user shortly after multiple failures or if there are different geolocations or device fingerprints associated with the same account. -- Review `azure.signinlogs.properties.app_id` to identify which applications were initiating the authentication attempts. Determine if these applications are Microsoft-owned, third-party, or custom applications and if they are authorized to access the resources. -- Check for any conditional access policies that may have been triggered by the failed login attempts by reviewing `azure.signinlogs.properties.authentication_requirement`. This can help identify if the failed attempts were due to policy enforcement or misconfiguration. - -## False positive analysis - -- Automated scripts or applications using non-interactive authentication may trigger this detection, particularly if they rely on legacy authentication protocols recorded in `azure.signinlogs.properties.authentication_protocol`. -- Corporate proxies or VPNs may cause multiple users to authenticate from the same IP, appearing as repeated failed attempts under `source.ip`. -- User account lockouts from forgotten passwords or misconfigured applications may show multiple authentication failures in `azure.signinlogs.properties.status.error_code`. -- Exclude known trusted IPs, such as corporate infrastructure, from alerts by filtering `source.ip`. -- Exlcude known custom applications from `azure.signinlogs.properties.app_id` that are authorized to use non-interactive authentication. -- Ignore principals with a history of failed logins due to legitimate reasons, such as expired passwords or account lockouts, by filtering `azure.signinlogs.properties.user_principal_name`. -- Correlate sign-in failures with password reset events or normal user behavior before triggering an alert. - -## Response and remediation - -- Block the source IP address in `source.ip` if determined to be malicious. -- Reset passwords for all affected user accounts listed in `azure.signinlogs.properties.user_principal_name` and enforce stronger password policies. -- Ensure basic authentication is disabled for all applications using legacy authentication protocols listed in `azure.signinlogs.properties.authentication_protocol`. -- Enable multi-factor authentication (MFA) for impacted accounts to mitigate credential-based attacks. -- Review conditional access policies to ensure they are correctly configured to block unauthorized access attempts recorded in `azure.signinlogs.properties.authentication_requirement`. -- Review Conditional Access policies to enforce risk-based authentication and block unauthorized access attempts recorded in `azure.signinlogs.properties.authentication_requirement`. -- Implement a zero-trust security model by enforcing least privilege access and continuous authentication. -- Regularly review and update conditional access policies to ensure they are effective against evolving threats. -- Restrict the use of legacy authentication protocols by disabling authentication methods listed in `azure.signinlogs.properties.client_app_used`. -- Regularly audit authentication logs in `azure.signinlogs` to detect abnormal login behavior and ensure early detection of potential attacks. -- Regularly rotate client credentials and secrets for applications using non-interactive authentication to reduce the risk of credential theft. -""" -references = [ - "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema", - "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", -] -risk_score = 47 -rule_id = "14fa0285-fe78-4843-ac8e-f4b481f49da9" -severity = "medium" -tags = [ - "Domain: Cloud", - "Data Source: Azure", - "Data Source: Microsoft Entra ID", - "Data Source: Microsoft Entra ID Sign-in Logs", - "Use Case: Identity and Access Audit", - "Resources: Investigation Guide", - "Tactic: Initial Access", -] -timestamp_override = "event.ingested" -type = "query" - -query = ''' -event.dataset: "azure.signinlogs" and -event.action: "Sign-in activity" and -event.outcome: "success" and -( - azure.signinlogs.properties.resource_display_name: "Microsoft Graph" or - azure.signinlogs.properties.resource_id: "00000003-0000-0000-c000-000000000000" -) and ( - azure.signinlogs.properties.app_id: "aebc6443-996d-45c2-90f0-388ff96faa56" or - azure.signinlogs.properties.app_display_name: "Visual Studio Code" -) -''' - - -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" -[[rule.threat.technique.subtechnique]] -id = "T1078.004" -name = "Cloud Accounts" -reference = "https://attack.mitre.org/techniques/T1078/004/" - - -[[rule.threat.technique]] -id = "T1566" -name = "Phishing" -reference = "https://attack.mitre.org/techniques/T1566/" -[[rule.threat.technique.subtechnique]] -id = "T1566.002" -name = "Spearphishing Link" -reference = "https://attack.mitre.org/techniques/T1566/002/" - - - -[rule.threat.tactic] -id = "TA0001" -name = "Initial Access" -reference = "https://attack.mitre.org/tactics/TA0001/" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1528" -name = "Steal Application Access Token" -reference = "https://attack.mitre.org/techniques/T1528/" - - -[rule.threat.tactic] -id = "TA0006" -name = "Credential Access" -reference = "https://attack.mitre.org/tactics/TA0006/" - diff --git a/rules/integrations/azure/initial_access_graph_first_occurrence_of_client_request.toml b/rules/integrations/azure/initial_access_graph_first_occurrence_of_client_request.toml index fe9faf6495d..9599d43c6f0 100644 --- a/rules/integrations/azure/initial_access_graph_first_occurrence_of_client_request.toml +++ b/rules/integrations/azure/initial_access_graph_first_occurrence_of_client_request.toml @@ -2,7 +2,7 @@ creation_date = "2025/04/23" integration = ["azure"] maturity = "production" -updated_date = "2025/12/10" +updated_date = "2025/12/17" [rule] author = ["Elastic"] @@ -74,6 +74,7 @@ Adversaries frequently exploit legitimate Microsoft or third-party application I """ references = [ "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://pushsecurity.com/blog/consentfix", ] risk_score = 21 rule_id = "2a3f38a8-204e-11f0-9c1f-f661ea17fbcd" @@ -134,7 +135,7 @@ reference = "https://attack.mitre.org/tactics/TA0006/" field = "new_terms_fields" value = [ "azure.graphactivitylogs.properties.app_id", - "azure.graphactivitylogs.properties.user_principal_object_id" + "azure.graphactivitylogs.properties.user_principal_object_id", ] [[rule.new_terms.history_window_start]] field = "history_window_start" diff --git a/rules/integrations/azure/persistence_entra_id_user_signed_in_from_unusual_device.toml b/rules/integrations/azure/persistence_entra_id_user_signed_in_from_unusual_device.toml index d445e30039b..fdd0c4a9a37 100644 --- a/rules/integrations/azure/persistence_entra_id_user_signed_in_from_unusual_device.toml +++ b/rules/integrations/azure/persistence_entra_id_user_signed_in_from_unusual_device.toml @@ -2,7 +2,7 @@ creation_date = "2025/06/16" integration = ["azure"] maturity = "production" -updated_date = "2025/12/10" +updated_date = "2025/12/17" [rule] author = ["Elastic"] @@ -47,6 +47,11 @@ This rule detects when a Microsoft Entra ID user signs in from a device that is - Identify the registered Entra ID device by reviewing `azure.signinlogs.properties.device_detail.display_name` and confirm it is expected for the user or organization. If it is not expected, consider removing the device registration. - Consider adding exceptions for verified devices that are known to be used by the user to reduce false-positives. """ +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://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/", +] risk_score = 21 rule_id = "72c91fc0-4ac0-11f0-811f-f661ea17fbcd" setup = """#### Required Microsoft Entra ID Sign-In Logs @@ -75,20 +80,6 @@ event.dataset: "azure.signinlogs" and azure.signinlogs.properties.user_principal_name: * ''' -[rule.investigation_fields] -field_names = [ - "azure.signinlogs.properties.user_principal_name", - "azure.signinlogs.properties.device_detail.device_id", - "azure.signinlogs.properties.incoming_token_type", - "azure.signinlogs.category", - "source.geo.country_name", - "source.geo.city_name", - "source.address", - "azure.signinlogs.properties.app_id", - "azure.signinlogs.properties.resource_id", - "azure.signinlogs.properties.risk_level", - "azure.signinlogs.properties.risk_detail", -] [[rule.threat]] framework = "MITRE ATT&CK" @@ -125,6 +116,21 @@ id = "TA0001" name = "Initial Access" reference = "https://attack.mitre.org/tactics/TA0001/" +[rule.investigation_fields] +field_names = [ + "azure.signinlogs.properties.user_principal_name", + "azure.signinlogs.properties.device_detail.device_id", + "azure.signinlogs.properties.incoming_token_type", + "azure.signinlogs.category", + "source.geo.country_name", + "source.geo.city_name", + "source.address", + "azure.signinlogs.properties.app_id", + "azure.signinlogs.properties.resource_id", + "azure.signinlogs.properties.risk_level", + "azure.signinlogs.properties.risk_detail", +] + [rule.new_terms] field = "new_terms_fields" value = [ diff --git a/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml b/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml index a4b369dff80..4054b5cecae 100644 --- a/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml +++ b/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml @@ -2,23 +2,41 @@ creation_date = "2025/05/01" integration = ["o365"] maturity = "production" -updated_date = "2025/12/10" +updated_date = "2025/12/17" [rule] author = ["Elastic"] description = """ -Identifies sign-ins on behalf of a principal user to the Microsoft Graph API from multiple IPs using the Microsoft -Authentication Broker or Visual Studio Code application. This behavior may indicate an adversary using a phished OAuth -refresh token. +Identifies sign-ins on behalf of a principal user to the Microsoft Graph or legacy Azure AD API from multiple IPs using +first-party Microsoft applications from the FOCI (Family of Client IDs) group. This rule uses split detection logic: (1) +Developer tools like Azure CLI, VSCode, Azure PowerShell, or Microsoft Authentication Broker accessing Graph or legacy +AAD from multiple IPs, or (2) Any FOCI family application accessing legacy Windows Azure Active Directory from multiple +IPs. This behavior may indicate an adversary using a phished OAuth authorization code or refresh token, as seen in +attacks like ConsentFix where attackers steal localhost OAuth codes and replay them from attacker infrastructure. """ from = "now-60m" interval = "59m" language = "esql" license = "Elastic License v2" -name = "M365 Identity OAuth Flow by Rare Client to Microsoft Graph" +name = "M365 Identity OAuth Flow by First-Party Microsoft App from Multiple IPs" note = """## Triage and analysis -### Investigating M365 Identity OAuth Flow by Rare Client to Microsoft Graph +### Investigating M365 Identity OAuth Flow by First-Party Microsoft App from Multiple IPs + +This rule detects when the same user authenticates to Microsoft Graph using first-party Microsoft applications from multiple IP addresses within a short time window. This pattern is indicative of OAuth code/token theft attacks like ConsentFix, where: + +1. Victim completes OAuth flow on their device (first IP) +2. Attacker exchanges stolen authorization code for tokens from their infrastructure (second IP) +3. Both events share the same user principal but originate from different locations + +**Detection Logic 1 - Developer Tools → Graph or Legacy AAD (Multi-IP)**: +- Visual Studio Code (`aebc6443-996d-45c2-90f0-388ff96faa56`) +- Microsoft Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) +- Azure CLI (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`) +- Azure PowerShell (`1950a258-227b-4e31-a9cf-717495945fc2`) + +**Detection Logic 2 - Any FOCI App → Legacy AAD Only (Multi-IP)**: +Any of the 38 FOCI family applications (Microsoft Office, Teams, Outlook, OneDrive, etc.) accessing legacy Windows Azure Active Directory from multiple IPs is suspicious because this deprecated API is rarely used legitimately. ### Possible Investigation Steps: @@ -45,6 +63,8 @@ references = [ "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", "https://github.com/dirkjanm/ROADtools", "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/", + "https://pushsecurity.com/blog/consentfix", + "https://github.com/secureworks/family-of-client-ids-research", ] risk_score = 73 rule_id = "36188365-f88f-4f70-8c1d-0b9554186b9c" @@ -76,8 +96,62 @@ from logs-o365.audit-* o365.audit.UserId is not null and o365.audit.ApplicationId is not null and o365.audit.UserType in ("0", "2", "3", "10") and - o365.audit.ApplicationId in ("aebc6443-996d-45c2-90f0-388ff96faa56", "29d9ed98-a469-4536-ade2-f981bc1d605e") and - o365.audit.ObjectId in ("00000003-0000-0000-c000-000000000000") + ( + /* Developer tools accessing Graph OR Legacy AAD */ + ( + o365.audit.ApplicationId in ( + "aebc6443-996d-45c2-90f0-388ff96faa56", + "29d9ed98-a469-4536-ade2-f981bc1d605e", + "04b07795-8ddb-461a-bbee-02f9e1bf7b46", + "1950a258-227b-4e31-a9cf-717495945fc2" + ) and + o365.audit.ObjectId in ( + "00000003-0000-0000-c000-000000000000", + "00000002-0000-0000-c000-000000000000" + ) + ) or + /* Any FOCI app accessing Legacy AAD only */ + ( + o365.audit.ApplicationId in ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2", + "1fec8e78-bce4-4aaf-ab1b-5451cc387264", + "26a7ee05-5602-4d76-a7ba-eae8b7b67941", + "27922004-5251-4030-b22d-91ecd9a37ea4", + "4813382a-8fa7-425e-ab75-3b753aab3abb", + "ab9b8c07-8f02-4f72-87fa-80105867a763", + "d3590ed6-52b3-4102-aeff-aad2292ab01c", + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1", + "af124e86-4e96-495a-b70a-90f90ab96707", + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8", + "844cca35-0656-46ce-b636-13f48b0eecbd", + "87749df4-7ccf-48f8-aa87-704bad0e0e16", + "cf36b471-5b44-428c-9ce7-313bf84528de", + "0ec893e0-5785-4de6-99da-4ed124e5296c", + "22098786-6e16-43cc-a27d-191a01a1e3b5", + "4e291c71-d680-4d0e-9640-0a3358e31177", + "57336123-6e14-4acc-8dcf-287b6088aa28", + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0", + "66375f6b-983f-4c2c-9701-d680650f588f", + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223", + "a40d7d7d-59aa-447e-a655-679a4107e548", + "a569458c-7f2b-45cb-bab9-b7dee514d112", + "b26aadf8-566f-4478-926f-589f601d9c74", + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12", + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0", + "e9c51622-460d-4d3d-952d-966a5b1da34c", + "eb539595-3fe1-474e-9c1d-feb3625d1be5", + "ecd6b820-32c2-49b6-98a6-444530e5a77a", + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d", + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34", + "be1918be-3fe3-4be9-b32b-b542fc27f02e", + "cab96880-db5b-4e15-90a7-f3f1d62ffe39", + "d7b530a4-7680-4c23-a8bf-c52c121d2e87", + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3", + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) and + o365.audit.ObjectId == "00000002-0000-0000-c000-000000000000" + ) + ) | eval Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp), Esql.oauth_authorize_user_id_case = case( @@ -158,6 +232,7 @@ name = "Spearphishing Link" reference = "https://attack.mitre.org/techniques/T1566/002/" + [rule.threat.tactic] id = "TA0001" name = "Initial Access" diff --git a/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml b/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml new file mode 100644 index 00000000000..712a4261abb --- /dev/null +++ b/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml @@ -0,0 +1,196 @@ +[metadata] +creation_date = "2025/04/23" +integration = ["o365"] +maturity = "production" +updated_date = "2025/12/17" + +[rule] +author = ["Elastic"] +description = """ +Detects potentially suspicious OAuth authorization activity in Microsoft 365 where first-party Microsoft applications +from the FOCI (Family of Client IDs) group are used to request access to Microsoft Graph or legacy Azure AD resources. +This rule uses split detection logic: (1) Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell +accessing either Microsoft Graph or legacy AAD are flagged, as these are commonly abused in phishing campaigns like +ConsentFix. (2) Any FOCI family application accessing legacy Windows Azure Active Directory +(00000002-0000-0000-c000-000000000000) is flagged, as this deprecated resource is rarely accessed legitimately and +attackers use it for stealth. First-party apps are trusted by default in all tenants, allowed to request permissions +without admin approval, and cannot be deleted or blocked - making them ideal for OAuth phishing attacks. +""" +from = "now-25m" +index = ["logs-o365.audit-*"] +language = "kuery" +license = "Elastic License v2" +name = "M365 Identity OAuth Phishing via First-Party Microsoft Application" +note = """## Triage and analysis + +### Investigating M365 Identity OAuth Phishing via First-Party Microsoft Application + +This rule identifies successful Microsoft 365 sign-ins where first-party Microsoft applications from the FOCI (Family of Client IDs) group are used in potentially suspicious OAuth flows. The rule uses split detection logic: + +**Detection Logic 1 - Developer Tools → Graph or Legacy AAD:** +- **Visual Studio Code** (`aebc6443-996d-45c2-90f0-388ff96faa56`) +- **Azure CLI** (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`) +- **Azure PowerShell** (`1950a258-227b-4e31-a9cf-717495945fc2`) + +These developer tools accessing Microsoft Graph or legacy AAD are flagged because they use localhost redirect URIs, making them ideal for OAuth code theft attacks like ConsentFix. + +**Detection Logic 2 - Any FOCI App → Legacy AAD Only:** +Any of the 38 FOCI family applications accessing legacy Windows Azure Active Directory (`00000002-0000-0000-c000-000000000000`) is suspicious because this deprecated API is rarely used legitimately. Attackers intentionally target legacy AAD to evade detection rules focused on Microsoft Graph. + +**FOCI Family Applications** (partial list - see Secureworks research for full list): +- Microsoft Office, Teams, Outlook Mobile, OneDrive, SharePoint +- Microsoft Edge, Power BI, Intune Company Portal, Microsoft Authenticator +- And 30+ other Microsoft first-party applications + +The behavior is typically seen in targeted attacks where users are lured into clicking a Microsoft login URL that redirects to a legitimate Microsoft URI (such as `insiders.vscode.dev` or `localhost`) and displays an OAuth code. If the user returns this code (e.g., via Signal, WhatsApp, or pasting into a phishing page), the attacker can use it to gain access to the user's data via Microsoft Graph APIs — all without prompting for explicit consent or MFA, especially when default or pre-consented apps are abused. + +**ConsentFix Attack Pattern**: Victims land on compromised high-reputation websites via search engines, are shown a fake Cloudflare Turnstile, and tricked into completing a legitimate Microsoft OAuth flow. The redirect URL contains a localhost URI with an authorization code that victims are socially engineered to paste back into the attacker's page. + +### Possible investigation steps + +- Review `user.name` or `o365.audit.UserId` to identify the impacted account. +- Validate whether the user expected to authorize the application (Azure CLI, VS Code, or Azure PowerShell) at the time of the event. +- Check if `o365.audit.ActorIpAddress` is an unexpected or geolocated IP — especially outside of corporate ranges or from proxy networks. +- Look at `user_agent.original` and `o365.audit.DeviceProperties` to determine the device and browser involved — known attacker flows often show Chrome + MacOS or headless browser variants. +- Confirm the `Target.ID` to identify the resource being accessed: + - Microsoft Graph: `00000003-0000-0000-c000-000000000000` + - Windows Azure Active Directory (legacy): `00000002-0000-0000-c000-000000000000` +- Check for follow-up access events or mailbox enumeration using the Graph API from unfamiliar service principals or devices. +- Review the `ExtendedProperties.RequestType` = `OAuth2:Authorize` and `ResultStatusDetail` = `Redirect` — this indicates that the user was redirected after authorization, which typically exposes the OAuth `code`. +- For Azure CLI-based attacks, look for subsequent non-interactive sign-ins from different IPs using the same session, particularly accessing legacy AAD or Intune resources. + +### False positive analysis + +- Developers or IT users intentionally using Visual Studio Code, Azure CLI, or Azure PowerShell to connect to Microsoft 365 may trigger this rule. +- Legitimate Visual Studio Code extensions that sync or query Graph API data (e.g., calendars, tasks, cloud-hosted notebooks). +- Enterprise use cases where these tools are used for integrated identity workflows or automation. +- Exclude known user agents and hosts that regularly use these applications against Graph. +- Whitelist specific source IPs or devices tied to developer machines. +- Correlate with user context and behavior — if the user has no reason to be developing or testing code, the event may be more suspicious. +- Add exception rules for managed devices or corporate laptops using this flow regularly. +- Azure CLI usage for legitimate infrastructure management tasks. + +### Response and remediation + +- Reach out to the user to confirm if they expected this login or may have shared an OAuth code. +- Suspend or reset credentials if the login appears suspicious or if the code was likely returned to a third party. +- Review recent Microsoft Graph activity (email, file access, Teams) for this user and service principal. +- Block or restrict future use of OAuth tokens from unknown apps or IPs via Conditional Access. +- Add alerts for first-party application IDs combined with low-reputation IPs or unexpected device fingerprints. +- Require MFA and Conditional Access for all OAuth flows — even for Microsoft first-party apps. +- Disable or restrict app consent for users, and require admin approval for Graph API scopes. +- Educate users about OAuth-based phishing techniques — especially those that ask users to share "codes" after clicking a Microsoft login link. +- Regularly audit `ApplicationId`, `RequestType`, and `ResultStatusDetail` values in `o365.audit` to spot anomalous usage patterns. +- Consider blocking localhost redirect URIs for OAuth flows where possible. +""" +references = [ + "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema", + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://pushsecurity.com/blog/consentfix", + "https://github.com/secureworks/family-of-client-ids-research", +] +risk_score = 47 +rule_id = "929d0766-204b-11f0-9c1f-f661ea17fbcd" +severity = "medium" +tags = [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Identity and Access Audit", + "Resources: Investigation Guide", + "Tactic: Initial Access", +] +timestamp_override = "event.ingested" +type = "query" + +query = ''' +event.dataset: "o365.audit" + and event.action: "UserLoggedIn" + and o365.audit.ExtendedProperties.RequestType: "OAuth2:Authorize" + and o365.audit.ExtendedProperties.ResultStatusDetail: "Redirect" + and o365.audit.UserType: ("0" or "2" or "3" or "5" or "6" or "10") + and ( + ( + o365.audit.ApplicationId: ( + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "1950a258-227b-4e31-a9cf-717495945fc2" + ) + and o365.audit.Target.ID: ( + "00000003-0000-0000-c000-000000000000" or + "00000002-0000-0000-c000-000000000000" + ) + ) or + ( + o365.audit.ApplicationId: ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "844cca35-0656-46ce-b636-13f48b0eecbd" or + "87749df4-7ccf-48f8-aa87-704bad0e0e16" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "22098786-6e16-43cc-a27d-191a01a1e3b5" or + "4e291c71-d680-4d0e-9640-0a3358e31177" or + "57336123-6e14-4acc-8dcf-287b6088aa28" or + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0" or + "66375f6b-983f-4c2c-9701-d680650f588f" or + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or + "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a569458c-7f2b-45cb-bab9-b7dee514d112" or + "b26aadf8-566f-4478-926f-589f601d9c74" or + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "eb539595-3fe1-474e-9c1d-feb3625d1be5" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "be1918be-3fe3-4be9-b32b-b542fc27f02e" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3" or + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) + and o365.audit.Target.ID: "00000002-0000-0000-c000-000000000000" + ) + ) +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1078" +name = "Valid Accounts" +reference = "https://attack.mitre.org/techniques/T1078/" +[[rule.threat.technique.subtechnique]] +id = "T1078.004" +name = "Cloud Accounts" +reference = "https://attack.mitre.org/techniques/T1078/004/" + + +[[rule.threat.technique]] +id = "T1566" +name = "Phishing" +reference = "https://attack.mitre.org/techniques/T1566/" +[[rule.threat.technique.subtechnique]] +id = "T1566.002" +name = "Spearphishing Link" +reference = "https://attack.mitre.org/techniques/T1566/002/" + + + +[rule.threat.tactic] +id = "TA0001" +name = "Initial Access" +reference = "https://attack.mitre.org/tactics/TA0001/" + diff --git a/rules/integrations/o365/initial_access_identity_oauth_phishing_via_vscode_client.toml b/rules/integrations/o365/initial_access_identity_oauth_phishing_via_vscode_client.toml deleted file mode 100644 index 58951ae3f64..00000000000 --- a/rules/integrations/o365/initial_access_identity_oauth_phishing_via_vscode_client.toml +++ /dev/null @@ -1,120 +0,0 @@ -[metadata] -creation_date = "2025/04/23" -integration = ["o365"] -maturity = "production" -updated_date = "2025/12/10" - -[rule] -author = ["Elastic"] -description = """ -Detects potentially suspicious OAuth authorization activity in Microsoft 365 where the Visual Studio Code first-party -application (client_id = aebc6443-996d-45c2-90f0-388ff96faa56) is used to request access to Microsoft Graph resources. -While this client ID is legitimately used by Visual Studio Code, threat actors have been observed abusing it in phishing -campaigns to make OAuth requests appear trustworthy. These attacks rely on redirect URIs such as VSCode Insiders -redirect location, prompting victims to return an OAuth authorization code that can be exchanged for access tokens. This -rule may help identify unauthorized use of the VS Code OAuth flow as part of social engineering or credential phishing -activity. -""" -from = "now-25m" -index = ["logs-o365.audit-*"] -language = "kuery" -license = "Elastic License v2" -name = "M365 Identity OAuth Flow by Visual Studio Code Client to Microsoft Graph" -note = """## Triage and analysis - -### Investigating M365 Identity OAuth Flow by Visual Studio Code Client to Microsoft Graph - -This rule identifies successful Microsoft 365 sign-ins where the Visual Studio Code first-party application (`ApplicationId = aebc6443-996d-45c2-90f0-388ff96faa56`) was used to initiate an OAuth 2.0 authorization code flow targeting Microsoft Graph. While this is common for legitimate development workflows, it has been abused in real-world phishing campaigns to trick users into returning authorization codes that attackers can exchange for access tokens. - -The behavior is typically seen in targeted attacks where users are lured into clicking a Microsoft login URL that redirects to a legitimate Microsoft URI (such as `insiders.vscode.dev`) and displays an OAuth code. If the user returns this code (e.g., via Signal, WhatsApp, or email), the attacker can use it to gain access to the user’s data via Microsoft Graph APIs — all without prompting for explicit consent or MFA, especially when default or pre-consented apps are abused. - -### Possible investigation steps - -- Review `user.name` or `o365.audit.UserId` to identify the impacted account. -- Validate whether the user expected to authorize the Visual Studio Code app at the time of the event. -- Check if `o365.audit.ActorIpAddress` is an unexpected or geolocated IP — especially outside of corporate ranges or from proxy networks. -- Look at `user_agent.original` and `o365.audit.DeviceProperties` to determine the device and browser involved — known attacker flows often show Chrome + MacOS or headless browser variants. -- Confirm the `Target.ID` (Microsoft Graph: `00000003-0000-0000-c000-000000000000`) matches the scope of access the attacker might attempt. -- Check for follow-up access events or mailbox enumeration using the Graph API from unfamiliar service principals or devices. -- Review the `ExtendedProperties.RequestType` = `OAuth2:Authorize` and `ResultStatusDetail` = `Redirect` — this indicates that the user was redirected after authorization, which typically exposes the OAuth `code`. - -### False positive analysis - -- Developers or IT users intentionally using Visual Studio Code to connect to Microsoft 365 may trigger this rule. -- Legitimate Visual Studio Code extensions that sync or query Graph API data (e.g., calendars, tasks, cloud-hosted notebooks). -- Enterprise use cases where VS Code is used for integrated identity workflows. -- Exclude known user agents and hosts that regularly use Visual Studio Code against Graph. -- Whitelist specific source IPs or devices tied to developer machines. -- Correlate with user context and behavior — if the user has no reason to be developing or testing code, the event may be more suspicious. -- Add exception rules for managed devices or corporate laptops using this flow regularly. - -### Response and remediation - -- Reach out to the user to confirm if they expected this login or may have shared an OAuth code. -- Suspend or reset credentials if the login appears suspicious or if the code was likely returned to a third party. -- Review recent Microsoft Graph activity (email, file access, Teams) for this user and service principal. -- Block or restrict future use of OAuth tokens from unknown apps or IPs via Conditional Access. -- Add alerts for `ApplicationId = aebc6443-...` combined with low-reputation IPs or unexpected device fingerprints. -- Require MFA and Conditional Access for all OAuth flows — even for Microsoft first-party apps. -- Disable or restrict app consent for users, and require admin approval for Graph API scopes. -- Educate users about OAuth-based phishing techniques — especially those that ask users to share "codes" after clicking a Microsoft login link. -- Regularly audit `ApplicationId`, `RequestType`, and `ResultStatusDetail` values in `o365.audit` to spot anomalous usage patterns. -""" -references = [ - "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema", - "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", -] -risk_score = 47 -rule_id = "929d0766-204b-11f0-9c1f-f661ea17fbcd" -severity = "medium" -tags = [ - "Domain: Cloud", - "Domain: SaaS", - "Data Source: Microsoft 365", - "Data Source: Microsoft 365 Audit Logs", - "Use Case: Identity and Access Audit", - "Resources: Investigation Guide", - "Tactic: Initial Access", -] -timestamp_override = "event.ingested" -type = "query" - -query = ''' -event.dataset: "o365.audit" - and event.action: "UserLoggedIn" - and o365.audit.ApplicationId: "aebc6443-996d-45c2-90f0-388ff96faa56" - and o365.audit.Target.ID: "00000003-0000-0000-c000-000000000000" - and o365.audit.ExtendedProperties.RequestType: "OAuth2:Authorize" - and o365.audit.ExtendedProperties.ResultStatusDetail: "Redirect" - and o365.audit.UserType: ("0" or "2" or "3" or "5" or "6" or "10") -''' - - -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" -[[rule.threat.technique.subtechnique]] -id = "T1078.004" -name = "Cloud Accounts" -reference = "https://attack.mitre.org/techniques/T1078/004/" - - -[[rule.threat.technique]] -id = "T1566" -name = "Phishing" -reference = "https://attack.mitre.org/techniques/T1566/" -[[rule.threat.technique.subtechnique]] -id = "T1566.002" -name = "Spearphishing Link" -reference = "https://attack.mitre.org/techniques/T1566/002/" - - - -[rule.threat.tactic] -id = "TA0001" -name = "Initial Access" -reference = "https://attack.mitre.org/tactics/TA0001/" - From 413a5fc9082166d0b9c97793db84e78063be2bc0 Mon Sep 17 00:00:00 2001 From: terrancedejesus Date: Wed, 17 Dec 2025 11:25:21 -0500 Subject: [PATCH 2/4] updating investigation guides to be standardized --- ..._code_grant_unusual_app_resource_user.toml | 48 +++------------ ...via_first_party_microsoft_application.toml | 59 ++++++------------ ...on_entra_id_susp_oauth2_authorization.toml | 45 +++++--------- ...via_first_party_microsoft_application.toml | 61 +++++-------------- 4 files changed, 57 insertions(+), 156 deletions(-) diff --git a/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml b/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml index ee883ca87e5..4e17ef9cf4a 100644 --- a/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml +++ b/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml @@ -24,58 +24,30 @@ note = """## Triage and analysis ### Investigating Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource -This rule identifies the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application ID, target resource ID, and user principal in Microsoft Entra ID. This is a New Terms rule that only fires when a user has not been observed using this specific app+resource combination in the last 14 days. - -**Why This Matters for ConsentFix Detection:** - -ConsentFix and similar OAuth phishing attacks exploit first-party Microsoft applications (Azure CLI, VS Code, Azure PowerShell) because: -- They are trusted by default in all tenants -- They can request permissions without admin approval -- They cannot be deleted or blocked - -When an attacker steals an OAuth authorization code and exchanges it for tokens, the resulting sign-in event shows: -- The victim's UPN -- The first-party app ID (e.g., Azure CLI) -- A target resource (often legacy AAD for stealth) - -If a user has never used Azure CLI to access Windows Azure Active Directory before, this is highly suspicious. - -**Detection Logic 1 - Developer Tools → Graph or Legacy AAD (First-Time)**: -- **Azure CLI**: `04b07795-8ddb-461a-bbee-02f9e1bf7b46` -- **Visual Studio Code**: `aebc6443-996d-45c2-90f0-388ff96faa56` -- **Azure PowerShell**: `1950a258-227b-4e31-a9cf-717495945fc2` - -**Detection Logic 2 - Any FOCI App → Legacy AAD Only (First-Time)**: -Any of the 38 FOCI family applications (Microsoft Office, Teams, Outlook, OneDrive, etc.) accessing legacy Windows Azure Active Directory for the first time by a user is suspicious because this deprecated API is rarely used legitimately. - -### Sensitive Target Resources: -- **Windows Azure Active Directory (Legacy)**: `00000002-0000-0000-c000-000000000000` - Deprecated, rarely legitimate -- **Microsoft Graph**: `00000003-0000-0000-c000-000000000000` - Common but verify context +This New Terms rule detects the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application, target resource, and user principal. When a user has never used a particular app+resource combination in the last 14 days and it involves FOCI applications or legacy Azure AD, this may indicate OAuth phishing. ### Possible investigation steps -- Review `azure.signinlogs.properties.user_principal_name` to identify the affected user. -- Confirm the `azure.signinlogs.properties.app_id` matches a first-party Microsoft application. If it's Azure CLI or Azure PowerShell and the user doesn't typically use these tools, this is suspicious. -- Check `azure.signinlogs.properties.resource_id` to identify what resource was accessed. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access by developer tools is unusual. -- Analyze `source.ip` and `source.geo.*` for geographic anomalies. ConsentFix attackers exchange codes from different IPs than the victim. -- Review `azure.signinlogs.properties.is_interactive` - if this is a non-interactive sign-in shortly after an interactive one from a different IP, it may indicate token replay. -- Check `azure.signinlogs.properties.session_id` and correlate with other sign-in events to identify the full OAuth flow sequence. -- Look for subsequent Graph API or AAD API activity from the same session or user from unusual locations. +- Identify the affected user and confirm if they typically use developer tools like Azure CLI or PowerShell. +- Determine if the application and resource combination is expected for this user's role. +- Analyze source IP and geolocation for anomalies. Attackers typically exchange codes from different IPs. +- Check for non-interactive sign-ins shortly after interactive ones from different IPs, indicating token replay. +- Correlate with other sign-in events using session ID to identify the full OAuth flow sequence. +- Look for subsequent Graph API or AAD API activity from unusual locations. ### False positive analysis -- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code for the first time to access specific resources. +- Developers or IT administrators legitimately using these tools for the first time. - Users onboarding to new development environments or tools. - Automation scripts that run with user-delegated permissions for the first time. ### Response and remediation -- Contact the user to confirm if they initiated the OAuth flow and used the detected application. +- Contact the user to confirm if they initiated the OAuth flow. - If unauthorized, immediately revoke all refresh tokens for the user via Entra ID. -- Review recent activity from the same session ID for signs of data access or enumeration. +- Review recent activity from the same session for signs of data access or enumeration. - Block the source IP if confirmed malicious. - Implement Conditional Access policies to restrict OAuth flows for these applications. -- Educate users about OAuth phishing and the risks of pasting authorization codes. """ references = [ "https://pushsecurity.com/blog/consentfix", diff --git a/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml b/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml index ff6dbdadeb2..dabd962bcac 100644 --- a/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml +++ b/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml @@ -25,60 +25,35 @@ note = """## Triage and analysis ### Investigating Entra ID OAuth Phishing via First-Party Microsoft Application -This rule identifies successful Entra ID sign-ins where first-party Microsoft applications from the FOCI (Family of Client IDs) group are used in potentially suspicious OAuth flows. The rule uses split detection logic: - -**Detection Logic 1 - Developer Tools → Graph or Legacy AAD:** -- **Visual Studio Code** (`aebc6443-996d-45c2-90f0-388ff96faa56`) -- **Azure CLI** (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`) -- **Azure PowerShell** (`1950a258-227b-4e31-a9cf-717495945fc2`) - -These developer tools accessing Microsoft Graph or legacy AAD are flagged because they use localhost redirect URIs, making them ideal for OAuth code theft attacks like ConsentFix. - -**Detection Logic 2 - Any FOCI App → Legacy AAD Only:** -Any of the 38 FOCI family applications accessing legacy Windows Azure Active Directory (`00000002-0000-0000-c000-000000000000`) is suspicious because this deprecated API is rarely used legitimately. Attackers intentionally target legacy AAD to evade detection rules focused on Microsoft Graph. - -**FOCI Family Applications** (partial list - see Secureworks research for full list): -- Microsoft Office, Teams, Outlook Mobile, OneDrive, SharePoint -- Microsoft Edge, Power BI, Intune Company Portal, Microsoft Authenticator -- And 30+ other Microsoft first-party applications - -**ConsentFix Attack Pattern**: Victims land on compromised high-reputation websites via search engines, are shown a fake Cloudflare Turnstile, and tricked into completing a legitimate Microsoft OAuth flow. The redirect URL contains a localhost URI with an authorization code that victims are socially engineered to paste back into the attacker's page. The attacker then uses Azure CLI to exchange the code for tokens and access legacy AAD/Intune resources. +This rule detects OAuth authorization activity where FOCI (Family of Client IDs) applications access Microsoft Graph or legacy Azure AD resources. Adversaries exploit these trusted first-party apps in phishing campaigns like ConsentFix to steal authorization codes and exchange them for tokens from attacker infrastructure. ### Possible investigation steps -- Review `azure.signinlogs.properties.user_principal_name` to identify the affected user and determine if they are a high-value target (privileged roles, executives, IT admins). -- Analyze `source.ip` and `source.geo.*` for geographic anomalies. ConsentFix attackers exchange codes from different IPs than the victim's location. -- Check `azure.signinlogs.properties.app_id` and `azure.signinlogs.properties.app_display_name` to confirm which first-party application was used. Azure CLI access by non-developers is suspicious. -- Examine `azure.signinlogs.properties.resource_id` to identify the target resource: - - `00000002-0000-0000-c000-000000000000` = Windows Azure Active Directory (legacy) - unusual for most users - - `00000003-0000-0000-c000-000000000000` = Microsoft Graph - common but verify context -- Review `azure.signinlogs.properties.is_interactive` - non-interactive sign-ins shortly after interactive ones from different IPs indicate token replay. -- Check `azure.signinlogs.properties.session_id` to correlate with other sign-in events and identify the full OAuth flow sequence. -- Look at `user_agent.original` for suspicious patterns (automation tools, headless browsers, unusual browser/OS combinations). -- Search for subsequent Graph API or AAD API activity from the same session or user from unusual locations. -- Check `azure.signinlogs.properties.device_detail` to determine if the sign-in came from a managed/compliant device. +- Identify the affected user and determine if they are a high-value target (privileged roles, executives, IT admins). +- Analyze source IP and geolocation for anomalies. Attackers typically exchange codes from different IPs than the victim. +- Confirm which first-party application was used. Azure CLI or PowerShell access by non-developers is suspicious. +- Identify the target resource. Legacy AAD access is unusual for most users and indicates potential evasion. +- Check for non-interactive sign-ins shortly after interactive ones from different IPs, which may indicate token replay. +- Correlate with other sign-in events using session ID to identify the full OAuth flow sequence. +- Look for suspicious user agent patterns (automation tools, headless browsers). +- Search for subsequent Graph API or AAD API activity from unusual locations. ### False positive analysis -- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code to access Microsoft Graph or Azure AD. -- Legitimate Visual Studio Code extensions that sync or query Graph API data (calendars, tasks, cloud-hosted notebooks). +- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code. - Enterprise automation or CI/CD pipelines using these tools with user-delegated permissions. - Users working from multiple locations (VPN, travel) may show different IPs. -- Corporate proxies or VPNs may show unexpected IP addresses. -- Consider excluding known developer machines, managed devices, or specific user groups that regularly use these tools. -- Add exceptions for specific source IPs tied to corporate infrastructure or known developer environments. +- Consider excluding known developer machines or specific user groups that regularly use these tools. ### Response and remediation -- Contact the user immediately to confirm if they initiated the OAuth flow and used the detected application. -- If unauthorized, revoke all refresh tokens for the user via Microsoft Entra ID portal or PowerShell. -- Review the user's recent Microsoft Graph activity (email access, file downloads, Teams messages) for signs of data exfiltration. +- Contact the user to confirm if they initiated the OAuth flow. +- If unauthorized, revoke all refresh tokens for the user via Microsoft Entra ID. +- Review recent Microsoft Graph activity for signs of data exfiltration. - Block the source IP if confirmed malicious. -- Check for any devices registered during this session and remove unauthorized device registrations. -- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices only. -- Educate users about OAuth phishing and the risks of pasting authorization codes into websites. -- Consider blocking localhost redirect URIs for OAuth flows where possible. -- Monitor for follow-on activity such as privilege escalation, lateral movement, or data access. +- Check for and remove any unauthorized device registrations. +- Implement Conditional Access policies to restrict OAuth flows to compliant devices. +- Educate users about OAuth phishing and the risks of pasting authorization codes. """ references = [ "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema", diff --git a/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml b/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml index 4054b5cecae..7012a0eade9 100644 --- a/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml +++ b/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml @@ -23,41 +23,28 @@ note = """## Triage and analysis ### Investigating M365 Identity OAuth Flow by First-Party Microsoft App from Multiple IPs -This rule detects when the same user authenticates to Microsoft Graph using first-party Microsoft applications from multiple IP addresses within a short time window. This pattern is indicative of OAuth code/token theft attacks like ConsentFix, where: +This rule detects when the same user authenticates to Microsoft Graph or legacy Azure AD using FOCI applications from multiple IP addresses within a short time window. This pattern indicates OAuth code/token theft where the victim completes OAuth flow on their device and the attacker exchanges the stolen code from different infrastructure. -1. Victim completes OAuth flow on their device (first IP) -2. Attacker exchanges stolen authorization code for tokens from their infrastructure (second IP) -3. Both events share the same user principal but originate from different locations +### Possible investigation steps -**Detection Logic 1 - Developer Tools → Graph or Legacy AAD (Multi-IP)**: -- Visual Studio Code (`aebc6443-996d-45c2-90f0-388ff96faa56`) -- Microsoft Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) -- Azure CLI (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`) -- Azure PowerShell (`1950a258-227b-4e31-a9cf-717495945fc2`) +- Identify the affected user and analyze the list of unique IP addresses used within the 30-minute window. +- Determine whether IPs originate from different geographic regions, cloud providers, or anonymizing infrastructure. +- Pivot into raw events to reconstruct the full sequence of resource access events. +- Check Azure audit logs for device join or registration events around the same timeframe. +- Review identity protection alerts for correlated risk detections such as anonymized IP access or token replay. -**Detection Logic 2 - Any FOCI App → Legacy AAD Only (Multi-IP)**: -Any of the 38 FOCI family applications (Microsoft Office, Teams, Outlook, OneDrive, etc.) accessing legacy Windows Azure Active Directory from multiple IPs is suspicious because this deprecated API is rarely used legitimately. +### False positive analysis -### Possible Investigation Steps: +- Developers or IT administrators working across environments may produce similar behavior. +- Users on VPN or traveling between networks may show multiple IPs. -- `o365.audit.UserId`: The identity value the application is acting on behalf of principal user. -- `unique_ips`: Analyze the list of unique IP addresses used within the 30-minute window. Determine whether these originate from different geographic regions, cloud providers, or anonymizing infrastructure (e.g., Tor or VPNs). -- `target_time_window`: Use the truncated time window to pivot into raw events to reconstruct the full sequence of resource access events, including exact timestamps and service targets. -- `azure.auditlogs` to check for device join or registration events around the same timeframe. -- `azure.identityprotection` to identify correlated risk detections, such as anonymized IP access or token replay. -- Any additional sign-ins from the `ips` involved, even outside the broker, to determine if tokens have been reused elsewhere. +### Response and remediation -### False Positive Analysis - -- Developers or IT administrators working across environments may also produce similar behavior. - -### Response and Remediation - -- If confirmed unauthorized, revoke all refresh tokens for the affected user and remove any devices registered during this session. -- Notify the user and determine whether the device join or authentication activity was expected. -- Audit Conditional Access and broker permissions (`29d9ed98-a469-4536-ade2-f981bc1d605e`) to ensure policies enforce strict access controls. -- Consider blocking token-based reauthentication to Microsoft Graph and DRS from suspicious locations or user agents. -- Continue monitoring for follow-on activity like lateral movement or privilege escalation. +- If confirmed unauthorized, revoke all refresh tokens for the affected user. +- Remove any devices registered during this session. +- Notify the user and determine whether the authentication activity was expected. +- Implement Conditional Access policies to restrict OAuth flows from suspicious locations. +- Monitor for follow-on activity like lateral movement or privilege escalation. """ references = [ "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", diff --git a/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml b/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml index 712a4261abb..4bd31e6b038 100644 --- a/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml +++ b/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml @@ -25,63 +25,30 @@ note = """## Triage and analysis ### Investigating M365 Identity OAuth Phishing via First-Party Microsoft Application -This rule identifies successful Microsoft 365 sign-ins where first-party Microsoft applications from the FOCI (Family of Client IDs) group are used in potentially suspicious OAuth flows. The rule uses split detection logic: - -**Detection Logic 1 - Developer Tools → Graph or Legacy AAD:** -- **Visual Studio Code** (`aebc6443-996d-45c2-90f0-388ff96faa56`) -- **Azure CLI** (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`) -- **Azure PowerShell** (`1950a258-227b-4e31-a9cf-717495945fc2`) - -These developer tools accessing Microsoft Graph or legacy AAD are flagged because they use localhost redirect URIs, making them ideal for OAuth code theft attacks like ConsentFix. - -**Detection Logic 2 - Any FOCI App → Legacy AAD Only:** -Any of the 38 FOCI family applications accessing legacy Windows Azure Active Directory (`00000002-0000-0000-c000-000000000000`) is suspicious because this deprecated API is rarely used legitimately. Attackers intentionally target legacy AAD to evade detection rules focused on Microsoft Graph. - -**FOCI Family Applications** (partial list - see Secureworks research for full list): -- Microsoft Office, Teams, Outlook Mobile, OneDrive, SharePoint -- Microsoft Edge, Power BI, Intune Company Portal, Microsoft Authenticator -- And 30+ other Microsoft first-party applications - -The behavior is typically seen in targeted attacks where users are lured into clicking a Microsoft login URL that redirects to a legitimate Microsoft URI (such as `insiders.vscode.dev` or `localhost`) and displays an OAuth code. If the user returns this code (e.g., via Signal, WhatsApp, or pasting into a phishing page), the attacker can use it to gain access to the user's data via Microsoft Graph APIs — all without prompting for explicit consent or MFA, especially when default or pre-consented apps are abused. - -**ConsentFix Attack Pattern**: Victims land on compromised high-reputation websites via search engines, are shown a fake Cloudflare Turnstile, and tricked into completing a legitimate Microsoft OAuth flow. The redirect URL contains a localhost URI with an authorization code that victims are socially engineered to paste back into the attacker's page. +This rule detects OAuth authorization activity where FOCI (Family of Client IDs) applications access Microsoft Graph or legacy Azure AD resources. Adversaries exploit these trusted first-party apps in phishing campaigns like ConsentFix to steal authorization codes and exchange them for tokens from attacker infrastructure. ### Possible investigation steps -- Review `user.name` or `o365.audit.UserId` to identify the impacted account. -- Validate whether the user expected to authorize the application (Azure CLI, VS Code, or Azure PowerShell) at the time of the event. -- Check if `o365.audit.ActorIpAddress` is an unexpected or geolocated IP — especially outside of corporate ranges or from proxy networks. -- Look at `user_agent.original` and `o365.audit.DeviceProperties` to determine the device and browser involved — known attacker flows often show Chrome + MacOS or headless browser variants. -- Confirm the `Target.ID` to identify the resource being accessed: - - Microsoft Graph: `00000003-0000-0000-c000-000000000000` - - Windows Azure Active Directory (legacy): `00000002-0000-0000-c000-000000000000` -- Check for follow-up access events or mailbox enumeration using the Graph API from unfamiliar service principals or devices. -- Review the `ExtendedProperties.RequestType` = `OAuth2:Authorize` and `ResultStatusDetail` = `Redirect` — this indicates that the user was redirected after authorization, which typically exposes the OAuth `code`. -- For Azure CLI-based attacks, look for subsequent non-interactive sign-ins from different IPs using the same session, particularly accessing legacy AAD or Intune resources. +- Identify the impacted account and validate whether the user expected to authorize the application. +- Check if the source IP is unexpected or outside corporate ranges, especially from proxy networks. +- Examine user agent and device properties for suspicious patterns (automation tools, headless browsers). +- Identify the target resource. Legacy AAD access is unusual for most users and indicates potential evasion. +- Check for follow-up access events or mailbox enumeration using the Graph API from unfamiliar locations. +- Look for subsequent non-interactive sign-ins from different IPs using the same session. ### False positive analysis -- Developers or IT users intentionally using Visual Studio Code, Azure CLI, or Azure PowerShell to connect to Microsoft 365 may trigger this rule. -- Legitimate Visual Studio Code extensions that sync or query Graph API data (e.g., calendars, tasks, cloud-hosted notebooks). -- Enterprise use cases where these tools are used for integrated identity workflows or automation. -- Exclude known user agents and hosts that regularly use these applications against Graph. -- Whitelist specific source IPs or devices tied to developer machines. -- Correlate with user context and behavior — if the user has no reason to be developing or testing code, the event may be more suspicious. -- Add exception rules for managed devices or corporate laptops using this flow regularly. -- Azure CLI usage for legitimate infrastructure management tasks. +- Developers or IT users intentionally using Azure CLI, VS Code, or PowerShell. +- Enterprise automation or CI/CD pipelines using these tools with user-delegated permissions. +- Consider excluding known developer machines or specific user groups that regularly use these tools. ### Response and remediation -- Reach out to the user to confirm if they expected this login or may have shared an OAuth code. -- Suspend or reset credentials if the login appears suspicious or if the code was likely returned to a third party. -- Review recent Microsoft Graph activity (email, file access, Teams) for this user and service principal. +- Contact the user to confirm if they expected this login or may have shared an OAuth code. +- If unauthorized, revoke all refresh tokens and reset credentials. +- Review recent Microsoft Graph activity for signs of data exfiltration. - Block or restrict future use of OAuth tokens from unknown apps or IPs via Conditional Access. -- Add alerts for first-party application IDs combined with low-reputation IPs or unexpected device fingerprints. -- Require MFA and Conditional Access for all OAuth flows — even for Microsoft first-party apps. -- Disable or restrict app consent for users, and require admin approval for Graph API scopes. -- Educate users about OAuth-based phishing techniques — especially those that ask users to share "codes" after clicking a Microsoft login link. -- Regularly audit `ApplicationId`, `RequestType`, and `ResultStatusDetail` values in `o365.audit` to spot anomalous usage patterns. -- Consider blocking localhost redirect URIs for OAuth flows where possible. +- Educate users about OAuth phishing techniques and the risks of sharing authorization codes. """ references = [ "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema", From 5ec1d553ecdee504de7d1656325368593539d4fc Mon Sep 17 00:00:00 2001 From: terrancedejesus Date: Wed, 17 Dec 2025 11:31:05 -0500 Subject: [PATCH 3/4] making investigation guides more contextual --- ..._code_grant_unusual_app_resource_user.toml | 32 +++++++++------- ...via_first_party_microsoft_application.toml | 37 ++++++++++--------- ...on_entra_id_susp_oauth2_authorization.toml | 34 ++++++++++------- ...via_first_party_microsoft_application.toml | 31 ++++++++++------ 4 files changed, 79 insertions(+), 55 deletions(-) diff --git a/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml b/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml index 4e17ef9cf4a..7e5ed6ca510 100644 --- a/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml +++ b/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml @@ -24,30 +24,36 @@ note = """## Triage and analysis ### Investigating Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource -This New Terms rule detects the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application, target resource, and user principal. When a user has never used a particular app+resource combination in the last 14 days and it involves FOCI applications or legacy Azure AD, this may indicate OAuth phishing. +This New Terms rule detects the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application ID, target resource ID, and user principal within the last 14 days. When a user has never used a particular app+resource combination and it involves FOCI applications or legacy Azure AD, this may indicate OAuth phishing attacks like ConsentFix. + +The rule is particularly effective at catching attacks where adversaries use stolen OAuth codes with first-party apps to access resources the victim has never accessed before. For example, if a non-developer suddenly uses Azure CLI to access legacy AAD for the first time, this is highly suspicious regardless of other factors. ### Possible investigation steps -- Identify the affected user and confirm if they typically use developer tools like Azure CLI or PowerShell. -- Determine if the application and resource combination is expected for this user's role. -- Analyze source IP and geolocation for anomalies. Attackers typically exchange codes from different IPs. -- Check for non-interactive sign-ins shortly after interactive ones from different IPs, indicating token replay. -- Correlate with other sign-in events using session ID to identify the full OAuth flow sequence. -- Look for subsequent Graph API or AAD API activity from unusual locations. +- Review `azure.signinlogs.properties.user_principal_name` to identify the affected user and determine if they are a developer who would legitimately use these tools. +- Check `azure.signinlogs.properties.app_display_name` to confirm which application was used. Azure CLI or PowerShell access by non-technical users is suspicious. +- Examine `azure.signinlogs.properties.resource_id` to identify the target resource. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access is unusual for most users. +- Analyze `source.ip` and `source.geo.*` for geographic anomalies. ConsentFix attackers exchange codes from different IPs than the victim. +- Review `azure.signinlogs.properties.is_interactive` - if this is a non-interactive sign-in shortly after an interactive one from a different IP, it indicates token replay. +- Correlate with other sign-in events using `azure.signinlogs.properties.session_id` to identify the full OAuth flow sequence. +- Pivot to `azure.graphactivitylogs` to search for subsequent Graph API or AAD API activity from unusual locations. +- Check `azure.auditlogs` for device registration events around the same timeframe. ### False positive analysis -- Developers or IT administrators legitimately using these tools for the first time. -- Users onboarding to new development environments or tools. +- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code for the first time to access specific resources. +- Users onboarding to new development environments or receiving new tooling. - Automation scripts that run with user-delegated permissions for the first time. +- Consider the user's role and typical activity patterns when evaluating alerts. ### Response and remediation -- Contact the user to confirm if they initiated the OAuth flow. -- If unauthorized, immediately revoke all refresh tokens for the user via Entra ID. -- Review recent activity from the same session for signs of data access or enumeration. +- Contact the user to confirm if they initiated the OAuth flow and used the detected application. +- If unauthorized, immediately revoke all refresh tokens for the user via Microsoft Entra ID. +- Review recent activity from the same `session_id` for signs of data access or enumeration. - Block the source IP if confirmed malicious. -- Implement Conditional Access policies to restrict OAuth flows for these applications. +- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices. +- Educate users about OAuth phishing and the risks of pasting authorization codes. """ references = [ "https://pushsecurity.com/blog/consentfix", diff --git a/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml b/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml index dabd962bcac..98d7872ee8d 100644 --- a/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml +++ b/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml @@ -25,35 +25,38 @@ note = """## Triage and analysis ### Investigating Entra ID OAuth Phishing via First-Party Microsoft Application -This rule detects OAuth authorization activity where FOCI (Family of Client IDs) applications access Microsoft Graph or legacy Azure AD resources. Adversaries exploit these trusted first-party apps in phishing campaigns like ConsentFix to steal authorization codes and exchange them for tokens from attacker infrastructure. +This rule detects OAuth authorization activity where FOCI (Family of Client IDs) applications access Microsoft Graph or legacy Azure AD resources. Adversaries exploit these trusted first-party apps in phishing campaigns like ConsentFix to steal authorization codes and exchange them for tokens from attacker infrastructure. Because first-party apps are pre-consented and cannot be blocked, attackers use them to bypass consent prompts and access user data without triggering typical OAuth alerts. + +The rule uses split detection logic: developer tools (Azure CLI, VSCode, PowerShell) accessing either Graph or legacy AAD are flagged, while any FOCI app accessing legacy AAD is flagged since this deprecated API is rarely used legitimately and attackers target it for stealth. ### Possible investigation steps -- Identify the affected user and determine if they are a high-value target (privileged roles, executives, IT admins). -- Analyze source IP and geolocation for anomalies. Attackers typically exchange codes from different IPs than the victim. -- Confirm which first-party application was used. Azure CLI or PowerShell access by non-developers is suspicious. -- Identify the target resource. Legacy AAD access is unusual for most users and indicates potential evasion. -- Check for non-interactive sign-ins shortly after interactive ones from different IPs, which may indicate token replay. -- Correlate with other sign-in events using session ID to identify the full OAuth flow sequence. -- Look for suspicious user agent patterns (automation tools, headless browsers). -- Search for subsequent Graph API or AAD API activity from unusual locations. +- Review `azure.signinlogs.properties.user_principal_name` to identify the affected user and determine if they are a high-value target (privileged roles, executives, IT admins). +- Analyze `source.ip` and `source.geo.*` for geographic anomalies. ConsentFix attackers exchange codes from different IPs than the victim's location. +- Check `azure.signinlogs.properties.app_display_name` to confirm which first-party application was used. Azure CLI or PowerShell access by non-developers is suspicious. +- Examine `azure.signinlogs.properties.resource_id` to identify the target resource. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access is unusual for most users. +- Review `azure.signinlogs.properties.is_interactive` - non-interactive sign-ins shortly after interactive ones from different IPs indicate token replay. +- Correlate with other sign-in events using `azure.signinlogs.properties.session_id` to identify the full OAuth flow sequence. +- Pivot to `azure.graphactivitylogs` to search for subsequent Graph API activity from the same session or user from unusual locations. +- Check `azure.auditlogs` for device registration events around the same timeframe, which may indicate persistence attempts. ### False positive analysis -- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code. +- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code to access Microsoft Graph or Azure AD. - Enterprise automation or CI/CD pipelines using these tools with user-delegated permissions. - Users working from multiple locations (VPN, travel) may show different IPs. -- Consider excluding known developer machines or specific user groups that regularly use these tools. +- Consider excluding known developer machines, managed devices, or specific user groups that regularly use these tools. +- Maintain an allowlist of expected source IPs tied to corporate infrastructure or developer environments. ### Response and remediation -- Contact the user to confirm if they initiated the OAuth flow. -- If unauthorized, revoke all refresh tokens for the user via Microsoft Entra ID. -- Review recent Microsoft Graph activity for signs of data exfiltration. +- Contact the user immediately to confirm if they initiated the OAuth flow and used the detected application. +- If unauthorized, revoke all refresh tokens for the user via Microsoft Entra ID portal or PowerShell. +- Review the user's recent Microsoft Graph activity (email access, file downloads, Teams messages) for signs of data exfiltration. - Block the source IP if confirmed malicious. -- Check for and remove any unauthorized device registrations. -- Implement Conditional Access policies to restrict OAuth flows to compliant devices. -- Educate users about OAuth phishing and the risks of pasting authorization codes. +- Check for any devices registered during this session via `azure.auditlogs` and remove unauthorized device registrations. +- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices only. +- Educate users about OAuth phishing and the risks of pasting authorization codes into websites. """ references = [ "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema", diff --git a/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml b/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml index 7012a0eade9..03a264b4880 100644 --- a/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml +++ b/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml @@ -23,28 +23,36 @@ note = """## Triage and analysis ### Investigating M365 Identity OAuth Flow by First-Party Microsoft App from Multiple IPs -This rule detects when the same user authenticates to Microsoft Graph or legacy Azure AD using FOCI applications from multiple IP addresses within a short time window. This pattern indicates OAuth code/token theft where the victim completes OAuth flow on their device and the attacker exchanges the stolen code from different infrastructure. +This rule detects when the same user authenticates to Microsoft Graph or legacy Azure AD using FOCI applications from multiple IP addresses within a 30-minute window. This pattern is a strong indicator of OAuth code/token theft attacks like ConsentFix, where the victim completes the OAuth authorize flow on their device (first IP), and the attacker exchanges the stolen authorization code for tokens from their infrastructure (second IP). + +The rule aggregates events by user, application, and resource, requiring both `OAuth2:Authorize` and `OAuth2:Token` requests from at least 2 different IPs to fire - this indicates the code was generated on one IP and exchanged on another. ### Possible investigation steps -- Identify the affected user and analyze the list of unique IP addresses used within the 30-minute window. -- Determine whether IPs originate from different geographic regions, cloud providers, or anonymizing infrastructure. -- Pivot into raw events to reconstruct the full sequence of resource access events. -- Check Azure audit logs for device join or registration events around the same timeframe. -- Review identity protection alerts for correlated risk detections such as anonymized IP access or token replay. +- Review `o365.audit.UserId` to identify the affected user and determine if they are a high-value target. +- Analyze `Esql.source_ip_values` to see all unique IP addresses used within the 30-minute window. Determine whether these originate from different geographic regions, cloud providers (AWS, Azure, GCP), or anonymizing infrastructure (Tor, VPNs). +- Use `Esql.time_window_date_trunc` to pivot into raw events and reconstruct the full sequence of resource access events with exact timestamps. +- Check `Esql.source_as_organization_name_values` for unfamiliar ASN organizations that may indicate attacker infrastructure. +- Review `Esql.o365_audit_ApplicationId_values` to confirm which first-party application was used. +- Pivot to `azure.auditlogs` to check for device join or registration events around the same timeframe, which may indicate persistence attempts. +- Correlate with `azure.identityprotection` to identify related risk detections such as anonymized IP access or token replay. +- Search for additional sign-ins from the IPs involved across other users to determine if this is part of a broader campaign. ### False positive analysis -- Developers or IT administrators working across environments may produce similar behavior. -- Users on VPN or traveling between networks may show multiple IPs. +- Developers or IT administrators working across environments (office, home, cloud VMs) may produce similar behavior. +- Users on VPN who switch servers or traveling between networks may show multiple IPs. +- Mobile users moving between cellular and WiFi networks during the time window. +- Consider correlating with device compliance status to distinguish managed vs. unmanaged access. ### Response and remediation -- If confirmed unauthorized, revoke all refresh tokens for the affected user. -- Remove any devices registered during this session. -- Notify the user and determine whether the authentication activity was expected. -- Implement Conditional Access policies to restrict OAuth flows from suspicious locations. -- Monitor for follow-on activity like lateral movement or privilege escalation. +- If confirmed unauthorized, immediately revoke all refresh tokens for the affected user via Entra ID. +- Remove any devices registered during this session by checking `azure.auditlogs` for `Add device` events. +- Notify the user and determine whether they may have shared an OAuth code via phishing. +- Block the attacker IPs at the perimeter and add to threat intel feeds. +- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices and approved locations. +- Monitor for follow-on activity like lateral movement, privilege escalation, or data exfiltration via Graph API. """ references = [ "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", diff --git a/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml b/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml index 4bd31e6b038..aa7871daf5f 100644 --- a/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml +++ b/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml @@ -25,29 +25,36 @@ note = """## Triage and analysis ### Investigating M365 Identity OAuth Phishing via First-Party Microsoft Application -This rule detects OAuth authorization activity where FOCI (Family of Client IDs) applications access Microsoft Graph or legacy Azure AD resources. Adversaries exploit these trusted first-party apps in phishing campaigns like ConsentFix to steal authorization codes and exchange them for tokens from attacker infrastructure. +This rule detects OAuth authorization activity where FOCI (Family of Client IDs) applications access Microsoft Graph or legacy Azure AD resources. Adversaries exploit these trusted first-party apps in phishing campaigns like ConsentFix to steal authorization codes and exchange them for tokens from attacker infrastructure. The rule specifically looks for `OAuth2:Authorize` requests with `Redirect` status, which indicates the user was redirected after authorization and the OAuth code was exposed. + +The rule uses split detection logic: developer tools (Azure CLI, VSCode, PowerShell) accessing either Graph or legacy AAD are flagged, while any FOCI app accessing legacy AAD is flagged since this deprecated API is rarely used legitimately and attackers target it for stealth. ### Possible investigation steps -- Identify the impacted account and validate whether the user expected to authorize the application. -- Check if the source IP is unexpected or outside corporate ranges, especially from proxy networks. -- Examine user agent and device properties for suspicious patterns (automation tools, headless browsers). -- Identify the target resource. Legacy AAD access is unusual for most users and indicates potential evasion. -- Check for follow-up access events or mailbox enumeration using the Graph API from unfamiliar locations. -- Look for subsequent non-interactive sign-ins from different IPs using the same session. +- Review `o365.audit.UserId` to identify the impacted account and validate whether the user expected to authorize the application. +- Check `o365.audit.ActorIpAddress` for unexpected IPs, especially outside corporate ranges or from proxy/VPN networks. +- Examine `user_agent.original` and `o365.audit.DeviceProperties` for suspicious patterns (automation tools, headless browsers, unusual browser/OS combinations). +- Confirm `o365.audit.Target.ID` to identify the resource being accessed. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access is unusual for most users. +- Review `o365.audit.ExtendedProperties.RequestType` and `ResultStatusDetail` - `OAuth2:Authorize` with `Redirect` indicates the OAuth code was exposed to the user. +- Look for subsequent `OAuth2:Token` events from different IPs using the same `o365.audit.UserId`, which indicates token exchange from attacker infrastructure. +- Pivot to `azure.graphactivitylogs` to check for follow-up Graph API activity (mailbox enumeration, file access) from unfamiliar locations. +- Correlate with `azure.signinlogs` for additional sign-in context and device details. ### False positive analysis -- Developers or IT users intentionally using Azure CLI, VS Code, or PowerShell. +- Developers or IT users intentionally using Visual Studio Code, Azure CLI, or Azure PowerShell to connect to Microsoft 365. +- Legitimate VS Code extensions that sync or query Graph API data (calendars, tasks, cloud-hosted notebooks). - Enterprise automation or CI/CD pipelines using these tools with user-delegated permissions. -- Consider excluding known developer machines or specific user groups that regularly use these tools. +- Exclude known user agents and hosts that regularly use these applications against Graph. +- Whitelist specific source IPs or devices tied to developer machines. ### Response and remediation -- Contact the user to confirm if they expected this login or may have shared an OAuth code. -- If unauthorized, revoke all refresh tokens and reset credentials. -- Review recent Microsoft Graph activity for signs of data exfiltration. +- Contact the user to confirm if they expected this login or may have shared an OAuth code via phishing page, Signal, or WhatsApp. +- If unauthorized, revoke all refresh tokens for the user and reset credentials. +- Review recent Microsoft Graph activity (email, file access, Teams) for signs of data exfiltration. - Block or restrict future use of OAuth tokens from unknown apps or IPs via Conditional Access. +- Check `azure.auditlogs` for device registration events and remove any unauthorized registrations. - Educate users about OAuth phishing techniques and the risks of sharing authorization codes. """ references = [ From 8c5204a9b024309b6299787a6044244eb1d84d60 Mon Sep 17 00:00:00 2001 From: terrancedejesus Date: Wed, 17 Dec 2025 11:40:14 -0500 Subject: [PATCH 4/4] updating descriptions --- ...h_auth_code_grant_unusual_app_resource_user.toml | 12 ++++++------ ...shing_via_first_party_microsoft_application.toml | 13 ++++++------- ..._evasion_entra_id_susp_oauth2_authorization.toml | 10 +++++----- ...shing_via_first_party_microsoft_application.toml | 13 ++++++------- 4 files changed, 23 insertions(+), 25 deletions(-) diff --git a/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml b/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml index 7e5ed6ca510..a4256fdae8c 100644 --- a/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml +++ b/rules/integrations/azure/initial_access_entra_id_oauth_auth_code_grant_unusual_app_resource_user.toml @@ -8,12 +8,12 @@ updated_date = "2025/12/17" author = ["Elastic"] description = """ Identifies the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client -application, target resource, and user principal in Microsoft Entra ID. This rule uses split detection logic: (1) -Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing either Microsoft Graph or legacy AAD -are flagged for first-time usage by a user. (2) Any FOCI (Family of Client IDs) application accessing legacy Windows -Azure Active Directory for the first time by a user is flagged, as this deprecated resource is rarely accessed -legitimately. This pattern is indicative of OAuth phishing attacks like ConsentFix, where attackers steal authorization -codes and exchange them for tokens from attacker-controlled infrastructure. +application, target resource, and user principal in Microsoft Entra ID. Developer tools like Azure CLI, Visual Studio +Code, and Azure PowerShell accessing Microsoft Graph or legacy Azure AD are flagged for first time usage by a user. +Additionally, any FOCI (Family of Client IDs) application accessing the deprecated Windows Azure Active Directory for +the first time is flagged since this resource is rarely accessed legitimately. This pattern is indicative of OAuth +phishing attacks like ConsentFix, where attackers steal authorization codes and exchange them for tokens from attacker +controlled infrastructure. """ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*"] diff --git a/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml b/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml index 98d7872ee8d..2e45d3b1bb6 100644 --- a/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml +++ b/rules/integrations/azure/initial_access_entra_id_oauth_phishing_via_first_party_microsoft_application.toml @@ -8,13 +8,12 @@ updated_date = "2025/12/17" author = ["Elastic"] description = """ Detects potentially suspicious OAuth authorization activity in Microsoft Entra ID where first-party Microsoft -applications from the FOCI (Family of Client IDs) group are used to request access to Microsoft Graph or legacy Azure AD -resources. This rule uses split detection logic: (1) Developer tools like Azure CLI, Visual Studio Code, and Azure -PowerShell accessing either Microsoft Graph or legacy AAD are flagged, as these are commonly abused in phishing -campaigns like ConsentFix. (2) Any FOCI family application accessing legacy Windows Azure Active Directory -(00000002-0000-0000-c000-000000000000) is flagged, as this deprecated resource is rarely accessed legitimately and -attackers use it for stealth. First-party apps are trusted by default in all tenants, allowed to request permissions -without admin approval, and cannot be deleted or blocked - making them ideal for OAuth phishing attacks. +applications from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources. +Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they +are commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the +deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers +target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal +for OAuth phishing attacks. """ from = "now-9m" index = ["filebeat-*", "logs-azure.signinlogs-*"] diff --git a/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml b/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml index 03a264b4880..692780a6416 100644 --- a/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml +++ b/rules/integrations/o365/defense_evasion_entra_id_susp_oauth2_authorization.toml @@ -8,11 +8,11 @@ updated_date = "2025/12/17" author = ["Elastic"] description = """ Identifies sign-ins on behalf of a principal user to the Microsoft Graph or legacy Azure AD API from multiple IPs using -first-party Microsoft applications from the FOCI (Family of Client IDs) group. This rule uses split detection logic: (1) -Developer tools like Azure CLI, VSCode, Azure PowerShell, or Microsoft Authentication Broker accessing Graph or legacy -AAD from multiple IPs, or (2) Any FOCI family application accessing legacy Windows Azure Active Directory from multiple -IPs. This behavior may indicate an adversary using a phished OAuth authorization code or refresh token, as seen in -attacks like ConsentFix where attackers steal localhost OAuth codes and replay them from attacker infrastructure. +first-party Microsoft applications from the FOCI (Family of Client IDs) group. Developer tools like Azure CLI, VSCode, +and Azure PowerShell accessing these resources from multiple IPs are flagged, along with any FOCI application accessing +the deprecated Windows Azure Active Directory from multiple IPs. This behavior may indicate an adversary using a phished +OAuth authorization code or refresh token, as seen in attacks like ConsentFix where attackers steal localhost OAuth +codes and replay them from attacker infrastructure. """ from = "now-60m" interval = "59m" diff --git a/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml b/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml index aa7871daf5f..f97a3f4fe2b 100644 --- a/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml +++ b/rules/integrations/o365/initial_access_identity_oauth_phishing_via_first_party_microsoft_application.toml @@ -8,13 +8,12 @@ updated_date = "2025/12/17" author = ["Elastic"] description = """ Detects potentially suspicious OAuth authorization activity in Microsoft 365 where first-party Microsoft applications -from the FOCI (Family of Client IDs) group are used to request access to Microsoft Graph or legacy Azure AD resources. -This rule uses split detection logic: (1) Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell -accessing either Microsoft Graph or legacy AAD are flagged, as these are commonly abused in phishing campaigns like -ConsentFix. (2) Any FOCI family application accessing legacy Windows Azure Active Directory -(00000002-0000-0000-c000-000000000000) is flagged, as this deprecated resource is rarely accessed legitimately and -attackers use it for stealth. First-party apps are trusted by default in all tenants, allowed to request permissions -without admin approval, and cannot be deleted or blocked - making them ideal for OAuth phishing attacks. +from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources. Developer +tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they are +commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the +deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers +target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal +for OAuth phishing attacks. """ from = "now-25m" index = ["logs-o365.audit-*"]