Entra ID OAuth user_impersonation Scope for Unusual User and Client
Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not associated with a specific device or session. This behavior is indicative of potential account compromise or unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/07/03"
3integration = ["azure"]
4maturity = "production"
5updated_date = "2026/08/12"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth
11scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized
12access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not
13associated with a specific device or session. This behavior is indicative of potential account compromise or
14unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen
15in the last 10 days, indicating potential abuse or unusual activity.
16"""
17from = "now-9m"
18index = ["filebeat-*", "logs-azure.signinlogs-*"]
19language = "kuery"
20license = "Elastic License v2"
21name = "Entra ID OAuth user_impersonation Scope for Unusual User and Client"
22note = """## Triage and analysis
23
24### Investigating Entra ID OAuth user_impersonation Scope for Unusual User and Client
25
26Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing `user_impersonation`, and a token issuer type of `AzureAD`. This rule is designed to detect suspicious
27OAuth user impersonation attempts in Microsoft Entra ID, particularly those involving the `user_impersonation` scope, which is often used by adversaries to gain unauthorized access to user accounts. The rule focuses on sign-in events where
28the sign-in session status is `unbound`, indicating that the session is not associated with a specific device or session, making it more vulnerable to abuse. This behavior is indicative of potential account compromise or
29unauthorized access attempts, especially when the user type is `Member` and the sign-in outcome is `success`. The rule aims to identify these events to facilitate timely investigation and response to potential security incidents. This is a New Terms rule that flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity.
30
31### Possible investigation steps
32
33- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the OAuth workflow.
34- Check the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` field for the presence of `user_impersonation`. This scope is commonly used in OAuth flows to allow applications to access user resources on behalf of the user.
35- Confirm that the `azure.signinlogs.properties.authentication_requirement` is set to `singleFactorAuthentication`, indicating that the sign-in did not require multi-factor authentication (MFA). This can be a red flag, as MFA is a critical security control that helps prevent unauthorized access.
36- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to identify the application involved in the OAuth workflow. Check if this application is known and trusted, or if it appears suspicious or unauthorized. FOCI applications are commonly abused by adversaries to evade security controls or conditional access policies.
37- Analyze the `azure.signinlogs.properties.client_ip` to determine the source of the sign-in attempt. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior.
38- Examine the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id` to identify the resource being accessed during the OAuth workflow. This can help determine if the access was legitimate or if it targeted sensitive resources. It may also help pivot to other related events or activities.
39- Use the `azure.signinlogs.properties.session_id` or `azure.signinlogs.properties.correlation_id` to correlate this event with other related sign-in events or activities. This can help identify patterns of suspicious behavior or potential account compromise.
40
41### False positive analysis
42
43- Some legitimate applications may use the `user_impersonation` scope for valid purposes, such as accessing user resources on behalf of the user. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.
44- Users may occasionally authenticate using single-factor authentication for specific applications or scenarios, especially in environments where MFA is not enforced or required. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications.
45- Some applications may use the `user_impersonation` scope for legitimate purposes, such as accessing user resources in a controlled manner. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.
46- The `restricted_user_impersonation` scope is distinct from `user_impersonation` and is excluded.
47- Expected OCaaS bootstrap requests from Exchange Online or Microsoft Forms Web are excluded when they originate from compliant, managed, joined Windows devices and do not use an incoming refresh token or primary refresh token.
48
49### Response and remediation
50
51- Contact the user to validate the OAuth workflow and assess whether they were targeted or tricked by a malicious actor.
52- If the OAuth workflow is confirmed to be malicious:
53 - Block the user account and reset the password to prevent further unauthorized access.
54 - Revoke active sessions and refresh tokens associated with the user principal.
55 - Review the application involved in the OAuth workflow and determine if it should be blocked or removed from the tenant.
56 - Investigate the source of the sign-in attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity.
57 - Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified.
58- Educate users about the risks associated with OAuth user impersonation and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible.
59"""
60references = [
61 "https://aadinternals.com/post/phishing/",
62 "https://dirkjanm.io/assets/raw/Finding%20Entra%20ID%20CA%20Bypasses%20-%20the%20structured%20way.pdf",
63 "https://github.com/Flangvik/TeamFiltration",
64 "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign",
65]
66risk_score = 47
67rule_id = "9563dace-5822-11f0-b1d3-f661ea17fbcd"
68severity = "medium"
69tags = [
70 "Domain: Cloud",
71 "Domain: Identity",
72 "Use Case: Threat Detection",
73 "Data Source: Azure",
74 "Data Source: Microsoft Entra ID",
75 "Data Source: Microsoft Entra ID Sign-in Logs",
76 "Platform: Entra ID",
77 "Tactic: Initial Access",
78 "Tactic: Defense Evasion",
79 "Rule Type: New Terms",
80 "Resources: Investigation Guide",
81]
82timestamp_override = "event.ingested"
83type = "new_terms"
84
85query = '''
86data_stream.dataset:azure.signinlogs and
87azure.signinlogs.properties.authentication_processing_details:(*user_impersonation* and not *restricted_user_impersonation*) and
88azure.signinlogs.properties.authentication_requirement:singleFactorAuthentication and
89azure.signinlogs.properties.token_issuer_type:AzureAD and
90azure.signinlogs.properties.token_protection_status_details.sign_in_session_status:unbound and
91azure.signinlogs.properties.user_type:Member and
92azure.signinlogs.properties.conditional_access_status:"notApplied" and
93not user_agent.original:(Microsoft*Authentication*iPhone* or Mozilla*PKeyAuth/1.0) and
94not azure.signinlogs.properties.device_detail.operating_system:(Android* or Ios*) and
95event.outcome:success and
96not azure.signinlogs.properties.app_id:(
97 0000000c-0000-0000-c000-000000000000 or
98 0a5f63c0-b750-4f38-a71c-4fc0d58b89e2 or
99 48af08dc-f6d2-435f-b2a7-069abd99c086 or
100 5e3ce6c0-2b1f-4285-8d4b-75ee78787346 or
101 65d91a3d-ab74-42e6-8a2f-0add61688c74 or
102 66a88757-258c-4c72-893c-3e8bed4d6899 or
103 6bc3b958-689b-49f5-9006-36d165f30e00 or
104 8c59ead7-d703-4a27-9e55-c96a0054c8d2 or
105 95de633a-083e-42f5-b444-a4295d8e9314 or
106 ab9b8c07-8f02-4f72-87fa-80105867a763 or
107 cc15fd57-2c6c-4117-a88c-83b1d56b4bbe or
108 d52792f4-ba38-424d-8140-ada5b883f293 or
109 e8be65d6-d430-4289-a665-51bf2a194bda or
110 fc0f3af4-6835-4174-b806-f7db311fd2f3
111) and
112not (
113 azure.signinlogs.properties.resource_id:c2ada927-a9e2-4564-aae2-70775a2fa0af and
114 (
115 azure.signinlogs.properties.app_id:00000002-0000-0ff1-ce00-000000000000 and
116 azure.signinlogs.properties.device_detail.operating_system:Windows or
117 azure.signinlogs.properties.app_id:5f00fd34-f302-417f-81ef-1adda179d8fd and
118 azure.signinlogs.properties.device_detail.operating_system:Windows*
119 ) and
120 azure.signinlogs.properties.device_detail.is_managed:true and
121 azure.signinlogs.properties.device_detail.is_compliant:true and
122 azure.signinlogs.properties.device_detail.trust_type:("Azure AD joined" or "Hybrid Azure AD joined") and
123 azure.signinlogs.properties.device_detail.device_id:(* and not "") and
124 azure.signinlogs.properties.incoming_token_type:none and
125 azure.signinlogs.properties.client_app_used:Browser and
126 azure.signinlogs.category:NonInteractiveUserSignInLogs
127)
128'''
129
130[rule.investigation_fields]
131field_names = [
132 "@timestamp",
133 "azure.correlation_id",
134 "azure.signinlogs.category",
135 "azure.signinlogs.identity",
136 "azure.signinlogs.properties.app_display_name",
137 "azure.signinlogs.properties.app_id",
138 "azure.signinlogs.properties.app_owner_tenant_id",
139 "azure.signinlogs.properties.authentication_requirement",
140 "azure.signinlogs.properties.client_credential_type",
141 "azure.signinlogs.properties.conditional_access_status",
142 "azure.signinlogs.properties.device_detail.operating_system",
143 "azure.signinlogs.properties.is_interactive",
144 "azure.signinlogs.properties.session_id",
145 "azure.signinlogs.properties.user_principal_name",
146 "azure.signinlogs.properties.user_type",
147 "azure.signinlogs.result_signature",
148 "azure.tenant_id",
149 "source.address",
150 "user.id"
151]
152
153
154[[rule.threat]]
155framework = "MITRE ATT&CK"
156[[rule.threat.technique]]
157id = "T1078"
158name = "Valid Accounts"
159reference = "https://attack.mitre.org/techniques/T1078/"
160[[rule.threat.technique.subtechnique]]
161id = "T1078.004"
162name = "Cloud Accounts"
163reference = "https://attack.mitre.org/techniques/T1078/004/"
164
165
166
167[rule.threat.tactic]
168id = "TA0001"
169name = "Initial Access"
170reference = "https://attack.mitre.org/tactics/TA0001/"
171[[rule.threat]]
172framework = "MITRE ATT&CK"
173[[rule.threat.technique]]
174id = "T1550"
175name = "Use Alternate Authentication Material"
176reference = "https://attack.mitre.org/techniques/T1550/"
177[[rule.threat.technique.subtechnique]]
178id = "T1550.001"
179name = "Application Access Token"
180reference = "https://attack.mitre.org/techniques/T1550/001/"
181
182[[rule.threat.technique]]
183id = "T1656"
184name = "Impersonation"
185reference = "https://attack.mitre.org/techniques/T1656/"
186
187
188
189[rule.threat.tactic]
190id = "TA0005"
191name = "Defense Evasion"
192reference = "https://attack.mitre.org/tactics/TA0005/"
193
194[rule.new_terms]
195field = "new_terms_fields"
196value = ["azure.signinlogs.properties.user_principal_name", "azure.signinlogs.properties.app_id"]
197[[rule.new_terms.history_window_start]]
198field = "history_window_start"
199value = "now-10d"
Triage and analysis
Investigating Entra ID OAuth user_impersonation Scope for Unusual User and Client
Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing user_impersonation, and a token issuer type of AzureAD. This rule is designed to detect suspicious
OAuth user impersonation attempts in Microsoft Entra ID, particularly those involving the user_impersonation scope, which is often used by adversaries to gain unauthorized access to user accounts. The rule focuses on sign-in events where
the sign-in session status is unbound, indicating that the session is not associated with a specific device or session, making it more vulnerable to abuse. This behavior is indicative of potential account compromise or
unauthorized access attempts, especially when the user type is Member and the sign-in outcome is success. The rule aims to identify these events to facilitate timely investigation and response to potential security incidents. This is a New Terms rule that flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity.
Possible investigation steps
- Review the
azure.signinlogs.properties.user_principal_namefield to identify the user principal involved in the OAuth workflow. - Check the
azure.signinlogs.properties.authentication_processing_details.Oauth Scope Infofield for the presence ofuser_impersonation. This scope is commonly used in OAuth flows to allow applications to access user resources on behalf of the user. - Confirm that the
azure.signinlogs.properties.authentication_requirementis set tosingleFactorAuthentication, indicating that the sign-in did not require multi-factor authentication (MFA). This can be a red flag, as MFA is a critical security control that helps prevent unauthorized access. - Review the
azure.signinlogs.properties.app_display_nameorazure.signinlogs.properties.app_idto identify the application involved in the OAuth workflow. Check if this application is known and trusted, or if it appears suspicious or unauthorized. FOCI applications are commonly abused by adversaries to evade security controls or conditional access policies. - Analyze the
azure.signinlogs.properties.client_ipto determine the source of the sign-in attempt. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior. - Examine the
azure.signinlogs.properties.resource_display_nameorazure.signinlogs.properties.resource_idto identify the resource being accessed during the OAuth workflow. This can help determine if the access was legitimate or if it targeted sensitive resources. It may also help pivot to other related events or activities. - Use the
azure.signinlogs.properties.session_idorazure.signinlogs.properties.correlation_idto correlate this event with other related sign-in events or activities. This can help identify patterns of suspicious behavior or potential account compromise.
False positive analysis
- Some legitimate applications may use the
user_impersonationscope for valid purposes, such as accessing user resources on behalf of the user. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. - Users may occasionally authenticate using single-factor authentication for specific applications or scenarios, especially in environments where MFA is not enforced or required. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications.
- Some applications may use the
user_impersonationscope for legitimate purposes, such as accessing user resources in a controlled manner. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. - The
restricted_user_impersonationscope is distinct fromuser_impersonationand is excluded. - Expected OCaaS bootstrap requests from Exchange Online or Microsoft Forms Web are excluded when they originate from compliant, managed, joined Windows devices and do not use an incoming refresh token or primary refresh token.
Response and remediation
- Contact the user to validate the OAuth workflow and assess whether they were targeted or tricked by a malicious actor.
- If the OAuth workflow is confirmed to be malicious:
- Block the user account and reset the password to prevent further unauthorized access.
- Revoke active sessions and refresh tokens associated with the user principal.
- Review the application involved in the OAuth workflow and determine if it should be blocked or removed from the tenant.
- Investigate the source of the sign-in attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity.
- Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified.
- Educate users about the risks associated with OAuth user impersonation and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible.
References
Related rules
- Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN
- Entra ID User Sign-in with Unusual Non-Managed Device
- Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource
- Microsoft Entra ID Impossible Travel Sign-in
- Entra ID OAuth Device Code Phishing via AiTM