[Rule Tuning] Microsoft Entra ID Suspicious Session Reuse to Graph Access (#4954)

* adjusted query

* add keep; lint

* Update rules/integrations/azure/initial_access_entra_graph_single_session_from_multiple_addresses.toml

Co-authored-by: Jonhnathan <[email protected]>

---------

Co-authored-by: Jonhnathan <[email protected]>

Author: terrancedejesus

rules/integrations/azure/initial_access_entra_graph_single_session_from_multiple_addresses.toml

@@ -2,15 +2,16 @@
 creation_date = "2025/05/08"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/07/16"
+updated_date = "2025/07/31"
+
 
 [rule]
 author = ["Elastic"]
 description = """
 Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs
-in and subsequently accesses Microsoft Graph from a different IP address using the same session ID within a short time
-window. This may indicate the use of a stolen refresh/access token or session cookie to impersonate the user and
-interact with Microsoft services.
+in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a
+successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session
+cookie or refresh/access token and is impersonating the user from an alternate host or location.
 """
 false_positives = [
     """
@@ -20,40 +21,39 @@ false_positives = [
     are involved.
     """,
 ]
-from = "now-1h"
+from = "now-31m"
+interval = "30m"
 language = "esql"
 license = "Elastic License v2"
-name = "Microsoft Entra ID Session Reuse with Suspicious Graph Access"
+name = "Microsoft Entra ID Suspicious Session Reuse to Graph Access"
 note = """## Triage and analysis
 
-### Investigating Microsoft Entra ID Session Reuse with Suspicious Graph Access
+### Investigating Microsoft Entra ID Suspicious Session Reuse to Graph Access
 
-This rule identifies when Microsoft Graph is accessed from a different IP than the one used for the original sign-in,
-but using the same session ID within 5 minutes. This may suggest an adversary has stolen a session cookie or refresh/access
-token and is impersonating the user from an alternate host or location.
+Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location.
 
 This rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be
 performed to the original sign-in and Graph events for further context.
 
 ### Investigation Steps
 
-- Review the `user_id`, `session_id`, and `source_ip_list`. Confirm whether both IPs belong to the same user and geography.
-- Check for inconsistencies in `client_id_list` (e.g., unknown apps) or user agents across correlated events.
-- Investigate recent phishing reports or device infections for the `user_id`.
-- Pivot to Entra ID `auditlogs` to see if a device was registered or privileges were modified.
-- Review `graph_time` to determine what action was taken after the sign-in.
-- Use the `session_id` to correlate with other logs in the same time window to identify any additional suspicious activity.
+- This rule relies on an aggregation-based ESQL query, therefore the alert document will contain dynamically generated fields.
+    - To pivot into the original events, it is recommended to use the values captured to filter in timeline or discovery for the original sign-in and Graph events.
+- Review the session ID and user ID to identify the user account involved in the suspicious activity.
+- Check the source addresses involved in the sign-in and Graph access to determine if they are known or expected locations for the user.
+    - The sign-in source addresses should be two, one for the initial phishing sign-in and the other when exchanging the auth code for a token by the adversary.
+    - The Graph API source address should identify the IP address used by the adversary to access Microsoft Graph.
+- Review the user agent strings for the sign-in and Graph access events to identify any anomalies or indicators of compromise.
+- Check the timestamp difference between the sign-in and Graph access events to determine if they occurred within a reasonable time frame that would suggest successful phishing to token issuance and then Graph access.
+- Identify the original sign-in event to investigation if conditional access policies were applied, such as requiring multi-factor authentication or blocking access from risky locations. In phishing scenarios, these policies likely were applied as the victim user would have been prompted to authenticate.
 
 ### False Positive Analysis
-- This pattern may occur if the user is switching between networks (e.g., corporate to mobile) or using a VPN.
-- Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges.
-- However, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved.
-- If the user is a developer or automation engineer, validate if this behavior was for testing purposes.
-- If the user is a system administrator, validate if this behavior was for administrative purposes.
+- This pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile).
+- Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges. Still, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved.
 
 ### Response Recommendations
 
-- If confirmed malicious, revoke all refresh/access tokens for the `user_id`.
+- If confirmed malicious, revoke all refresh/access tokens for the user principal.
 - Block the source IP(s) involved in the Graph access.
 - Notify the user and reset credentials.
 - Review session control policies and conditional access enforcement.
@@ -65,14 +65,16 @@ references = [
     "https://github.com/dirkjanm/ROADtools",
     "https://attack.mitre.org/techniques/T1078/004/",
 ]
-risk_score = 73
+risk_score = 47
 rule_id = "0d3d2254-2b4a-11f0-a019-f661ea17fbcc"
 setup = """#### Required Microsoft Entra ID Sign-In and Graph Activity Logs
 This rule requires the Microsoft Entra ID Sign-In Logs and Microsoft Graph Activity Logs integration to be enabled and configured to collect audit and activity logs via Azure Event Hub.
 """
-severity = "high"
+severity = "medium"
 tags = [
     "Domain: Cloud",
+    "Domain: Identity",
+    "Domain: API",
     "Data Source: Azure",
     "Data Source: Microsoft Entra ID",
     "Data Source: Microsoft Entra ID Sign-In Logs",
@@ -88,7 +90,7 @@ timestamp_override = "event.ingested"
 type = "esql"
 
 query = '''
-from logs-azure.*
+from logs-azure.signinlogs-*, logs-azure.graphactivitylogs-* metadata _id, _version, _index
 | where
     (event.dataset == "azure.signinlogs"
      and source.`as`.organization.name != "MICROSOFT-CORP-MSN-as-BLOCK"