Detecting Leaked Session Tokens: Sentinel and GuardDuty Detections

Retrospective: this article looks back at events from February 2017, written in 2026 with the benefit of hindsight.

When a provider leaks session tokens, the question is whether anyone used them. Detection focuses on sessions that look valid but behave differently from the real user.

Signals worth watching

• The same session or token used from two distant locations in a short time.
• Sign-ins with a valid session but an unfamiliar device, browser or operating system.
• Token use after a session was revoked or a password changed.
• Activity from hosting providers or anonymizing networks for users who normally sign in from the office.

Where the data lives

Microsoft 365 / Entra ID: interactive and non-interactive sign-in logs, Entra ID Protection risk detections (such as anomalous token and unfamiliar sign-in properties), and the unified audit log for mailbox and file access.

AWS: CloudTrail events showing API calls with credentials that should have been rotated, and GuardDuty findings for credential use from unusual locations.

A starting query

Look for users signing in from more than one country within an hour:

SigninLogs
| where ResultType == "0"
| summarize Countries = dcount(Location), CountryList = make_set(Location)
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where Countries > 1

Response

1. Revoke sessions for any user showing suspicious token reuse.
2. Check what the session accessed: mail, files, admin portals.
3. Rotate any secrets the user or application could reach.
4. Enable Conditional Access controls that make tokens harder to replay, such as compliant-device requirements and token protection where supported.

Session theft is now a common attack technique, not only a provider-bug scenario. The same detections serve both.