Entra ID RT to PRT Transition from Same User and Device

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. 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 = "2025/06/24"
  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. 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 RT to PRT Transition from Same User and Device"
 22note = """## Triage and analysis
 23
 24### Investigating Entra ID RT to PRT Transition from Same User and Device
 25
 26This rule identifies a sequence where a Microsoft Entra ID user signs in using a refresh token issued to the Microsoft Authentication Broker (MAB), followed by a sign-in using a Primary Refresh Token (PRT) from the same 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 obtained device trust and is now using the PRT to impersonate a fully compliant user+device pair.
 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]
 66timestamp_override = "event.ingested"
 67type = "eql"
 68
 69query = '''
 70sequence by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id with maxspan=1h
 71  [authentication where
 72    event.dataset == "azure.signinlogs" and
 73    azure.signinlogs.category == "NonInteractiveUserSignInLogs" and
 74    azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and
 75    azure.signinlogs.properties.incoming_token_type == "refreshToken" and
 76    azure.signinlogs.properties.device_detail.trust_type == "Azure AD joined" and
 77    azure.signinlogs.properties.device_detail.device_id != null and
 78    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and
 79    azure.signinlogs.properties.user_type == "Member" and
 80    azure.signinlogs.result_signature == "SUCCESS"
 81  ]
 82  [authentication where
 83    event.dataset == "azure.signinlogs" and
 84    azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and
 85    azure.signinlogs.properties.resource_display_name != "Device Registration Service" and
 86    azure.signinlogs.result_signature == "SUCCESS"
 87  ]
 88'''
 89
 90[rule.investigation_fields]
 91field_names = [
 92    "azure.signinlogs.properties.user_principal_name",
 93    "azure.signinlogs.properties.device_detail.device_id",
 94    "azure.signinlogs.properties.incoming_token_type",
 95    "azure.signinlogs.properties.resource_display_name",
 96    "azure.signinlogs.properties.token_protection_status_details.sign_in_session_status",
 97    "azure.signinlogs.properties.app_id",
 98    "azure.signinlogs.properties.device_detail.trust_type",
 99    "source.geo.country_name",
100    "source.geo.city_name",
101    "source.address",
102    "event.outcome",
103    "event.category",
104]
105
106[[rule.threat]]
107framework = "MITRE ATT&CK"
108[[rule.threat.technique]]
109id = "T1078"
110name = "Valid Accounts"
111reference = "https://attack.mitre.org/techniques/T1078/"
112[[rule.threat.technique.subtechnique]]
113id = "T1078.004"
114name = "Cloud Accounts"
115reference = "https://attack.mitre.org/techniques/T1078/004/"
116
117
118[[rule.threat.technique]]
119id = "T1098"
120name = "Account Manipulation"
121reference = "https://attack.mitre.org/techniques/T1098/"
122[[rule.threat.technique.subtechnique]]
123id = "T1098.005"
124name = "Device Registration"
125reference = "https://attack.mitre.org/techniques/T1098/005/"
126
127
128
129[rule.threat.tactic]
130id = "TA0003"
131name = "Persistence"
132reference = "https://attack.mitre.org/tactics/TA0003/"
133[[rule.threat]]
134framework = "MITRE ATT&CK"
135
136[rule.threat.tactic]
137id = "TA0001"
138name = "Initial Access"
139reference = "https://attack.mitre.org/tactics/TA0001/"

Triage and analysis

Investigating Entra ID RT to PRT Transition from Same User and Device

This rule identifies a sequence where a Microsoft Entra ID user signs in using a refresh token issued to the Microsoft Authentication Broker (MAB), followed by a sign-in using a Primary Refresh Token (PRT) from the same 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 obtained device trust and is now using the PRT to impersonate a fully compliant user+device pair.

Possible investigation steps

  • Identify the user principal and device from azure.signinlogs.properties.user_principal_name and azure.signinlogs.properties.device_detail.device_id.
  • Confirm the first sign-in event came from the Microsoft Auth Broker (app_id) with incoming_token_type: refreshToken.
  • Ensure the device has a trust_type of "Azure AD joined" and that the sign_in_session_status is "unbound".
  • Confirm the second sign-in used incoming_token_type: primaryRefreshToken and that the resource_display_name is 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

to-top