Entra PRT replay many tokens
One address or session presented SEVERAL DIFFERENT Primary Refresh Tokens interactively — the signature of a host replaying a harvested collection of…
What it detects
One address or session presented SEVERAL DIFFERENT Primary Refresh Tokens interactively — the signature of a host replaying a harvested collection of PRTs rather than a device using its own.
A PRT is issued to one device for one user and is meant to stay on that device. A device therefore has exactly one, and its sign-ins carry one uniqueTokenIdentifier for as long as the token lives. Several distinct token identifiers arriving from a single source is not a device behaving normally; it is a collection being worked through.
isInteractive: true matters: a genuine PRT refresh is non-interactive background traffic. An interactive PRT sign-in means something is driving the token through a browser-shaped flow, which is what a replay looks like.
Grouped by address AND session so a single compromised endpoint is one finding rather than one per token, and so the evidence names the tokens together.
MITRE ATT&CK mapping
False positives and triage
A shared egress address (corporate NAT, a VPN concentrator) puts many legitimate devices behind one IP, and each brings its own PRT — this is the main false positive, and it is why the rule also groups on session id. Before escalating, check whether the token identifiers belong to DIFFERENT users (a NAT gateway) or the SAME user (theft: one person's tokens should not arrive from many devices at once), and whether the device ids in the sign-ins are known-enrolled. A terminal server or VDI pool legitimately shows several users' tokens from one address and should be allowlisted once confirmed.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/entra_prt_replay_many_tokens.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_prt_replay_many_tokens
version: 1.0.0
status: stable
severity: critical
confidence: 0.7
platforms: [application]
mitre_techniques: [T1550.001, T1528]
description: |
One address or session presented SEVERAL DIFFERENT Primary Refresh Tokens
interactively — the signature of a host replaying a harvested collection of
PRTs rather than a device using its own.
A PRT is issued to one device for one user and is meant to stay on that device.
A device therefore has exactly one, and its sign-ins carry one
`uniqueTokenIdentifier` for as long as the token lives. Several distinct token
identifiers arriving from a single source is not a device behaving normally; it
is a collection being worked through.
`isInteractive: true` matters: a genuine PRT refresh is non-interactive
background traffic. An interactive PRT sign-in means something is driving the
token through a browser-shaped flow, which is what a replay looks like.
Grouped by address AND session so a single compromised endpoint is one finding
rather than one per token, and so the evidence names the tokens together.
match:
event_category: authentication
ext:incomingTokenType: primaryRefreshToken
ext:isInteractive: "true"
threshold:
# Two distinct PRTs from one source is already anomalous — a device has one.
# The window is an hour because replay tooling works through a dump quickly.
count: 2
window_seconds: 3600
distinct: ext:uniqueTokenIdentifier
group_by: [source_ip, session_id]
correlation_keys: [source_ip, user_name]
false_positive_guidance: |
A shared egress address (corporate NAT, a VPN concentrator) puts many legitimate
devices behind one IP, and each brings its own PRT — this is the main false
positive, and it is why the rule also groups on session id. Before escalating,
check whether the token identifiers belong to DIFFERENT users (a NAT gateway) or
the SAME user (theft: one person's tokens should not arrive from many devices at
once), and whether the device ids in the sign-ins are known-enrolled. A terminal
server or VDI pool legitimately shows several users' tokens from one address and
should be allowlisted once confirmed.
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.