Detecting AWS Session Token Hijacking: CloudTrail, GuardDuty and Athena Queries

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

Stolen AWS session tokens let attackers act as a legitimate user without signing in. Detection focuses on where and how sessions are used.

Signals worth watching

• An IAM Identity Center or assumed-role session used from an IP address different from where it was issued.
• Sessions used from VPN services, hosting providers or unusual countries.
• Developer roles performing write actions on production resources they rarely touch (for example, PutObject on front-end asset buckets).
• Activity outside the developer's normal hours.
• GuardDuty findings for anomalous behavior or credential use from unusual locations.

Where the data lives

• CloudTrail: UserIdentityArn, SourceIpAddress, SessionCredentialFromConsole, and session context.
• IAM Identity Center sign-in events (Authenticate, Federate).
• GuardDuty findings.
• S3 data events for critical buckets.

A starting query

Assumed-role sessions used from multiple IPs:

AWSCloudTrail
| where UserIdentityType == "AssumedRole"
| extend SessionName = tostring(split(UserIdentityArn, "/")[2])
| summarize IPs = dcount(SourceIpAddress), IPList = make_set(SourceIpAddress, 10)
    by UserIdentityArn, bin(TimeGenerated, 1h)
| where IPs > 1

Changes to production web assets:

AWSCloudTrail
| where EventName in ("PutObject", "CopyObject", "DeleteObject")
| where RequestParameters has "prod-frontend-bucket"
| project TimeGenerated, UserIdentityArn, SourceIpAddress, RequestParameters

Response

1. Revoke active sessions (deny policies based on token issue time; sign out in IAM Identity Center).
2. Review all actions in the session.
3. Restore modified assets from versions.
4. Investigate the developer's device.