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 = "2026/04/10"
  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
 71]
 72timestamp_override = "event.ingested"
 73type = "new_terms"
 74
 75query = '''
 76data_stream.dataset: "azure.signinlogs" and
 77    event.category: "authentication" and
 78    azure.signinlogs.properties.user_type: "Member" and
 79    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and
 80    not azure.signinlogs.properties.device_detail.is_managed: true and
 81    not azure.signinlogs.properties.device_detail.device_id: "" and
 82    azure.signinlogs.properties.user_principal_name: *
 83'''
 84
 85
 86[[rule.threat]]
 87framework = "MITRE ATT&CK"
 88
 89[[rule.threat.technique]]
 90id = "T1098"
 91name = "Account Manipulation"
 92reference = "https://attack.mitre.org/techniques/T1098/"
 93
 94[[rule.threat.technique.subtechnique]]
 95id = "T1098.005"
 96name = "Device Registration"
 97reference = "https://attack.mitre.org/techniques/T1098/005/"
 98
 99[rule.threat.tactic]
100id = "TA0003"
101name = "Persistence"
102reference = "https://attack.mitre.org/tactics/TA0003/"
103
104[[rule.threat]]
105framework = "MITRE ATT&CK"
106
107[[rule.threat.technique]]
108id = "T1078"
109name = "Valid Accounts"
110reference = "https://attack.mitre.org/techniques/T1078/"
111
112[[rule.threat.technique.subtechnique]]
113id = "T1078.004"
114name = "Cloud Accounts"
115reference = "https://attack.mitre.org/techniques/T1078/004/"
116
117[rule.threat.tactic]
118id = "TA0001"
119name = "Initial Access"
120reference = "https://attack.mitre.org/tactics/TA0001/"
121
122[rule.investigation_fields]
123field_names = [
124    "azure.signinlogs.properties.user_principal_name",
125    "azure.signinlogs.properties.device_detail.device_id",
126    "azure.signinlogs.properties.incoming_token_type",
127    "azure.signinlogs.category",
128    "source.geo.country_name",
129    "source.geo.city_name",
130    "source.address",
131    "azure.signinlogs.properties.app_id",
132    "azure.signinlogs.properties.resource_id",
133    "azure.signinlogs.properties.risk_level",
134    "azure.signinlogs.properties.risk_detail",
135]
136
137[rule.new_terms]
138field = "new_terms_fields"
139value = [
140    "azure.signinlogs.properties.user_principal_name",
141    "azure.signinlogs.properties.device_detail.device_id",
142]
143[[rule.new_terms.history_window_start]]
144field = "history_window_start"
145value = "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_name field to identify the user associated with the sign-in.
  • Check the azure.signinlogs.properties.device_detail.device_id field to identify the device used for the sign-in.
  • 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).
  • Examine azure.signinlogs.category to determine if these were non-interactive or interactive sign-ins.
  • 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.
  • 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.
  • 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.
  • 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.

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_name and 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

to-top