Entra ID Windows Hello or Passkey Sign-in from Unregistered Device

Identifies a Microsoft Entra ID sign-in that is satisfied by a phishing-resistant, device-bound credential (Windows Hello for Business, FIDO2 security key, or passkey) while carrying no device identifier. Windows Hello for Business (WHfB) and passkey credentials are bound to a device's TPM, so a genuine sign-in with one of these methods is normally accompanied by the registered device it lives on. A WHfB or passkey assertion that authenticates with an empty device_detail.device_id indicates the underlying key material is being used away from its bound device, for example by an adversary who extracted the key (or signed an assertion with it) and replayed it from attacker infrastructure to mint device-agnostic tokens. This is the core primitive of the "borrowing Windows Hello keys" technique and is a strong precursor to attacker device registration and Primary Refresh Token (PRT) issuance. Cross-tenant (B2B) sign-ins are excluded because they are a common benign source of empty device identifiers.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/08/07"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2026/08/07"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies a Microsoft Entra ID sign-in that is satisfied by a phishing-resistant, device-bound credential (Windows
 11Hello for Business, FIDO2 security key, or passkey) while carrying no device identifier. Windows Hello for Business
 12(WHfB) and passkey credentials are bound to a device's TPM, so a genuine sign-in with one of these methods is normally
 13accompanied by the registered device it lives on. A WHfB or passkey assertion that authenticates with an empty
 14`device_detail.device_id` indicates the underlying key material is being used away from its bound device, for example by
 15an adversary who extracted the key (or signed an assertion with it) and replayed it from attacker infrastructure to mint
 16device-agnostic tokens. This is the core primitive of the "borrowing Windows Hello keys" technique and is a strong
 17precursor to attacker device registration and Primary Refresh Token (PRT) issuance. Cross-tenant (B2B) sign-ins are
 18excluded because they are a common benign source of empty device identifiers.
 19"""
 20false_positives = [
 21    """
 22    Rare edge cases during initial passwordless onboarding may briefly produce a Windows Hello for Business or passkey
 23    sign-in before the device is fully registered. Validate against the user's device registration timeline. Genuine
 24    WHfB and passkey sign-ins are otherwise accompanied by a populated device identifier.
 25    """,
 26]
 27from = "now-9m"
 28index = ["logs-azure.signinlogs-*"]
 29language = "kuery"
 30license = "Elastic License v2"
 31name = "Entra ID Windows Hello or Passkey Sign-in from Unregistered Device"
 32note = """## Triage and analysis
 33
 34### Investigating Entra ID Windows Hello or Passkey Sign-in from Unregistered Device
 35
 36WHfB and passkey credentials are bound to a device's TPM, so a legitimate sign-in with one of these methods is normally accompanied by its registered device. A same-tenant sign-in with an empty `device_detail.device_id` means the key material is being used away from its bound device - the core signal of the "borrowing Windows Hello keys" technique, where an adversary replays a WHfB/NGC key or passkey to mint device-agnostic tokens from their own infrastructure.
 37
 38### Possible investigation steps
 39- Identify the user via `user_principal_name` and confirm `authentication_details.authentication_method` is WHfB, FIDO2, or a passkey with `device_detail.device_id` empty (a `device_id` present on an unmanaged device is a different, noisier condition, not this rule).
 40- Review `app_id`/`resource_display_name` for Graph or Device Registration Service access right after, check `source.ip`, `source.geo.*`, and `user_agent.original` for automation (python-requests) or hosting/VPS ASNs (ROADtools/roadtx), and pivot on `user_id` in `azure.auditlogs` for a subsequent "Register device" or "Add Windows Hello for Business credential" event; if the user didn't enroll a new key/passkey, treat it as compromised.
 41
 42### False positive analysis
 43- Initial passwordless onboarding can briefly produce this sign-in before device registration completes; correlate with the registration timeline.
 44
 45### Response and remediation
 46- Treat the key/passkey as compromised: delete the credential and any attacker-registered device via Graph/the Entra portal, revoke sessions/refresh tokens (delete devices first, since that breaks device-bound PRT persistence), and re-enroll from a trusted device.
 47- Hunt for device registrations and PRT issuance after the sign-in, and consider Conditional Access requiring device compliance for sensitive resources.
 48"""
 49references = [
 50    "https://dirkjanm.io/borrowing-windows-hello-keys/",
 51    "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/",
 52]
 53risk_score = 47
 54rule_id = "763b0a74-2961-4396-bb4b-8cd850e1ebe4"
 55setup = """#### Required Microsoft Entra ID Sign-In Logs
 56This rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect sign-in logs via Azure Event Hub.
 57"""
 58severity = "medium"
 59tags = [
 60    "Domain: Cloud",
 61    "Domain: Identity",
 62    "Platform: Entra ID",
 63    "Use Case: Threat Detection",
 64    "Tactic: Defense Evasion",
 65    "Tactic: Initial Access",
 66    "Rule Type: New Terms",
 67    "Data Source: Azure",
 68    "Data Source: Microsoft Entra ID",
 69    "Data Source: Microsoft Entra ID Sign-in Logs",
 70    "Resources: Investigation Guide",
 71]
 72timestamp_override = "event.ingested"
 73type = "new_terms"
 74
 75query = '''
 76data_stream.dataset: "azure.signinlogs" and
 77    event.category: "authentication" and
 78    azure.signinlogs.result_signature: "SUCCESS" and
 79    azure.signinlogs.properties.user_type: "Member" and
 80    azure.signinlogs.properties.authentication_details.authentication_method: (
 81        "Windows Hello for Business" or *passkey* or FIDO2* or *Passkey*
 82    ) and
 83    azure.signinlogs.properties.device_detail.device_id: ("" or not *) and
 84    azure.signinlogs.properties.cross_tenant_access_type: "none" and
 85    azure.signinlogs.properties.user_principal_name: *
 86'''
 87
 88
 89[[rule.threat]]
 90framework = "MITRE ATT&CK"
 91[[rule.threat.technique]]
 92id = "T1550"
 93name = "Use Alternate Authentication Material"
 94reference = "https://attack.mitre.org/techniques/T1550/"
 95
 96
 97[rule.threat.tactic]
 98id = "TA0005"
 99name = "Defense Evasion"
100reference = "https://attack.mitre.org/tactics/TA0005/"
101[[rule.threat]]
102framework = "MITRE ATT&CK"
103[[rule.threat.technique]]
104id = "T1078"
105name = "Valid Accounts"
106reference = "https://attack.mitre.org/techniques/T1078/"
107[[rule.threat.technique.subtechnique]]
108id = "T1078.004"
109name = "Cloud Accounts"
110reference = "https://attack.mitre.org/techniques/T1078/004/"
111
112
113
114[rule.threat.tactic]
115id = "TA0001"
116name = "Initial Access"
117reference = "https://attack.mitre.org/tactics/TA0001/"
118
119[rule.investigation_fields]
120field_names = [
121    "azure.signinlogs.properties.user_principal_name",
122    "azure.signinlogs.properties.authentication_details.authentication_method",
123    "azure.signinlogs.properties.device_detail.device_id",
124    "azure.signinlogs.properties.device_detail.is_managed",
125    "azure.signinlogs.properties.cross_tenant_access_type",
126    "azure.signinlogs.properties.incoming_token_type",
127    "azure.signinlogs.properties.app_id",
128    "azure.signinlogs.properties.resource_display_name",
129    "source.geo.country_name",
130    "source.address",
131    "user_agent.original",
132]
133
134[rule.new_terms]
135field = "new_terms_fields"
136value = ["azure.signinlogs.properties.user_principal_name"]
137[[rule.new_terms.history_window_start]]
138field = "history_window_start"
139value = "now-7d"

Triage and analysis

Investigating Entra ID Windows Hello or Passkey Sign-in from Unregistered Device

WHfB and passkey credentials are bound to a device's TPM, so a legitimate sign-in with one of these methods is normally accompanied by its registered device. A same-tenant sign-in with an empty device_detail.device_id means the key material is being used away from its bound device - the core signal of the "borrowing Windows Hello keys" technique, where an adversary replays a WHfB/NGC key or passkey to mint device-agnostic tokens from their own infrastructure.

Possible investigation steps

  • Identify the user via user_principal_name and confirm authentication_details.authentication_method is WHfB, FIDO2, or a passkey with device_detail.device_id empty (a device_id present on an unmanaged device is a different, noisier condition, not this rule).
  • Review app_id/resource_display_name for Graph or Device Registration Service access right after, check source.ip, source.geo.*, and user_agent.original for automation (python-requests) or hosting/VPS ASNs (ROADtools/roadtx), and pivot on user_id in azure.auditlogs for a subsequent "Register device" or "Add Windows Hello for Business credential" event; if the user didn't enroll a new key/passkey, treat it as compromised.

False positive analysis

  • Initial passwordless onboarding can briefly produce this sign-in before device registration completes; correlate with the registration timeline.

Response and remediation

  • Treat the key/passkey as compromised: delete the credential and any attacker-registered device via Graph/the Entra portal, revoke sessions/refresh tokens (delete devices first, since that breaks device-bound PRT persistence), and re-enroll from a trusted device.
  • Hunt for device registrations and PRT issuance after the sign-in, and consider Conditional Access requiring device compliance for sensitive resources.

References

Related rules

to-top