Entra ID OAuth PRT Issuance to Non-Managed Device Detected
Identifies when a user signs in with a refresh token using the Microsoft Authentication Broker (MAB) client, followed by a Primary Refresh Token (PRT) sign-in from the same device within 1 hour from an unmanaged device. This pattern may indicate that an attacker has successfully registered a device using ROADtx and transitioned from short-term token access to long-term persistent access via PRTs. Excluding access to the Device Registration Service (DRS) ensures the PRT is being used beyond registration, often to access Microsoft 365 resources like Outlook or SharePoint.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/06/24"
3integration = ["azure"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies when a user signs in with a refresh token using the Microsoft Authentication Broker (MAB) client, followed by
11a Primary Refresh Token (PRT) sign-in from the same device within 1 hour from an unmanaged device. This pattern may indicate that an attacker has
12successfully registered a device using ROADtx and transitioned from short-term token access to long-term persistent
13access via PRTs. Excluding access to the Device Registration Service (DRS) ensures the PRT is being used beyond
14registration, often to access Microsoft 365 resources like Outlook or SharePoint.
15"""
16from = "now-60m"
17index = ["filebeat-*", "logs-azure.signinlogs-*"]
18interval = "30m"
19language = "eql"
20license = "Elastic License v2"
21name = "Entra ID OAuth PRT Issuance to Non-Managed Device Detected"
22note = """## Triage and analysis
23
24### Investigating Entra ID OAuth PRT Issuance to Non-Managed Device Detected
25
26This rule identifies a sequence where a Microsoft Entra ID authenticates using a refresh token issued to the Microsoft Authentication Broker (MAB), followed by an authentication using a Primary Refresh Token (PRT) from the same unmanaged device. This behavior is uncommon for normal user activity and strongly suggests adversarial behavior, particularly when paired with OAuth phishing and device registration tools like ROADtx. The use of PRT shortly after a refresh token sign-in typically indicates the attacker has registered a virtual device and is now using the PRT to impersonate a registered user+device pair. The device in question is still marked as unmanaged, indicating it is not compliant with organizational policies and managed by Intune or other MDM solutions.
27
28### Possible investigation steps
29- Identify the user principal and device from `azure.signinlogs.properties.user_principal_name` and `azure.signinlogs.properties.device_detail.device_id`.
30- Confirm the first sign-in event came from the Microsoft Auth Broker (`app_id`) with `incoming_token_type: refreshToken`.
31- Ensure the device has a `trust_type` of "Azure AD joined" and that the `sign_in_session_status` is "unbound".
32- Confirm the second sign-in used `incoming_token_type: primaryRefreshToken` and that the `resource_display_name` is not "Device Registration Service".
33- Investigate any Microsoft Graph, Outlook, or SharePoint access occurring shortly after.
34- Review conditional access policy outcomes and determine whether MFA or device compliance was bypassed.
35
36### False positive analysis
37- Legitimate device onboarding and sign-ins using hybrid-joined endpoints may trigger this rule.
38- Rapid device provisioning in enterprise environments using MAB could generate similar token behavior.
39- Use supporting signals, such as IP address changes, geolocation, or user agent anomalies, to reduce noise.
40
41### Response and remediation
42- Investigate other sign-in patterns and assess whether token abuse has occurred.
43- Revoke PRT sessions via Microsoft Entra ID or Conditional Access.
44- Remove or quarantine the suspicious device registration.
45- Require password reset and enforce MFA.
46- Audit and tighten device trust and conditional access configurations.
47"""
48references = [
49 "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
50 "https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/",
51]
52risk_score = 47
53rule_id = "40e60816-5122-11f0-9caa-f661ea17fbcd"
54severity = "medium"
55tags = [
56 "Domain: Cloud",
57 "Domain: Identity",
58 "Use Case: Threat Detection",
59 "Data Source: Azure",
60 "Data Source: Microsoft Entra ID",
61 "Data Source: Microsoft Entra ID Sign-In Logs",
62 "Tactic: Persistence",
63 "Tactic: Initial Access",
64 "Resources: Investigation Guide",
65 "Noise: Medium",
66 "Performance: Fast",
67 "Profile: Recommended",
68 "Threat: Device Code Phishing",
69 "Rule Type: Event Correlation (EQL)",
70 "Platform: Entra ID",
71]
72timestamp_override = "event.ingested"
73type = "eql"
74
75query = '''
76sequence by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id with maxspan=1h
77 [authentication where
78 data_stream.dataset == "azure.signinlogs" and
79 azure.signinlogs.category == "NonInteractiveUserSignInLogs" and
80 azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and
81 azure.signinlogs.properties.incoming_token_type == "refreshToken" and
82 azure.signinlogs.properties.device_detail.trust_type == "Azure AD joined" and
83 azure.signinlogs.properties.device_detail.device_id != null and
84 azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and
85 azure.signinlogs.properties.user_type == "Member" and
86 azure.signinlogs.result_signature == "SUCCESS"
87 ]
88 [authentication where
89 data_stream.dataset == "azure.signinlogs" and
90 azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and
91 azure.signinlogs.properties.resource_display_name != "Device Registration Service" and
92 azure.signinlogs.result_signature == "SUCCESS" and
93 azure.signinlogs.properties.device_detail.is_managed != true
94 and not (
95 azure.signinlogs.properties.app_display_name == "Windows Sign In" or
96 user_agent.original == "Windows-AzureAD-Authentication-Provider/1.0"
97 )
98 ]
99'''
100
101[rule.investigation_fields]
102field_names = [
103 "azure.signinlogs.properties.user_principal_name",
104 "azure.signinlogs.properties.device_detail.device_id",
105 "azure.signinlogs.properties.incoming_token_type",
106 "azure.signinlogs.properties.resource_display_name",
107 "azure.signinlogs.properties.token_protection_status_details.sign_in_session_status",
108 "azure.signinlogs.properties.app_id",
109 "azure.signinlogs.properties.device_detail.trust_type",
110 "source.geo.country_name",
111 "source.geo.city_name",
112 "source.address",
113 "event.outcome",
114 "event.category",
115]
116
117[[rule.threat]]
118framework = "MITRE ATT&CK"
119
120[[rule.threat.technique]]
121id = "T1078"
122name = "Valid Accounts"
123reference = "https://attack.mitre.org/techniques/T1078/"
124
125[[rule.threat.technique.subtechnique]]
126id = "T1078.004"
127name = "Cloud Accounts"
128reference = "https://attack.mitre.org/techniques/T1078/004/"
129
130[[rule.threat.technique]]
131id = "T1098"
132name = "Account Manipulation"
133reference = "https://attack.mitre.org/techniques/T1098/"
134
135[[rule.threat.technique.subtechnique]]
136id = "T1098.005"
137name = "Device Registration"
138reference = "https://attack.mitre.org/techniques/T1098/005/"
139
140[rule.threat.tactic]
141id = "TA0003"
142name = "Persistence"
143reference = "https://attack.mitre.org/tactics/TA0003/"
144
145[[rule.threat]]
146framework = "MITRE ATT&CK"
147
148[[rule.threat.technique]]
149id = "T1528"
150name = "Steal Application Access Token"
151reference = "https://attack.mitre.org/techniques/T1528/"
152
153[rule.threat.tactic]
154id = "TA0006"
155name = "Credential Access"
156reference = "https://attack.mitre.org/tactics/TA0006/"
157
158[[rule.threat]]
159framework = "MITRE ATT&CK"
160
161[rule.threat.tactic]
162id = "TA0001"
163name = "Initial Access"
164reference = "https://attack.mitre.org/tactics/TA0001/"
165
166[[rule.threat]]
167framework = "MITRE ATT&CK"
168
169[[rule.threat.technique]]
170id = "T1550"
171name = "Use Alternate Authentication Material"
172reference = "https://attack.mitre.org/techniques/T1550/"
173
174[[rule.threat.technique.subtechnique]]
175id = "T1550.001"
176name = "Application Access Token"
177reference = "https://attack.mitre.org/techniques/T1550/001/"
178
179[rule.threat.tactic]
180id = "TA0005"
181name = "Defense Evasion"
182reference = "https://attack.mitre.org/tactics/TA0005/"
Triage and analysis
Investigating Entra ID OAuth PRT Issuance to Non-Managed Device Detected
This rule identifies a sequence where a Microsoft Entra ID authenticates using a refresh token issued to the Microsoft Authentication Broker (MAB), followed by an authentication using a Primary Refresh Token (PRT) from the same unmanaged device. This behavior is uncommon for normal user activity and strongly suggests adversarial behavior, particularly when paired with OAuth phishing and device registration tools like ROADtx. The use of PRT shortly after a refresh token sign-in typically indicates the attacker has registered a virtual device and is now using the PRT to impersonate a registered user+device pair. The device in question is still marked as unmanaged, indicating it is not compliant with organizational policies and managed by Intune or other MDM solutions.
Possible investigation steps
- Identify the user principal and device from
azure.signinlogs.properties.user_principal_nameandazure.signinlogs.properties.device_detail.device_id. - Confirm the first sign-in event came from the Microsoft Auth Broker (
app_id) withincoming_token_type: refreshToken. - Ensure the device has a
trust_typeof "Azure AD joined" and that thesign_in_session_statusis "unbound". - Confirm the second sign-in used
incoming_token_type: primaryRefreshTokenand that theresource_display_nameis not "Device Registration Service". - Investigate any Microsoft Graph, Outlook, or SharePoint access occurring shortly after.
- Review conditional access policy outcomes and determine whether MFA or device compliance was bypassed.
False positive analysis
- Legitimate device onboarding and sign-ins using hybrid-joined endpoints may trigger this rule.
- Rapid device provisioning in enterprise environments using MAB could generate similar token behavior.
- Use supporting signals, such as IP address changes, geolocation, or user agent anomalies, to reduce noise.
Response and remediation
- Investigate other sign-in patterns and assess whether token abuse has occurred.
- Revoke PRT sessions via Microsoft Entra ID or Conditional Access.
- Remove or quarantine the suspicious device registration.
- Require password reset and enforce MFA.
- Audit and tighten device trust and conditional access configurations.
References
Related rules
- Entra ID OAuth Device Code Sign-in to Azure AD Graph Enumeration
- Azure Service Principal Sign-In Followed by Arc Cluster Credential Access
- Entra ID ADRS Token Request by Microsoft Authentication Broker
- Entra ID AiTM Phishing-Kit Chain Detected
- Entra ID Microsoft Authentication Broker DRS Sign-In from Suspicious ASN