Entra ID Device-Bound PRT from Unusual Device IP

edit

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Entra ID Device-Bound PRT from Unusual Device IP

edit

Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from a source IP that has not been seen with that deviceid. Replay events are limited to compliant or Intune-managed devices. Adversaries who steal a WAM PRT SSO cookie replay it off-box; the token keeps the workstation deviceid, so this pair is new even when Windows Sign-In for that device is outside a correlation window.

Rule type: new_terms

Rule indices:

filebeat-*
logs-azure.signinlogs-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

Domain: Cloud
Domain: Identity
Use Case: Threat Detection
Use Case: Identity and Access Audit
Data Source: Azure
Data Source: Microsoft Entra ID
Data Source: Microsoft Entra ID Sign-in Logs
Platform: Entra ID
Tactic: Credential Access
Tactic: Defense Evasion
Resources: Investigation Guide
Rule Type: New Terms

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Entra ID Device-Bound PRT from Unusual Device IP

This rule fires when a tooling FOCI client redeems a device-bound PRT from a source.ip that has not appeared with that device_id in the prior 5 days. Unlike Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP, it does not need a Windows Sign-In or WAM event in the same window — so a workstation that last signed in yesterday still alerts when the cookie is redeemed from a new address.

PRTremote and similar harvest tools steal a WAM PRT SSO cookie and POST it from attacker infrastructure. The issued token keeps the workstation deviceid, so Conditional Access that requires a compliant device can succeed. Replay events must be is_compliant or is_managed. The stolen cookie nonce is typically valid for about five minutes; that is the attacker’s redeem window, not this rule’s history.

This is not ConsentFix / OAuth-code phishing. Those flows show OAuth2:Authorize with Redirect and often lack a bound compliant device.

Possible investigation steps

Review azure.signinlogs.properties.user_principal_name, azure.signinlogs.properties.device_detail.device_id, azure.signinlogs.properties.device_detail.display_name, and source.ip. Confirm incoming_token_type is primaryRefreshToken and device_detail.is_compliant / is_managed are true.
Compare azure.signinlogs.properties.app_display_name and user_agent.original with the resource (resource_display_name). A cookie POST through WAM can show a Trident/MSIE user agent on the Azure CLI client ID; that is the same IE stack legitimate Windows az login uses when it brokers through WAM, so it is triage context, not a detection key. TokenTactics commonly presents as Microsoft Office (that client is omitted here; hunt it separately if harvest is already confirmed).
Hunt prior Windows Sign-In / Windows-AzureAD-Authentication-Provider/1.0 events for the same deviceid. If those IPs differ from source.ip, treat this as the same story as the ES|QL companion. A Microsoft-owned ASN (including 8075) does not clear the alert.
Hunt endpoint telemetry for the same user or device display name as host.name: InteractiveToken scheduled tasks, svchost.exe (Schedule) → cmd.exe → BrowserCore.exe, or files formatted_nonce.txt / prt_cookie.txt.
Review Graph, SharePoint, and mailbox activity after the sign-in for directory, file, or mail enumeration.

False positive analysis

Developers who run Azure CLI, Graph CLI, or VS Code from a new network while WAM still attaches the workstation deviceid. Exception known Cloud Shell / jump-host IPs after confirming the client actually ran there.
First use of a tooling client on a new device, or the first time a laptop appears on a new ISP, will fire once per (device_id, source.ip) pair and then age out of novelty.
Hybrid-joined workstations that report both is_compliant and is_managed as false (no Intune) will not match. Hunt those deviceids separately if harvest is already confirmed.
Microsoft Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, Azure Portal, and Office 365 Management are excluded. Do not treat their absence as a miss.

Response and remediation

Contact the user to confirm whether they ran the first-party client from source.ip.
If unauthorized, revoke refresh tokens and primary refresh tokens for the user. The deviceid on the token is often the legitimate workstation — do not delete that device as if it were a ROADtx registration until you confirm otherwise.
Isolate the workstation, hunt for InteractiveToken scheduled tasks and BrowserCore harvest, and treat the admin identity that registered the task as a second compromised principal.

Setup

edit

The Azure Fleet integration (or Filebeat Azure module) with Microsoft Entra ID sign-in logs is required. Ingest SignInLogs and NonInteractiveUserSignInLogs into logs-azure.signinlogs-*.

See Microsoft Entra ID sign-in logs and the Azure integration.

Rule query

edit

data_stream.dataset: azure.signinlogs and
    event.outcome: success and
    azure.signinlogs.properties.status.error_code: 0 and
    azure.signinlogs.properties.incoming_token_type: "primaryRefreshToken" and
    azure.signinlogs.properties.device_detail.device_id: * and
    source.ip: * and
    (
        azure.signinlogs.properties.device_detail.is_compliant: true or
        azure.signinlogs.properties.device_detail.is_managed: true
    ) and azure.signinlogs.properties.app_id: (
        "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or
        "1950a258-227b-4e31-a9cf-717495945fc2" or
        "aebc6443-996d-45c2-90f0-388ff96faa56" or
        "14d82eec-204b-4c2f-b7e8-296a70dab67e" or
        "1b730954-1685-4b74-9bfd-dac224a7b894" or
        "872cd9fa-d31f-45e0-9eab-6e460a02d1f1"
    ) and azure.signinlogs.properties.resource_id: (
        "00000003-0000-0000-c000-000000000000" or
        "00000003-0000-0ff1-ce00-000000000000" or
        "6a9b9266-8161-4a7b-913a-a9eda19da220" or
        "00000002-0000-0ff1-ce00-000000000000"
    )

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
Technique:
- Name: Steal Application Access Token
- ID: T1528
- Reference URL: https://attack.mitre.org/techniques/T1528/
Technique:
- Name: Steal Web Session Cookie
- ID: T1539
- Reference URL: https://attack.mitre.org/techniques/T1539/
Tactic:
- Name: Defense Evasion
- ID: TA0005
- Reference URL: https://attack.mitre.org/tactics/TA0005/
Technique:
- Name: Use Alternate Authentication Material
- ID: T1550
- Reference URL: https://attack.mitre.org/techniques/T1550/
Sub-technique:
- Name: Application Access Token
- ID: T1550.001
- Reference URL: https://attack.mitre.org/techniques/T1550/001/
Tactic:
- Name: Initial Access
- ID: TA0001
- Reference URL: https://attack.mitre.org/tactics/TA0001/
Technique:
- Name: Valid Accounts
- ID: T1078
- Reference URL: https://attack.mitre.org/techniques/T1078/
Sub-technique:
- Name: Cloud Accounts
- ID: T1078.004
- Reference URL: https://attack.mitre.org/techniques/T1078/004/

« Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP Entra ID Windows Hello or Passkey Sign-in from Unregistered Device »