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_nameand confirmauthentication_details.authentication_methodis WHfB, FIDO2, or a passkey withdevice_detail.device_idempty (adevice_idpresent on an unmanaged device is a different, noisier condition, not this rule). - Review
app_id/resource_display_namefor Graph or Device Registration Service access right after, checksource.ip,source.geo.*, anduser_agent.originalfor automation (python-requests) or hosting/VPS ASNs (ROADtools/roadtx), and pivot onuser_idinazure.auditlogsfor 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
- Entra ID OAuth user_impersonation Scope for Unusual User and Client
- Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP
- Entra ID Device-Bound PRT from Unusual Device IP
- Entra ID Deviceless Windows Hello Sign-in Followed by Device Registration
- Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN