Entra ID Windows Hello for Business Credential Registered

Identifies the first-seen registration of a Windows Hello for Business (WHfB) credential for a Microsoft Entra ID user from a given source ASN in a tenant, based on a prefixed historic window. Enrollment is commonly part of legitimate onboarding or passwordless rollout and is not inherently malicious. Adversaries who have obtained a token that satisfies fresh (NGC) multi-factor authentication, for example by borrowing an existing WHfB key or passkey, can also enroll their own WHfB credential to establish durable, phishing-resistant persistence that survives password resets and standard session revocation. Correlate first-seen enrollments with the sign-in and device state that preceded them.

Rule type: new_terms
Rule indices:

  • logs-azure.auditlogs-*

Rule Severity: low
Risk Score: 21
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Cloud
  • Domain: Identity
  • Platform: Entra ID
  • Use Case: Identity and Access Audit
  • Use Case: Threat Detection
  • Tactic: Persistence
  • Rule Type: New Terms
  • Data Source: Azure
  • Data Source: Microsoft Entra ID
  • Data Source: Microsoft Entra ID Audit Logs
  • Resources: Investigation Guide

Version: 1
Rule authors:

  • Elastic

Rule license: Elastic License v2

This rule requires the Azure integration with Microsoft Entra ID Audit logs enabled and collected via Azure Event Hub.

This is a first-seen (new_terms) signal: a WHfB credential was registered for a tenant/user/source-ASN combination not observed in the prior 14 days. Enrollment is often legitimate onboarding, but adversaries abuse the same action as persistence - after borrowing an existing WHfB key or passkey to satisfy fresh MFA, they enroll their own credential, which survives password resets and ordinary session revocation.

  • Identify the target (target_resources.0.user_principal_name) and initiator (initiated_by.user.userPrincipalName), confirm whether WHfB enrollment was expected, and check whether the source ASN is new for that user.
  • Correlate with azure.signinlogs shortly before for a deviceless WHfB/passkey sign-in, device-code flow, or attacker device registration/PRT issuance; an additional credential from a new ASN on an established account is more suspicious. Examine the preceding sign-in's source IP/geo and user agent for automation or hosting/VPS origins.
  • First-time WHfB enrollment during onboarding/passwordless rollout is expected; repeat enrollments from the same tenant/user/ASN within 14 days don't fire.
  • Users traveling or switching ISP/VPN may appear as a new ASN - validate against known networks before treating as suspicious.
  • If unauthorized, delete the WHfB credential and any attacker-registered device via Graph or the Entra portal, revoke sessions and refresh tokens (delete devices first, to break device-bound PRT persistence), reset credentials, and re-enroll from a trusted device.
  • Review the sign-in that authorized the enrollment to determine the initial access vector.
data_stream.dataset: "azure.auditlogs" and
    azure.auditlogs.operation_name: "Add Windows Hello for Business credential" and
    event.outcome: ("Success" or "success") and
    azure.tenant_id: * and
    azure.auditlogs.properties.initiated_by.user.userPrincipalName: * and
    source.as.number: *

Framework: MITRE ATT&CK