Entra PRT replay success after failures
A Primary Refresh Token that had been failing interactively then SUCCEEDED from the same source — the moment a replayed token got through.
What it detects
A Primary Refresh Token that had been failing interactively then SUCCEEDED from the same source — the moment a replayed token got through.
This is the sequence that matters most in a PRT theft, and neither half tells the story alone. Failures by themselves are ambiguous (a non-compliant device looks the same). A success by itself looks like an ordinary sign-in. The transition — repeated interactive failures on one token, then a success on that same token from that same source — is the attacker finding the conditional-access gap, and it is the point at which the session becomes usable.
Alerting on the transition rather than on either half is what makes this actionable: it names the exact sign-in that granted access, so the response is a specific session to revoke rather than an account to review.
MITRE ATT&CK mapping
False positives and triage
The benign version of this shape is a device that was non-compliant, got remediated, and then signed in successfully — same token, same address, failures then success. Distinguish on the source and the gap: remediation takes a human minutes to hours and happens from the user's normal address, while a replay retries quickly from an address the user has not used. Check whether a device compliance or conditional-access policy change was recorded between the failure and the success — if one was, this is remediation, not theft. If the success came from a new address with no policy change, treat the session as compromised and revoke it rather than resetting the password alone (a password reset does not invalidate an already-issued PRT).
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/cloud/entra_prt_replay_success_after_failures.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_prt_replay_success_after_failures
version: 1.0.0
status: stable
severity: critical
confidence: 0.75
platforms: [application]
mitre_techniques: [T1550.001, T1078.004]
description: |
A Primary Refresh Token that had been failing interactively then SUCCEEDED from
the same source — the moment a replayed token got through.
This is the sequence that matters most in a PRT theft, and neither half tells
the story alone. Failures by themselves are ambiguous (a non-compliant device
looks the same). A success by itself looks like an ordinary sign-in. The
transition — repeated interactive failures on one token, then a success on that
same token from that same source — is the attacker finding the conditional-access
gap, and it is the point at which the session becomes usable.
Alerting on the transition rather than on either half is what makes this
actionable: it names the exact sign-in that granted access, so the response is a
specific session to revoke rather than an account to review.
sequence:
# An hour: the retry-until-through pattern is minutes to tens of minutes, and a
# longer window would start joining unrelated sign-ins on the same token.
within_seconds: 3600
group_by: [source_ip, "ext:uniqueTokenIdentifier"]
order: strict
steps:
- id: prt_replay_rejected
match:
event_category: authentication
event_outcome: failure
ext:incomingTokenType: primaryRefreshToken
ext:isInteractive: "true"
- id: prt_replay_accepted
match:
event_category: authentication
event_outcome: success
ext:incomingTokenType: primaryRefreshToken
ext:isInteractive: "true"
correlation_keys: [source_ip, user_name]
false_positive_guidance: |
The benign version of this shape is a device that was non-compliant, got
remediated, and then signed in successfully — same token, same address, failures
then success. Distinguish on the source and the gap: remediation takes a human
minutes to hours and happens from the user's normal address, while a replay
retries quickly from an address the user has not used. Check whether a device
compliance or conditional-access policy change was recorded between the failure
and the success — if one was, this is remediation, not theft. If the success came
from a new address with no policy change, treat the session as compromised and
revoke it rather than resetting the password alone (a password reset does not
invalidate an already-issued PRT).
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.