Suspicious Activity via Auth Broker On-Behalf-of Principal User

Identifies suspicious activity from the Microsoft Authentication Broker in Microsoft Entra ID sign-in logs. This behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT) to register a device and access Microsoft services as a user. The pattern includes sign-ins from multiple IPs across services (Microsoft Graph, DRS, AAD) using the Authentication Broker client on behalf of a principal user.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/04/30"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2025/04/30"
  6min_stack_version = "8.17.0"
  7min_stack_comments = "Elastic ES|QL values aggregation is more performant in 8.16.5 and above."
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Identifies suspicious activity from the Microsoft Authentication Broker in Microsoft Entra ID sign-in logs. This
 13behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT) to register a
 14device and access Microsoft services as a user. The pattern includes sign-ins from multiple IPs across services
 15(Microsoft Graph, DRS, AAD) using the Authentication Broker client on behalf of a principal user.
 16"""
 17false_positives = [
 18    """
 19    Legitimate device registrations using Microsoft Authentication Broker may occur during corporate enrollment
 20    scenarios or bulk provisioning, but it is uncommon for multiple source IPs to register the same identity across
 21    Microsoft Graph, Device Registration Service (DRS), and Azure Active Directory (AAD) in a short time span.
 22    """,
 23]
 24from = "now-1h"
 25language = "esql"
 26license = "Elastic License v2"
 27name = "Suspicious Activity via Auth Broker On-Behalf-of Principal User"
 28note = """## Triage and analysis
 29
 30### Investigating Suspicious Activity via Auth Broker On-Behalf-of Principal User
 31
 32This rule identifies suspicious activity from the Microsoft Authentication Broker where the same identity accesses Microsoft Graph at least twice and either Device Registration Service (DRS) or Azure Active Directory (AAD) once — all from multiple unique source IPs within a short window. This behavior may indicate the use of a previously phished refresh token to impersonate a user and register a device, followed by an attempt to acquire a Primary Refresh Token (PRT) for persistent access.
 33
 34### Possible Investigation Steps:
 35
 36- `target`: The user principal name targeted by the authentication broker. Investigate whether this user has recently registered a device, signed in from new IPs, or has had recent password resets or MFA changes.
 37- `azure.signinlogs.identity`: The identity value the broker is acting on behalf of. This may be useful when correlating to device registration records or audit events tied to object IDs.
 38- `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).
 39- `incoming_token_type`: Look for values like `"refreshToken"` or `"none"`, which may indicate token replay. `"refreshToken"` suggests broker-based reauthentication using stolen credentials.
 40- `user_agents`: Check for mixed user agent strings. Automation tools (e.g., `python-requests`) alongside browser-based agents (e.g., Chrome on macOS) may indicate scripted misuse of tokens.
 41- `OS`: Review for inconsistencies. For example, if both `Windows` and `MacOs` appear during a short time span for the same user, this may point to token abuse across multiple environments.
 42- `target_time_window`: Use the truncated time window to pivot into raw `azure.signinlogs` to reconstruct the full sequence of resource access events, including exact timestamps and service targets.
 43- `azure.auditlogs` to check for device join or registration events around the same timeframe.
 44- `azure.identityprotection` to identify correlated risk detections, such as anonymized IP access or token replay.
 45- Any additional sign-ins from the `ips` involved, even outside the broker, to determine if tokens have been reused elsewhere.
 46
 47### False Positive Analysis
 48
 49- This pattern may occur if the user is registering a new device legitimately from two networks (e.g., mobile hotspot and home).
 50- Security software (e.g., endpoint detection tools) or identity clients may produce rapid Graph and DRS access in rare edge cases.
 51- Developers or IT administrators working across environments may also produce similar behavior.
 52
 53### Response and Remediation
 54
 55- If confirmed unauthorized, revoke all refresh tokens for the affected user and remove any devices registered during this session.
 56- Notify the user and determine whether the device join or authentication activity was expected.
 57- Audit Conditional Access and broker permissions (`29d9ed98-a469-4536-ade2-f981bc1d605e`) to ensure policies enforce strict access controls.
 58- Consider blocking token-based reauthentication to Microsoft Graph and DRS from suspicious locations or user agents.
 59- Continue monitoring for follow-on activity like lateral movement or privilege escalation.
 60"""
 61references = [
 62    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
 63    "https://github.com/dirkjanm/ROADtools",
 64    "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/",
 65]
 66risk_score = 73
 67rule_id = "375132c6-25d5-11f0-8745-f661ea17fbcd"
 68setup = """#### Required Microsoft Entra ID Sign-In Logs
 69This rule requires the Microsoft Entra ID Sign-In Logs integration be enabled and configured to collect sign-in logs. In Entra ID, sign-in logs must be enabled and streaming to the Event Hub used for the Azure integration.
 70"""
 71severity = "high"
 72tags = [
 73    "Domain: Cloud",
 74    "Data Source: Azure",
 75    "Data Source: Entra ID",
 76    "Data Source: Entra ID Sign-in Logs",
 77    "Use Case: Identity and Access Audit",
 78    "Use Case: Threat Detection",
 79    "Resources: Investigation Guide",
 80    "Tactic: Defense Evasion",
 81    "Tactic: Persistence",
 82]
 83timestamp_override = "event.ingested"
 84type = "esql"
 85
 86query = '''
 87FROM logs-azure.signinlogs* metadata _id, _version, _index
 88
 89// filter for Microsoft Entra ID Sign-in Logs
 90| where event.dataset == "azure.signinlogs"
 91
 92    // filters on member principals, excluding service principals
 93    and azure.signinlogs.properties.user_type == "Member"
 94    and source.ip is not null
 95    and azure.signinlogs.identity is not null
 96    and azure.signinlogs.properties.user_principal_name is not null
 97    and event.outcome == "success"
 98
 99    // filter for successful sign-ins to Microsoft Graph and DRS/AAD from the Microsoft Authentication Broker
100    and (azure.signinlogs.properties.app_display_name == "Microsoft Authentication Broker" or azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e")
101    and azure.signinlogs.properties.resource_display_name in ("Device Registration Service", "Microsoft Graph", "Windows Azure Active Directory")
102
103// keep relevant fields
104| keep @timestamp, azure.signinlogs.identity, source.ip, azure.signinlogs.properties.app_display_name, azure.signinlogs.properties.resource_display_name, azure.signinlogs.properties.user_principal_name, azure.signinlogs.properties.incoming_token_type, user_agent.original, azure.signinlogs.properties.device_detail.operating_system
105
106// aggregate by 30-minute time window
107| eval target_time_window = DATE_TRUNC(30 minutes, @timestamp)
108
109// case statements to track which are MS Graph, DRS, and AAD access
110| eval ms_graph = case(azure.signinlogs.properties.resource_display_name == "Microsoft Graph", source.ip, null), drs = case(azure.signinlogs.properties.resource_display_name == "Device Registration Service", source.ip, null), aad = case(azure.signinlogs.properties.resource_display_name == "Windows Azure Active Directory", source.ip, null)
111
112// aggregate by principal and time window
113// store token types, target user, unique source IPs, and user agents in arrays for investigation
114| stats is_ms_graph = COUNT_DISTINCT(ms_graph), is_drs = COUNT_DISTINCT(drs), is_aad = COUNT_DISTINCT(aad), unique_src_ip = COUNT_DISTINCT(source.ip), ips = VALUES(source.ip), incoming_token_type = VALUES(azure.signinlogs.properties.incoming_token_type), target = VALUES(azure.signinlogs.properties.user_principal_name), user_agents = VALUES(user_agent.original), OS = VALUES(azure.signinlogs.properties.device_detail.operating_system) by azure.signinlogs.identity, target_time_window
115
116// filter for cases with multiple unique source IPs, and at least one DRS or AAD access, and multiple MS Graph accesses
117| where unique_src_ip >= 2 and (is_drs >= 1 or is_aad >= 1) and is_ms_graph >= 2
118'''
119
120
121[[rule.threat]]
122framework = "MITRE ATT&CK"
123[[rule.threat.technique]]
124id = "T1550"
125name = "Use Alternate Authentication Material"
126reference = "https://attack.mitre.org/techniques/T1550/"
127[[rule.threat.technique.subtechnique]]
128id = "T1550.001"
129name = "Application Access Token"
130reference = "https://attack.mitre.org/techniques/T1550/001/"
131
132
133
134[rule.threat.tactic]
135id = "TA0005"
136name = "Defense Evasion"
137reference = "https://attack.mitre.org/tactics/TA0005/"
138[[rule.threat]]
139framework = "MITRE ATT&CK"
140[[rule.threat.technique]]
141id = "T1098"
142name = "Account Manipulation"
143reference = "https://attack.mitre.org/techniques/T1098/"
144[[rule.threat.technique.subtechnique]]
145id = "T1098.005"
146name = "Device Registration"
147reference = "https://attack.mitre.org/techniques/T1098/005/"
148
149
150
151[rule.threat.tactic]
152id = "TA0003"
153name = "Persistence"
154reference = "https://attack.mitre.org/tactics/TA0003/"

Triage and analysis

Investigating Suspicious Activity via Auth Broker On-Behalf-of Principal User

This rule identifies suspicious activity from the Microsoft Authentication Broker where the same identity accesses Microsoft Graph at least twice and either Device Registration Service (DRS) or Azure Active Directory (AAD) once — all from multiple unique source IPs within a short window. This behavior may indicate the use of a previously phished refresh token to impersonate a user and register a device, followed by an attempt to acquire a Primary Refresh Token (PRT) for persistent access.

Possible Investigation Steps:

  • target: The user principal name targeted by the authentication broker. Investigate whether this user has recently registered a device, signed in from new IPs, or has had recent password resets or MFA changes.
  • azure.signinlogs.identity: The identity value the broker is acting on behalf of. This may be useful when correlating to device registration records or audit events tied to object IDs.
  • 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).
  • incoming_token_type: Look for values like "refreshToken" or "none", which may indicate token replay. "refreshToken" suggests broker-based reauthentication using stolen credentials.
  • user_agents: Check for mixed user agent strings. Automation tools (e.g., python-requests) alongside browser-based agents (e.g., Chrome on macOS) may indicate scripted misuse of tokens.
  • OS: Review for inconsistencies. For example, if both Windows and MacOs appear during a short time span for the same user, this may point to token abuse across multiple environments.
  • target_time_window: Use the truncated time window to pivot into raw azure.signinlogs 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.

False Positive Analysis

  • This pattern may occur if the user is registering a new device legitimately from two networks (e.g., mobile hotspot and home).
  • Security software (e.g., endpoint detection tools) or identity clients may produce rapid Graph and DRS access in rare edge cases.
  • 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.

References

Related rules

to-top