Microsoft Entra ID Suspicious Cloud Device Registration
Detects a sequence of events in Microsoft Entra ID indicative of a suspicious cloud-based device registration,
potentially using ROADtools. This behavior involves adding a device via the Device Registration Service, followed by the
assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or
acquire a Primary Refresh Token (PRT). ROADtools, a popular red team toolkit, often leaves distinct telemetry signatures
such as the Microsoft.OData.Client
user agent and specific OS version values. These sequences are uncommon in typical
user behavior and may reflect abuse of device trust for session hijacking or silent token replay.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/06/13"
3integration = ["azure"]
4maturity = "production"
5updated_date = "2025/06/13"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects a sequence of events in Microsoft Entra ID indicative of a suspicious cloud-based device registration,
11potentially using ROADtools. This behavior involves adding a device via the Device Registration Service, followed by the
12assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or
13acquire a Primary Refresh Token (PRT). ROADtools, a popular red team toolkit, often leaves distinct telemetry signatures
14such as the `Microsoft.OData.Client` user agent and specific OS version values. These sequences are uncommon in typical
15user behavior and may reflect abuse of device trust for session hijacking or silent token replay.
16"""
17from = "now-9m"
18index = ["filebeat-*", "logs-azure.auditlogs-*"]
19language = "eql"
20license = "Elastic License v2"
21name = "Microsoft Entra ID Suspicious Cloud Device Registration"
22note = """## Triage and analysis
23
24### Investigating Microsoft Entra ID Suspicious Cloud Device Registration
25
26This rule detects a sequence of Microsoft Entra ID audit events consistent with cloud device registration abuse via ROADtools or similar automation. The activity includes three correlated events:
27
281. Add device operation from the Device Registration Service using a `Microsoft.OData.Client/*` user-agent and a known Windows OS version.
292. Addition of a registered user with an `enterprise registration` URN.
303. Assignment of a registered owner to the device.
31
32This pattern has been observed in OAuth phishing and PRT abuse campaigns where adversaries silently register a cloud device to obtain persistent, trusted access.
33
34### Possible investigation steps
35
36- Identify the user principal associated with the device registration.
37- Review the `azure.auditlogs.identity` field to confirm the Device Registration Service initiated the request.
38- Check for the presence of the `Microsoft.OData.Client/*` user-agent in `azure.auditlogs.properties.additional_details.value`, as this is common in ROADtools usage.
39- Confirm the OS version seen in the modified properties is expected (e.g., `10.0.19041.928`), or investigate unexpected versions.
40- Examine the URN in the new value field (`urn:ms-drs:enterpriseregistration.windows.net`) to verify it's not being misused.
41- Use `azure.correlation_id` to pivot across all three steps of the registration flow.
42- Pivot to `azure.signinlogs` to detect follow-on activity using the new device, such as sign-ins involving refresh or primary refresh tokens.
43- Look for signs of persistence or lateral movement enabled by the newly registered device.
44- Identify the registered device name by reviewing `azure.auditlogs.properties.target_resources.0.display_name` and confirm it's expected for the user or organization.
45- Use the correlation ID `azure.correlation_id` to pivot into registered user events from Entra ID audit logs and check `azure.auditlogs.properties.target_resources.0.user_principal_name` to identify the user associated with the device registration.
46- Review any activity for this user from Entra ID sign-in logs, where the incoming token type is a `primaryRefreshToken`.
47
48### False positive analysis
49
50- Some MDM or autopilot provisioning flows may generate similar sequences. Validate against known provisioning tools, expected rollout windows, and device inventory.
51- Investigate whether the device name, OS version, and registration details align with normal IT workflows.
52
53### Response and remediation
54
55- If confirmed malicious, remove the registered device from Entra ID.
56- Revoke refresh tokens and primary refresh tokens associated with the user and device.
57- Disable the user account and initiate password reset and identity verification procedures.
58- Review audit logs and sign-in activity for additional indicators of persistence or access from the rogue device.
59- Tighten conditional access policies to restrict device registration and enforce compliance or hybrid join requirements.
60"""
61references = [
62 "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
63 "https://github.com/dirkjanm/ROADtools",
64]
65risk_score = 47
66rule_id = "90efea04-5675-11f0-8f80-f661ea17fbcd"
67severity = "medium"
68tags = [
69 "Domain: Cloud",
70 "Domain: Identity",
71 "Data Source: Azure",
72 "Data Source: Microsoft Entra ID",
73 "Data Source: Microsoft Entra ID Audit Logs",
74 "Use Case: Identity and Access Audit",
75 "Tactic: Persistence",
76 "Resources: Investigation Guide",
77]
78timestamp_override = "event.ingested"
79type = "eql"
80
81query = '''
82sequence by azure.correlation_id with maxspan=1m
83[any where event.dataset == "azure.auditlogs" and
84 azure.auditlogs.identity == "Device Registration Service" and
85 azure.auditlogs.operation_name == "Add device" and
86 azure.auditlogs.properties.additional_details.value like "Microsoft.OData.Client/*" and (
87 `azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name` == "CloudAccountEnabled" and
88 `azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value` == "[true]"
89 ) and
90 `azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value` like "*10.0.19041.928*"]
91[any where event.dataset == "azure.auditlogs" and
92 azure.auditlogs.operation_name == "Add registered users to device" and
93 `azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value` like "*urn:ms-drs:enterpriseregistration.windows.net*"]
94[any where event.dataset == "azure.auditlogs" and
95 azure.auditlogs.operation_name == "Add registered owner to device"]
96'''
97
98
99[[rule.threat]]
100framework = "MITRE ATT&CK"
101[[rule.threat.technique]]
102id = "T1098"
103name = "Account Manipulation"
104reference = "https://attack.mitre.org/techniques/T1098/"
105[[rule.threat.technique.subtechnique]]
106id = "T1098.005"
107name = "Device Registration"
108reference = "https://attack.mitre.org/techniques/T1098/005/"
109
110
111
112[rule.threat.tactic]
113id = "TA0003"
114name = "Persistence"
115reference = "https://attack.mitre.org/tactics/TA0003/"
Triage and analysis
Investigating Microsoft Entra ID Suspicious Cloud Device Registration
This rule detects a sequence of Microsoft Entra ID audit events consistent with cloud device registration abuse via ROADtools or similar automation. The activity includes three correlated events:
- Add device operation from the Device Registration Service using a
Microsoft.OData.Client/*
user-agent and a known Windows OS version. - Addition of a registered user with an
enterprise registration
URN. - Assignment of a registered owner to the device.
This pattern has been observed in OAuth phishing and PRT abuse campaigns where adversaries silently register a cloud device to obtain persistent, trusted access.
Possible investigation steps
- Identify the user principal associated with the device registration.
- Review the
azure.auditlogs.identity
field to confirm the Device Registration Service initiated the request. - Check for the presence of the
Microsoft.OData.Client/*
user-agent inazure.auditlogs.properties.additional_details.value
, as this is common in ROADtools usage. - Confirm the OS version seen in the modified properties is expected (e.g.,
10.0.19041.928
), or investigate unexpected versions. - Examine the URN in the new value field (
urn:ms-drs:enterpriseregistration.windows.net
) to verify it's not being misused. - Use
azure.correlation_id
to pivot across all three steps of the registration flow. - Pivot to
azure.signinlogs
to detect follow-on activity using the new device, such as sign-ins involving refresh or primary refresh tokens. - Look for signs of persistence or lateral movement enabled by the newly registered device.
- Identify the registered device name by reviewing
azure.auditlogs.properties.target_resources.0.display_name
and confirm it's expected for the user or organization. - Use the correlation ID
azure.correlation_id
to pivot into registered user events from Entra ID audit logs and checkazure.auditlogs.properties.target_resources.0.user_principal_name
to identify the user associated with the device registration. - Review any activity for this user from Entra ID sign-in logs, where the incoming token type is a
primaryRefreshToken
.
False positive analysis
- Some MDM or autopilot provisioning flows may generate similar sequences. Validate against known provisioning tools, expected rollout windows, and device inventory.
- Investigate whether the device name, OS version, and registration details align with normal IT workflows.
Response and remediation
- If confirmed malicious, remove the registered device from Entra ID.
- Revoke refresh tokens and primary refresh tokens associated with the user and device.
- Disable the user account and initiate password reset and identity verification procedures.
- Review audit logs and sign-in activity for additional indicators of persistence or access from the rogue device.
- Tighten conditional access policies to restrict device registration and enforce compliance or hybrid join requirements.
References
Related rules
- Suspicious ADRS Token Request by Microsoft Auth Broker
- Microsoft Entra ID Service Principal Credentials Added by Rare User
- Microsoft Entra ID Service Principal Created
- Microsoft Entra ID Conditional Access Policy (CAP) Modified
- Entra ID RT to PRT Transition from Same User and Device