Microsoft Entra ID Suspicious Session Reuse to Graph Access

edit
A newer version is available. Check out the latest documentation.

Microsoft Entra ID Suspicious Session Reuse to Graph Access

edit

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.

Rule type: esql

Rule indices: None

Severity: medium

Risk score: 47

Runs every: 30m

Searches indices from: now-31m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: Identity
  • Domain: API
  • Data Source: Azure
  • Data Source: Microsoft Entra ID
  • Data Source: Microsoft Entra ID Sign-In Logs
  • Data Source: Microsoft Graph
  • Data Source: Microsoft Graph Activity Logs
  • Use Case: Identity and Access Audit
  • Use Case: Threat Detection
  • Resources: Investigation Guide
  • Tactic: Defense Evasion
  • Tactic: Initial Access

Version: 4

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Microsoft Entra ID Suspicious Session Reuse to Graph Access

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

  • 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 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 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.
  • Monitor for follow-on activity, such as lateral movement or privilege escalation.
  • Review conditional access policies to ensure they are enforced correctly.

Setup

edit

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.

Rule query

edit
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"
     and azure.signinlogs.properties.session_id is not null)
    or
    (event.dataset == "azure.graphactivitylogs"
     and source.`as`.organization.name != "MICROSOFT-CORP-MSN-as-BLOCK"
     and azure.graphactivitylogs.properties.c_sid is not null)

| eval
    Esql.azure_signinlogs_properties_session_id_coalesce = coalesce(azure.signinlogs.properties.session_id, azure.graphactivitylogs.properties.c_sid),
    Esql.azure_signinlogs_properties_user_id_coalesce = coalesce(azure.signinlogs.properties.user_id, azure.graphactivitylogs.properties.user_principal_object_id),
    Esql.azure_signinlogs_properties_app_id_coalesce = coalesce(azure.signinlogs.properties.app_id, azure.graphactivitylogs.properties.app_id),
    Esql.source_ip = source.ip,
    Esql.@timestamp = @timestamp,
    Esql.event_type_case = case(
        event.dataset == "azure.signinlogs", "signin",
        event.dataset == "azure.graphactivitylogs", "graph",
        "other"
    ),
    Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)

| keep
    Esql.azure_signinlogs_properties_session_id_coalesce,
    Esql.source_ip,
    Esql.@timestamp,
    Esql.event_type_case,
    Esql.time_window_date_trunc,
    Esql.azure_signinlogs_properties_user_id_coalesce,
    Esql.azure_signinlogs_properties_app_id_coalesce

| stats
    Esql.azure_signinlogs_properties_user_id_coalesce_values = values(Esql.azure_signinlogs_properties_user_id_coalesce),
    Esql.azure_signinlogs_properties_session_id_coalesce_values = values(Esql.azure_signinlogs_properties_session_id_coalesce),
    Esql.source_ip_values = values(Esql.source_ip),
    Esql.source_ip_count_distinct = count_distinct(Esql.source_ip),
    Esql.azure_signinlogs_properties_app_id_coalesce_values = values(Esql.azure_signinlogs_properties_app_id_coalesce),
    Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct = count_distinct(Esql.azure_signinlogs_properties_app_id_coalesce),
    Esql.event_type_case_values = values(Esql.event_type_case),
    Esql.event_type_case_count_distinct = count_distinct(Esql.event_type_case),
    Esql.@timestamp.min = min(Esql.@timestamp),
    Esql.@timestamp.max = max(Esql.@timestamp),
    Esql.signin_time_min = min(case(Esql.event_type_case == "signin", Esql.@timestamp, null)),
    Esql.graph_time_min = min(case(Esql.event_type_case == "graph", Esql.@timestamp, null)),
    Esql.event_count = count()
  by Esql.azure_signinlogs_properties_session_id_coalesce, Esql.time_window_date_trunc

| eval
    Esql.event_duration_minutes_date_diff = date_diff("minutes", Esql.@timestamp.min, Esql.@timestamp.max),
    Esql.event_signin_to_graph_delay_minutes_date_diff = date_diff("minutes", Esql.signin_time_min, Esql.graph_time_min)

| where
    Esql.event_type_case_count_distinct > 1 and
    Esql.source_ip_count_distinct > 1 and
    Esql.event_duration_minutes_date_diff <= 5 and
    Esql.signin_time_min is not null and
    Esql.graph_time_min is not null and
    Esql.event_signin_to_graph_delay_minutes_date_diff >= 0

Framework: MITRE ATT&CKTM