Entra ID Multiple Device Registrations by a Single User

edit

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

Entra ID Multiple Device Registrations by a Single User

edit

Detects multiple Microsoft Entra ID device registrations by a single user, where three or more distinct devices are registered within a 15-minute window. A legitimate user enrolling a device produces a single "Register device" event; registering multiple distinct devices in quick succession is uncommon and is the fingerprint behavior of adversary-in-the-middle (AiTM) phishing kits and stolen-token replay tooling (for example Kali365), which mint a new Azure AD-joined device, and therefore a new Primary Refresh Token (PRT), per relay or replay attempt. Each registered device is a separate certificate-bound principal whose PRT survives user-level session revocation and password resets, so multiple registrations on a single low-privilege identity establish device-bound persistence at scale.

Rule type: esql

Rule indices: None

Severity: medium

Risk score: 47

Runs every: 5m

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

Maximum alerts per execution: 100

References:

Tags:

Domain: Cloud
Domain: Identity
Data Source: Azure
Data Source: Microsoft Entra ID
Data Source: Microsoft Entra ID Audit Logs
Use Case: Identity and Access Audit
Use Case: Threat Detection
Tactic: Persistence
Tactic: Initial Access
Tactic: Credential Access
Resources: Investigation Guide

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Entra ID Multiple Device Registrations by a Single User

A single Entra ID "Register device" event is routine: a user enrolling one device emits one registration. Concentrating three or more distinct device registrations onto one user inside a 15-minute window is uncommon for legitimate activity and is the fingerprint of either:

An AiTM phishing-kit relay session that, after capturing the victim’s sign-in, registers one or more Azure AD-joined devices of its own from the kit infrastructure within minutes (observed cadence of roughly one device every 2-6 minutes, e.g. Kali365 registering five devices in ~12 minutes).
Token-replay tooling driving multiple device joins in quick succession off a stolen refresh token or PRT.

Each registered device is a separate principal with its own certificate-bound PRT. Because user-level controls (revokeSignInSessions, password reset) do not invalidate device-bound PRTs, every device left in place is an independent, persistent foothold.

Possible investigation steps

