Entra ID User Sign-in with Unusual Non-Managed Device

ELASTIC detection rule by Elastic · Elastic License v2

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.

[metadata]
creation_date = "2025/06/16"
integration = ["azure"]
maturity = "production"
updated_date = "2026/08/12"

[rule]
author = ["Elastic"]
description = """
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.
"""
from = "now-9m"
index = ["filebeat-*", "logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID User Sign-in with Unusual Non-Managed Device"
note = """## 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.
- Hybrid Azure AD joined devices often report `is_managed: false` when Intune MDM is not enrolled; that corporate hybrid-join state is excluded. Azure AD joined devices are kept in scope because OAuth phishing / ROADtx device registration commonly creates cloud-joined (not hybrid) unmanaged devices.
- Non-interactive sign-ins with `azure.signinlogs.properties.incoming_token_type` of `"none"` (common Microsoft first-party background token acquisition on registered devices) are excluded; `"primaryRefreshToken"` (PRT) and `"refreshToken"` activity remain in scope.

### 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 = [
    "https://pushsecurity.com/blog/consentfix",
    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
    "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/",
]
risk_score = 21
rule_id = "72c91fc0-4ac0-11f0-811f-f661ea17fbcd"
setup = """#### Required Microsoft Entra ID Sign-In Logs
This 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.
"""
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Platform: Entra ID",
    "Resources: Investigation Guide",

]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "azure.signinlogs" and
    event.category: "authentication" and
    azure.signinlogs.properties.user_type: "Member" and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and
    not azure.signinlogs.properties.device_detail.is_managed: true and
    not azure.signinlogs.properties.device_detail.device_id: "" and
    not azure.signinlogs.properties.device_detail.trust_type: "Hybrid Azure AD joined" and
    not (azure.signinlogs.category: "NonInteractiveUserSignInLogs" and azure.signinlogs.properties.incoming_token_type: "none") and
    azure.signinlogs.properties.user_principal_name: *
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]]
id = "T1098.005"
name = "Device Registration"
reference = "https://attack.mitre.org/techniques/T1098/005/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"

[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"

[rule.investigation_fields]
field_names = [
    "azure.signinlogs.properties.user_principal_name",
    "azure.signinlogs.properties.device_detail.device_id",
    "azure.signinlogs.properties.incoming_token_type",
    "azure.signinlogs.category",
    "source.geo.country_name",
    "source.geo.city_name",
    "source.address",
    "azure.signinlogs.properties.app_id",
    "azure.signinlogs.properties.resource_id",
    "azure.signinlogs.properties.risk_level",
    "azure.signinlogs.properties.risk_detail",
]

[rule.new_terms]
field = "new_terms_fields"
value = [
    "azure.signinlogs.properties.user_principal_name",
    "azure.signinlogs.properties.device_detail.device_id",
]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

5fe987bc-ad87-49c5-866e-0393ba6cbfa7

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion