Skip to content

Commit 9aea98f

Browse files
terrancedejesusAegrah
terrancedejesus
and
Aegrah
authored
[New Rule] Entra ID Multiple Device Registrations by a Single User (#6350)
* [New Rule] Entra ID Multiple Device Registrations by a Single User * updating references * addressing feedback --------- Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
1 parent 4894e96 commit 9aea98f

1 file changed

Lines changed: 186 additions & 0 deletions

File tree

‎rules/integrations/azure/persistence_entra_id_multiple_device_registrations.toml‎

Lines changed: 186 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,186 @@
1+
[metadata]
2+
creation_date = "2026/06/26"
3+
integration = ["azure"]
4+
maturity = "production"
5+
updated_date = "2026/07/06"
6+
7+
[rule]
8+
author = ["Elastic"]
9+
description = """
10+
Detects multiple Microsoft Entra ID device registrations by a single user, where three or more distinct devices are
11+
registered within a 15-minute window. A legitimate user enrolling a device produces a single "Register device" event;
12+
registering multiple distinct devices in quick succession is uncommon and is the fingerprint behavior of
13+
adversary-in-the-middle (AiTM) phishing kits and stolen-token replay tooling (for example Kali365), which mint a new
14+
Azure AD-joined device, and therefore a new Primary Refresh Token (PRT), per relay or replay attempt. Each registered
15+
device is a separate certificate-bound principal whose PRT survives user-level session revocation and password resets,
16+
so multiple registrations on a single low-privilege identity establish device-bound persistence at scale.
17+
"""
18+
false_positives = [
19+
"""
20+
A user legitimately enrolling several devices in a short window (for example, a new laptop and phone during
21+
onboarding, or re-registering a device after a wipe) can produce three or more registrations. Validate against the
22+
user's device inventory and onboarding activity, and consider raising the threshold or tightening the window if
23+
benign multi-device enrollment is common in the environment.
24+
""",
25+
"""
26+
Bulk provisioning workflows, autopilot/MDM rollouts, or device-management tooling that registers devices on behalf
27+
of users may generate multiple registrations across many users at once. Suppress during planned rollout windows.
28+
""",
29+
]
30+
from = "now-30m"
31+
language = "esql"
32+
license = "Elastic License v2"
33+
name = "Entra ID Multiple Device Registrations by a Single User"
34+
note = """## Triage and analysis
35+
36+
### Investigating Entra ID Multiple Device Registrations by a Single User
37+
38+
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:
39+
40+
- 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).
41+
- Token-replay tooling driving multiple device joins in quick succession off a stolen refresh token or PRT.
42+
43+
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.
44+
45+
### Possible investigation steps
46+
47+
- 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.
48+
- 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.
49+
- 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.
50+
- 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.
51+
- 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.
52+
- 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.
53+
- Confirm with the user whether they performed a multi-device enrollment or onboarding action during the window.
54+
55+
### False positive analysis
56+
57+
- 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.
58+
- Bulk provisioning, autopilot, or MDM rollouts can register multiple devices per user concurrently. Consider suppression during planned rollouts.
59+
- If benign multi-device enrollment is routine in the environment, raise the distinct-device threshold or shorten the window.
60+
61+
### Response and remediation
62+
63+
- 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.
64+
- `GET /v1.0/users/{id}/registeredDevices` and `/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}` for each unrecognized device in the window.
65+
- Revoke refresh tokens and sessions, then reset credentials and re-register MFA.
66+
- `POST /v1.0/users/{id}/revokeSignInSessions`.
67+
- Temporarily disable the account if activity must be halted during investigation.
68+
- `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`.
69+
- Remove other attacker persistence established alongside the device joins: attacker-registered MFA methods, malicious inbox/forwarding rules, and OAuth consents.
70+
- 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).
71+
"""
72+
references = [
73+
"https://any.run/malware-trends/kali365/",
74+
"https://www.huntress.com/blog/kali365-device-code-phishing-kit",
75+
"https://www.ic3.gov/PSA/2026/PSA260521",
76+
"https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/"
77+
]
78+
risk_score = 47
79+
rule_id = "960b1cef-f94d-4150-863d-b1dc311739de"
80+
severity = "medium"
81+
tags = [
82+
"Domain: Cloud",
83+
"Domain: Identity",
84+
"Data Source: Azure",
85+
"Data Source: Microsoft Entra ID",
86+
"Data Source: Microsoft Entra ID Audit Logs",
87+
"Use Case: Identity and Access Audit",
88+
"Use Case: Threat Detection",
89+
"Tactic: Persistence",
90+
"Tactic: Initial Access",
91+
"Tactic: Credential Access",
92+
"Resources: Investigation Guide",
93+
]
94+
timestamp_override = "event.ingested"
95+
type = "esql"
96+
97+
query = '''
98+
from logs-azure.auditlogs-*
99+
| where data_stream.dataset == "azure.auditlogs"
100+
and azure.auditlogs.operation_name == "Register device"
101+
and azure.auditlogs.properties.initiated_by.user.userPrincipalName is not null
102+
// For "Register device" the registered device is the primary target resource (index 0);
103+
// target_resources is a numeric-indexed object array in this integration, so wildcard/name-based matching is not available.
104+
and `azure.auditlogs.properties.target_resources.0.display_name` is not null
105+
106+
| eval Esql.bucket_window = date_trunc(15 minutes, @timestamp)
107+
108+
| stats
109+
Esql.count_distinct_devices = count_distinct(`azure.auditlogs.properties.target_resources.0.display_name`),
110+
Esql.device_name_values = values(`azure.auditlogs.properties.target_resources.0.display_name`),
111+
Esql.user_agent_values = values(azure.auditlogs.properties.userAgent),
112+
Esql.source_ip_values = values(source.ip),
113+
Esql.source_as_number_values = values(source.`as`.number),
114+
Esql.source_as_organization_values = values(source.`as`.organization.name),
115+
Esql.source_country_values = values(source.geo.country_name),
116+
Esql.source_city_values = values(source.geo.city_name),
117+
Esql.source_region_values = values(source.geo.region_name),
118+
Esql.correlation_id_values = values(azure.correlation_id),
119+
Esql.timestamp_first_seen = min(@timestamp),
120+
Esql.timestamp_last_seen = max(@timestamp),
121+
Esql.event_count = count(*)
122+
by azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.bucket_window
123+
124+
| where Esql.count_distinct_devices >= 3
125+
126+
| keep azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.*
127+
'''
128+
129+
130+
[[rule.threat]]
131+
framework = "MITRE ATT&CK"
132+
[[rule.threat.technique]]
133+
id = "T1098"
134+
name = "Account Manipulation"
135+
reference = "https://attack.mitre.org/techniques/T1098/"
136+
[[rule.threat.technique.subtechnique]]
137+
id = "T1098.005"
138+
name = "Device Registration"
139+
reference = "https://attack.mitre.org/techniques/T1098/005/"
140+
141+
142+
143+
[rule.threat.tactic]
144+
id = "TA0003"
145+
name = "Persistence"
146+
reference = "https://attack.mitre.org/tactics/TA0003/"
147+
[[rule.threat]]
148+
framework = "MITRE ATT&CK"
149+
[[rule.threat.technique]]
150+
id = "T1078"
151+
name = "Valid Accounts"
152+
reference = "https://attack.mitre.org/techniques/T1078/"
153+
[[rule.threat.technique.subtechnique]]
154+
id = "T1078.004"
155+
name = "Cloud Accounts"
156+
reference = "https://attack.mitre.org/techniques/T1078/004/"
157+
158+
159+
160+
[rule.threat.tactic]
161+
id = "TA0001"
162+
name = "Initial Access"
163+
reference = "https://attack.mitre.org/tactics/TA0001/"
164+
[[rule.threat]]
165+
framework = "MITRE ATT&CK"
166+
[[rule.threat.technique]]
167+
id = "T1557"
168+
name = "Adversary-in-the-Middle"
169+
reference = "https://attack.mitre.org/techniques/T1557/"
170+
171+
172+
[rule.threat.tactic]
173+
id = "TA0006"
174+
name = "Credential Access"
175+
reference = "https://attack.mitre.org/tactics/TA0006/"
176+
177+
[rule.investigation_fields]
178+
field_names = [
179+
"azure.auditlogs.properties.initiated_by.user.userPrincipalName",
180+
"Esql.count_distinct_devices",
181+
"Esql.device_name_values",
182+
"Esql.user_agent_values",
183+
"Esql.source_ip_values",
184+
"Esql.source_as_organization_values",
185+
]
186+

0 commit comments

Comments
 (0)