Entra ID User Sign-in with Unusual Non-Managed Device
Identifies when a Microsoft Entra ID user signs in from a device that is not typically used by the user and is not managed, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/06/16"
3integration = ["azure"]
4maturity = "production"
5updated_date = "2025/12/17"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies when a Microsoft Entra ID user signs in from a device that is not typically used by the user and is not managed, which may
11indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing
12the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a
13new device to obtain a Primary Refresh Token (PRT) and maintain persistent access.
14"""
15from = "now-9m"
16index = ["filebeat-*", "logs-azure.signinlogs-*"]
17language = "kuery"
18license = "Elastic License v2"
19name = "Entra ID User Sign-in with Unusual Non-Managed Device"
20note = """## Triage and analysis
21
22### Investigating Entra ID User Sign-in with Unusual Non-Managed Device
23
24This rule detects when a Microsoft Entra ID user signs in from a device that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access.
25
26### Possible investigation steps
27- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user associated with the sign-in.
28- Check the `azure.signinlogs.properties.device_detail.device_id` field to identify the device used for the sign-in.
29- Review `azure.signinlogs.properties.incoming_token_type` to determine what tpe of security token was used for the sign-in, such as a Primary Refresh Token (PRT).
30- Examine `azure.signinlogs.category` to determine if these were non-interactive or interactive sign-ins.
31- Check the geolocation of the sign-in by reviewing `source.geo.country_name` and `source.geo.city_name` to identify the location of the device used for the sign-in. If these are unusual for the user, it may indicate a potential compromise.
32- Review `azure.signinlogs.properties.app_id` to determine which client application was used for the sign-in. If the application is not recognized or expected, it may indicate unauthorized access. Adversaries use first-party client IDs to blend in with legitimate traffic.
33- Examine `azure.signinlogs.properties.resource_id` to determine what resource the security token has in scope and/or is requesting access to. If the resource is not recognized or expected, it may indicate unauthorized access. Excessive access to Graph API is common post-compromise behavior.
34- Review the identity protection risk status by checking `azure.signinlogs.properties.risk_level` and `azure.signinlogs.properties.risk_detail` to determine if the sign-in was flagged as risky by Entra ID Protection.
35
36### False positive analysis
37- Legitimate users may sign in from new devices, such as when using a new laptop or mobile device. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or device IDs.
38- Environments where users frequently change devices, such as in a corporate setting with rotating hardware, may generate false positives.
39- Users may use both an endpoint and mobile device for sign-ins, which could trigger this rule.
40
41### Response and remediation
42- If the sign-in is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access.
43- Disable the user account temporarily to prevent any potential compromise or unauthorized access.
44- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access.
45- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user.
46- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources.
47- Identify the registered Entra ID device by reviewing `azure.signinlogs.properties.device_detail.display_name` and confirm it is expected for the user or organization. If it is not expected, consider removing the device registration.
48- Consider adding exceptions for verified devices that are known to be used by the user to reduce false-positives.
49"""
50references = [
51 "https://pushsecurity.com/blog/consentfix",
52 "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
53 "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/",
54]
55risk_score = 21
56rule_id = "72c91fc0-4ac0-11f0-811f-f661ea17fbcd"
57setup = """#### Required Microsoft Entra ID Sign-In Logs
58This rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect audit and activity logs via Azure Event Hub.
59"""
60severity = "low"
61tags = [
62 "Domain: Cloud",
63 "Domain: Identity",
64 "Use Case: Threat Detection",
65 "Tactic: Persistence",
66 "Data Source: Azure",
67 "Data Source: Microsoft Entra ID",
68 "Data Source: Microsoft Entra ID Sign-in Logs",
69 "Resources: Investigation Guide",
70]
71timestamp_override = "event.ingested"
72type = "new_terms"
73
74query = '''
75event.dataset: "azure.signinlogs" and
76 event.category: "authentication" and
77 azure.signinlogs.properties.user_type: "Member" and
78 azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and
79 not azure.signinlogs.properties.device_detail.is_managed: true and
80 not azure.signinlogs.properties.device_detail.device_id: "" and
81 azure.signinlogs.properties.user_principal_name: *
82'''
83
84
85[[rule.threat]]
86framework = "MITRE ATT&CK"
87[[rule.threat.technique]]
88id = "T1098"
89name = "Account Manipulation"
90reference = "https://attack.mitre.org/techniques/T1098/"
91[[rule.threat.technique.subtechnique]]
92id = "T1098.005"
93name = "Device Registration"
94reference = "https://attack.mitre.org/techniques/T1098/005/"
95
96
97
98[rule.threat.tactic]
99id = "TA0003"
100name = "Persistence"
101reference = "https://attack.mitre.org/tactics/TA0003/"
102[[rule.threat]]
103framework = "MITRE ATT&CK"
104[[rule.threat.technique]]
105id = "T1078"
106name = "Valid Accounts"
107reference = "https://attack.mitre.org/techniques/T1078/"
108[[rule.threat.technique.subtechnique]]
109id = "T1078.004"
110name = "Cloud Accounts"
111reference = "https://attack.mitre.org/techniques/T1078/004/"
112
113
114
115[rule.threat.tactic]
116id = "TA0001"
117name = "Initial Access"
118reference = "https://attack.mitre.org/tactics/TA0001/"
119
120[rule.investigation_fields]
121field_names = [
122 "azure.signinlogs.properties.user_principal_name",
123 "azure.signinlogs.properties.device_detail.device_id",
124 "azure.signinlogs.properties.incoming_token_type",
125 "azure.signinlogs.category",
126 "source.geo.country_name",
127 "source.geo.city_name",
128 "source.address",
129 "azure.signinlogs.properties.app_id",
130 "azure.signinlogs.properties.resource_id",
131 "azure.signinlogs.properties.risk_level",
132 "azure.signinlogs.properties.risk_detail",
133]
134
135[rule.new_terms]
136field = "new_terms_fields"
137value = [
138 "azure.signinlogs.properties.user_principal_name",
139 "azure.signinlogs.properties.device_detail.device_id",
140]
141[[rule.new_terms.history_window_start]]
142field = "history_window_start"
143value = "now-7d"
Triage and analysis
Investigating Entra ID User Sign-in with Unusual Non-Managed Device
This rule detects when a Microsoft Entra ID user signs in from a device that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access.
Possible investigation steps
- Review the
azure.signinlogs.properties.user_principal_namefield to identify the user associated with the sign-in. - Check the
azure.signinlogs.properties.device_detail.device_idfield to identify the device used for the sign-in. - Review
azure.signinlogs.properties.incoming_token_typeto determine what tpe of security token was used for the sign-in, such as a Primary Refresh Token (PRT). - Examine
azure.signinlogs.categoryto determine if these were non-interactive or interactive sign-ins. - Check the geolocation of the sign-in by reviewing
source.geo.country_nameandsource.geo.city_nameto identify the location of the device used for the sign-in. If these are unusual for the user, it may indicate a potential compromise. - Review
azure.signinlogs.properties.app_idto determine which client application was used for the sign-in. If the application is not recognized or expected, it may indicate unauthorized access. Adversaries use first-party client IDs to blend in with legitimate traffic. - Examine
azure.signinlogs.properties.resource_idto determine what resource the security token has in scope and/or is requesting access to. If the resource is not recognized or expected, it may indicate unauthorized access. Excessive access to Graph API is common post-compromise behavior. - Review the identity protection risk status by checking
azure.signinlogs.properties.risk_levelandazure.signinlogs.properties.risk_detailto determine if the sign-in was flagged as risky by Entra ID Protection.
False positive analysis
- Legitimate users may sign in from new devices, such as when using a new laptop or mobile device. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or device IDs.
- Environments where users frequently change devices, such as in a corporate setting with rotating hardware, may generate false positives.
- Users may use both an endpoint and mobile device for sign-ins, which could trigger this rule.
Response and remediation
- If the sign-in is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access.
- Disable the user account temporarily to prevent any potential compromise or unauthorized access.
- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access.
- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user.
- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources.
- Identify the registered Entra ID device by reviewing
azure.signinlogs.properties.device_detail.display_nameand confirm it is expected for the user or organization. If it is not expected, consider removing the device registration. - Consider adding exceptions for verified devices that are known to be used by the user to reduce false-positives.
References
Related rules
- Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource
- Entra ID OAuth PRT Issuance to Non-Managed Device Detected
- Entra ID OAuth User Impersonation to Microsoft Graph
- Entra ID OAuth user_impersonation Scope for Unusual User and Client
- Entra ID ADRS Token Request by Microsoft Authentication Broker