updating investigation guides to be standardized

Author: terrancedejesus

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",

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",

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/",