Entra ID Windows Hello for Business Credential Registered

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Entra ID Windows Hello for Business Credential Registered

edit

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-*

Severity: low

Risk score: 21

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

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

Investigation guide

edit

Triage and analysis

Investigating Entra ID Windows Hello for Business Credential Registered

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.

Possible investigation steps

  • 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.

False positive analysis

  • 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.

Response and remediation

  • 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.

Setup

edit

Required Microsoft Entra ID Audit Logs

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

Rule query

edit
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&CKTM