Entra PRT replay failures
The SAME Primary Refresh Token was presented interactively over and over from one source and kept failing — a stolen token being retried against…
What it detects
The SAME Primary Refresh Token was presented interactively over and over from one source and kept failing — a stolen token being retried against conditional access rather than a device signing in.
A device that holds its own PRT does not fail with it repeatedly: the token is valid, the device is compliant, and the sign-in succeeds. Repeated interactive failures on ONE token identifier mean something is holding a token it cannot fully use — typically a replay from an unenrolled host, where the PRT itself is accepted but device compliance, MFA claim or a conditional-access grant is not.
This is the failure half of PRT theft, and it is the half that shows up FIRST. It is worth alerting on by itself because it is the window in which the theft can still be contained: the attacker has the token but has not yet satisfied policy.
MITRE ATT&CK mapping
- T1550.001Use Alternate Authentication Material: Application Access Token· Defense Evasion
False positives and triage
A user whose device fell out of compliance (expired certificate, disk encryption off, stale enrolment) will fail interactively on their own PRT until the device is remediated, and that is the common benign shape. The discriminator is the source: check whether the address is the user's usual one and whether the device id in the sign-in is enrolled to that user. Same token from a NEW address is theft; same token from the SAME address the user always uses is a compliance problem. Also check the error codes — 50199 and 53000-53004 are conditional-access and device-state failures, while 50126 would suggest an unrelated password issue.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/cloud/entra_prt_replay_failures.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_prt_replay_failures
version: 1.0.0
status: stable
severity: high
confidence: 0.6
platforms: [application]
mitre_techniques: [T1550.001]
description: |
The SAME Primary Refresh Token was presented interactively over and over from
one source and kept failing — a stolen token being retried against conditional
access rather than a device signing in.
A device that holds its own PRT does not fail with it repeatedly: the token is
valid, the device is compliant, and the sign-in succeeds. Repeated interactive
failures on ONE token identifier mean something is holding a token it cannot
fully use — typically a replay from an unenrolled host, where the PRT itself is
accepted but device compliance, MFA claim or a conditional-access grant is not.
This is the failure half of PRT theft, and it is the half that shows up FIRST.
It is worth alerting on by itself because it is the window in which the theft can
still be contained: the attacker has the token but has not yet satisfied policy.
match:
event_category: authentication
event_outcome: failure
ext:incomingTokenType: primaryRefreshToken
ext:isInteractive: "true"
threshold:
count: 3
window_seconds: 3600
group_by: [source_ip, "ext:uniqueTokenIdentifier"]
correlation_keys: [source_ip, user_name]
false_positive_guidance: |
A user whose device fell out of compliance (expired certificate, disk encryption
off, stale enrolment) will fail interactively on their own PRT until the device
is remediated, and that is the common benign shape. The discriminator is the
source: check whether the address is the user's usual one and whether the device
id in the sign-in is enrolled to that user. Same token from a NEW address is
theft; same token from the SAME address the user always uses is a compliance
problem. Also check the error codes — 50199 and 53000-53004 are conditional-access
and device-state failures, while 50126 would suggest an unrelated password issue.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.