Identify the user (azure.auditlogs.properties.initiated_by.user.userPrincipalName) and review the registered devices in Esql.device_name_values. Tool-driven joins frequently use default Windows-style names such as DESKTOP-<6 alphanumeric> and a homogeneous, hardcoded OS build.
Inspect Esql.user_agent_values from the Register device events. A spoofed Windows device-registration client string (Dsreg/10.0 (Windows <build>)) or a raw HTTP client (axios/*, python-requests/*, Microsoft.OData.Client/*) instead of a genuine browser/endpoint user agent is high-fidelity tooling.
Pivot to the paired Add device events for each device (correlate via azure.correlation_id) and review the modified properties: DeviceOSType, DeviceOSVersion/CloudDeviceOSVersion, and DeviceTrustType. A DeviceTrustType of AzureAd (full join) on a low-privilege user, and an identical hardcoded OS build across all devices in the window, are strong indicators.
Review the origin surfaced on the alert: Esql.source_ip_values, Esql.source_as_number_values, Esql.source_as_organization_values, and Esql.source_country_values/Esql.source_city_values/Esql.source_region_values. Hosting/VPS ASNs (for example Tencent, Alibaba, or other cloud providers) and unexpected geographies for a device-registration event are high-fidelity suspicious. A single source IP/ASN across every registration in the window is consistent with one piece of kit infrastructure driving the joins.
Cross-reference logs-azure.signinlogs-* for the same user around the registration window. The registrations are brokered through the Microsoft Authentication Broker application against the Device Registration Service resource; confirm whether the broker was subsequently used to mint tokens for other resources (for example Microsoft Graph) from the same source.
Cross-reference logs-azure.auditlogs-* for a security-info / MFA method registration (User registered security info) by the same user near the registration window; AiTM kits commonly plant their own MFA method alongside the device persistence.
Confirm with the user whether they performed a multi-device enrollment or onboarding action during the window.

False positive analysis

New-device or onboarding flows where a user enrolls three or more devices in a short window can fire. Validate against the user’s known device inventory and any onboarding or device-refresh events.
Bulk provisioning, autopilot, or MDM rollouts can register multiple devices per user concurrently. Consider suppression during planned rollouts.
If benign multi-device enrollment is routine in the environment, raise the distinct-device threshold or shorten the window.

Response and remediation

Treat as likely AiTM compromise or token replay until proven otherwise. Remove the rogue device registrations BEFORE revoking sessions, because device-bound PRTs survive revokeSignInSessions and a device left in place re-establishes access.
GET /v1.0/users/{id}/registeredDevices and /ownedDevices, then DELETE /v1.0/devices/{deviceObjectId} for each unrecognized device in the window.
Revoke refresh tokens and sessions, then reset credentials and re-register MFA.
POST /v1.0/users/{id}/revokeSignInSessions.
Temporarily disable the account if activity must be halted during investigation.
PATCH /v1.0/users/{id} with body {"accountEnabled": false}.
Remove other attacker persistence established alongside the device joins: attacker-registered MFA methods, malicious inbox/forwarding rules, and OAuth consents.
Hunt for the same device-name pattern, OS build, and registration user agent across other users and tenants, and apply Conditional Access to restrict device registration (require a compliant/managed device or trusted network).

Rule query

edit

from logs-azure.auditlogs-*
| where data_stream.dataset == "azure.auditlogs"
    and azure.auditlogs.operation_name == "Register device"
    and azure.auditlogs.properties.initiated_by.user.userPrincipalName is not null
    // For "Register device" the registered device is the primary target resource (index 0);
    // target_resources is a numeric-indexed object array in this integration, so wildcard/name-based matching is not available.
    and `azure.auditlogs.properties.target_resources.0.display_name` is not null

| eval Esql.bucket_window = date_trunc(15 minutes, @timestamp)

| stats
    Esql.count_distinct_devices = count_distinct(`azure.auditlogs.properties.target_resources.0.display_name`),
    Esql.device_name_values = values(`azure.auditlogs.properties.target_resources.0.display_name`),
    Esql.user_agent_values = values(azure.auditlogs.properties.userAgent),
    Esql.source_ip_values = values(source.ip),
    Esql.source_as_number_values = values(source.`as`.number),
    Esql.source_as_organization_values = values(source.`as`.organization.name),
    Esql.source_country_values = values(source.geo.country_name),
    Esql.source_city_values = values(source.geo.city_name),
    Esql.source_region_values = values(source.geo.region_name),
    Esql.correlation_id_values = values(azure.correlation_id),
    Esql.timestamp_first_seen = min(@timestamp),
    Esql.timestamp_last_seen = max(@timestamp),
    Esql.event_count = count(*)
    by azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.bucket_window

| where Esql.count_distinct_devices >= 3

| keep azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.*

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Persistence
- ID: TA0003
- Reference URL: https://attack.mitre.org/tactics/TA0003/
Technique:
- Name: Account Manipulation
- ID: T1098
- Reference URL: https://attack.mitre.org/techniques/T1098/
Sub-technique:
- Name: Device Registration
- ID: T1098.005
- Reference URL: https://attack.mitre.org/techniques/T1098/005/
Tactic:
- Name: Initial Access
- ID: TA0001
- Reference URL: https://attack.mitre.org/tactics/TA0001/
Technique:
- Name: Valid Accounts
- ID: T1078
- Reference URL: https://attack.mitre.org/techniques/T1078/
Sub-technique:
- Name: Cloud Accounts
- ID: T1078.004
- Reference URL: https://attack.mitre.org/techniques/T1078/004/
Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
Technique:
- Name: Adversary-in-the-Middle
- ID: T1557
- Reference URL: https://attack.mitre.org/techniques/T1557/

« Entra ID Microsoft Authentication Broker Sign-In with Non-Standard User Agent Entra ID OAuth Application Redirect URI Modified »