Suspicious ADRS Token Request by Microsoft Auth Broker
Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session.
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 suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker
11(29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service
12(01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the
13authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This
14behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary
15Refresh Token (PRT) or establishing a trusted session.
16"""
17from = "now-9m"
18index = ["filebeat-*", "logs-azure.signinlogs-*"]
19language = "kuery"
20license = "Elastic License v2"
21name = "Suspicious ADRS Token Request by Microsoft Auth Broker"
22note = """## Triage and analysis
23
24### Investigating Suspicious ADRS Token Request by Microsoft Auth Broker
25
26Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session.
27
28### Possible investigation steps
29- Identify the user principal associated with the request by checking `azure.signinlogs.properties.user_principal_name` or `azure.signinlogs.properties.user_id`.
30- Review the `azure.signinlogs.properties.app_id` and `azure.signinlogs.properties.resource_id` to confirm the request is made by the Microsoft Authentication Broker and targeting the Device Registration Service.
31- Examine the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` for the presence of `adrs_access`, indicating an attempt to access ADRS.
32- Check the `azure.signinlogs.properties.incoming_token_type` to confirm the request is made using a refresh token, which is typical for persistent access scenarios.
33- Review the `azure.signinlogs.properties.user_type` to ensure it is a "Member" user, as this behavior is unusual for standard user accounts.
34- Review the `source.address` and `source.geo.country_name` to identify the origin of the request. Look for any anomalies or unexpected locations.
35- Check the `azure.signinlogs.properties.device_detail.operating_system` and `azure.signinlogs.properties.device_detail.browser` to identify the device and browser used for the request. Look for any unusual or unexpected devices for this user.
36- Use the `azure.signinlogs.properties.session_id` to correlate this request with other sign-in events for the same user. Look for any patterns of suspicious activity or multiple requests in a short time frame.
37- Correlate with Entra ID audit logs to identify any recent device registrations or changes to the user's device registration status.
38- Pivot to primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse or unauthorized access attempts.
39
40### False positive analysis
41- Legitimate applications or services that require access to the Device Registration Service may trigger this rule. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user accounts.
42- Users being onboarded or enrolled in new devices may also trigger this rule, especially if they are using the Microsoft Authentication Broker for the first time.
43
44### Response and remediation
45- If the request is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access.
46- Disable the user account temporarily to prevent any potential compromise or unauthorized access.
47- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access.
48- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user.
49- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources.
50- Consider deactivating any newly registered devices associated with the user account until further investigation is complete.
51"""
52references = [
53 "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
54]
55risk_score = 47
56rule_id = "d121f0a8-4875-11f0-bb2b-f661ea17fbcd"
57severity = "medium"
58tags = [
59 "Domain: Cloud",
60 "Domain: Identity",
61 "Data Source: Azure",
62 "Data Source: Microsoft Entra ID",
63 "Data Source: Microsoft Entra ID Sign-In Logs",
64 "Use Case: Identity and Access Audit",
65 "Tactic: Persistence",
66 "Resources: Investigation Guide",
67]
68timestamp_override = "event.ingested"
69type = "query"
70
71query = '''
72event.dataset: "azure.signinlogs" and
73 azure.signinlogs.properties.app_id : "29d9ed98-a469-4536-ade2-f981bc1d605e" and
74 azure.signinlogs.properties.resource_id : "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" and
75 azure.signinlogs.category: "NonInteractiveUserSignInLogs" and
76 azure.signinlogs.properties.authentication_processing_details: *adrs_access* and
77 azure.signinlogs.properties.incoming_token_type: "refreshToken" and
78 azure.signinlogs.properties.user_type: "Member"
79'''
80
81
82[[rule.threat]]
83framework = "MITRE ATT&CK"
84[[rule.threat.technique]]
85id = "T1098"
86name = "Account Manipulation"
87reference = "https://attack.mitre.org/techniques/T1098/"
88[[rule.threat.technique.subtechnique]]
89id = "T1098.005"
90name = "Device Registration"
91reference = "https://attack.mitre.org/techniques/T1098/005/"
92
93
94
95[rule.threat.tactic]
96id = "TA0003"
97name = "Persistence"
98reference = "https://attack.mitre.org/tactics/TA0003/"
Triage and analysis
Investigating Suspicious ADRS Token Request by Microsoft Auth Broker
Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session.
Possible investigation steps
- Identify the user principal associated with the request by checking
azure.signinlogs.properties.user_principal_name
orazure.signinlogs.properties.user_id
. - Review the
azure.signinlogs.properties.app_id
andazure.signinlogs.properties.resource_id
to confirm the request is made by the Microsoft Authentication Broker and targeting the Device Registration Service. - Examine the
azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info
for the presence ofadrs_access
, indicating an attempt to access ADRS. - Check the
azure.signinlogs.properties.incoming_token_type
to confirm the request is made using a refresh token, which is typical for persistent access scenarios. - Review the
azure.signinlogs.properties.user_type
to ensure it is a "Member" user, as this behavior is unusual for standard user accounts. - Review the
source.address
andsource.geo.country_name
to identify the origin of the request. Look for any anomalies or unexpected locations. - Check the
azure.signinlogs.properties.device_detail.operating_system
andazure.signinlogs.properties.device_detail.browser
to identify the device and browser used for the request. Look for any unusual or unexpected devices for this user. - Use the
azure.signinlogs.properties.session_id
to correlate this request with other sign-in events for the same user. Look for any patterns of suspicious activity or multiple requests in a short time frame. - Correlate with Entra ID audit logs to identify any recent device registrations or changes to the user's device registration status.
- Pivot to primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse or unauthorized access attempts.
False positive analysis
- Legitimate applications or services that require access to the Device Registration Service may trigger this rule. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user accounts.
- Users being onboarded or enrolled in new devices may also trigger this rule, especially if they are using the Microsoft Authentication Broker for the first time.
Response and remediation
- If the request is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access.
- Disable the user account temporarily to prevent any potential compromise or unauthorized access.
- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access.
- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user.
- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources.
- Consider deactivating any newly registered devices associated with the user account until further investigation is complete.
References
Related rules
- Entra ID User Signed In from Unusual Device
- Microsoft Entra ID Service Principal Credentials Added by Rare User
- Microsoft Entra ID Service Principal Created
- Microsoft Entra ID Conditional Access Policy (CAP) Modified
- BloodHound Suite User-Agents Detected