14.3 Identifying Token Replay in Sign-In Logs

Identifying Token Replay in Sign-In Logs

The hardest part of token replay investigation is distinguishing replay from legitimate multi-device usage. A user who signs into Outlook on their laptop AND on their phone generates sign-ins from two different IPs — which looks identical to token replay. This subsection teaches the specific log fields that differentiate them.

Required role: Microsoft Sentinel Reader.

The key differentiators

Field 1: AuthenticationRequirement. Legitimate sign-ins show multiFactorAuthentication (MFA was completed). Token replay sign-ins show singleFactorAuthentication — because the token already passed MFA, the replaying session does not trigger a new MFA challenge.

Field 2: IsInteractive. Legitimate user sign-ins are typically interactive (the user actively signed in). Token replay via API/script shows as non-interactive (the application silently presented the token).

Field 3: TokenIssuerType. Legitimate sign-ins from managed devices show AzureAD. Sign-ins using a stolen session cookie imported into a non-managed browser may show different issuer characteristics.

Field 4: DeviceDetail. Legitimate sign-ins include device information (OS, browser, device ID). Token replay from attacker infrastructure often has: a different OS/browser than the user’s known devices, or missing device detail entirely (when using API-based access).

The token replay identification query

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// Identify potential token replay: same user, different IPs, different auth requirements
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName == "r.williams@northgateeng.com"
| where ResultType == "0"
| project TimeGenerated, IPAddress,
    AuthReq = AuthenticationRequirement,
    IsInteractive,
    AppDisplayName,
    Browser = tostring(DeviceDetail.browser),
    OS = tostring(DeviceDetail.operatingSystem),
    DeviceId = tostring(DeviceDetail.deviceId),
    Location = strcat(tostring(LocationDetails.countryOrRegion), "/",
        tostring(LocationDetails.city)),
    ConditionalAccessStatus
| order by TimeGenerated desc

Pattern analysis: Legitimate multi-device usage shows: MFA completed on each device, consistent device details (known devices), and corporate or home IPs. Token replay shows: single-factor auth from a non-corporate IP, different or missing device details compared to the user’s known devices, and access to resources the user does not normally access from that IP.

The definitive replay test: timeline correlation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

// Correlation: was this IP active during the original compromise window?
let CompromiseWindow = datetime(2026-02-27T08:00:00Z);
let CurrentIP = "203.0.113.91";
// Check: did this IP appear during the original AiTM window?
SigninLogs
| where TimeGenerated between(CompromiseWindow .. (CompromiseWindow + 72h))
| where IPAddress == CurrentIP
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName
| union (
    // Check: does this IP appear for other users? (shared attacker infrastructure)
    SigninLogs
    | where TimeGenerated > ago(30d)
    | where IPAddress == CurrentIP
    | where UserPrincipalName != "r.williams@northgateeng.com"
    | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName
)
| order by TimeGenerated desc

If the IP appeared during the original compromise window OR is used by other compromised accounts: confirmed attacker infrastructure. If the IP is entirely new and not associated with any previous compromise: possible re-compromise through a different vector.

Subsection artifact: The token replay identification query and the timeline correlation query. These form the identification section of your token investigation playbook.

Knowledge check

Common false positives and how to rule them out

Not every multi-IP sign-in is token replay. Before escalating, rule out these legitimate scenarios:

VPN disconnect/reconnect. The user’s VPN drops momentarily, and the next request goes through their ISP’s direct IP instead. The sign-in logs show two IPs within minutes. Differentiator: both IPs are from the same geographic area, and the user agent is consistent. Check: is one of the IPs a known corporate VPN exit? If yes: probably VPN failover.

Mobile network handoff. A mobile user moves from WiFi to cellular (or between cellular towers). Their IP changes mid-session. Differentiator: both IPs are in the same country, the device detail shows a mobile OS, and the time gap is seconds (not minutes). Token replay typically shows a different OS or browser.

Legitimate multi-device usage. The user signs into Outlook on their laptop AND on their phone within the same hour. Two different IPs (one corporate WiFi, one cellular). Differentiator: both devices are known to the user (check DeviceDetail.deviceId against the user’s registered devices), and both show MFA completed (not single-factor).

Cloud proxy or CASB. If the organisation routes traffic through a cloud proxy (Zscaler, Netskope), the user’s sign-in may show the proxy’s IP instead of the corporate IP. The proxy IP changes as the user is routed to different proxy nodes. Differentiator: the IPs belong to the proxy provider’s ASN. Add proxy IPs to the CorporateExternalIPs watchlist.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Rule out false positives: check if the suspicious IP is a known proxy/VPN
SigninLogs
| where TimeGenerated > ago(90d)
| where IPAddress == "203.0.113.91"  // The suspicious IP
| where ResultType == "0"
| summarize
    UniqueUsers = dcount(UserPrincipalName),
    Users = make_set(UserPrincipalName, 20),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)

If the IP has been used by many legitimate users over months: it is likely a corporate proxy or VPN exit that is missing from your watchlist. If the IP has been used by only the compromised user (or a small number of known-compromised users): it is attacker infrastructure.