MFA Won’t Save You: How Hackers Use Token Replay to Hijack Cloud Accounts

Your firewall isn’t your perimeter anymore. Identity is. But what happens when the digital keys to that identity are stolen after the lock has already been opened?

If you work in cybersecurity, you know the drill: enforce complex passwords, turn on Multi-Factor Authentication (MFA), and sleep soundly. But advanced adversaries have evolved. They aren’t trying to guess your password or SIM-swap your phone anymore. They are bypassing the login process entirely using a technique known as Token Replay.

The Anatomy of the Hack

A Token Replay attack occurs when an adversary intercepts a valid authentication token such as an OAuth access token, AWS STS credential, or Azure Primary Refresh Token and reuses it to access cloud resources.

Think of it like a wristband at a nightclub. The bouncer (MFA) checks your ID at the door. But if someone slips that wristband off your wrist and puts it on their own, they can walk in and out of the club freely. The bouncer doesn’t check their ID again because the wristband is the proof of verification.

In the cloud, that wristband is the Session Token.

Step 1: Extraction

Before they can replay a token, hackers have to steal it. They don’t need to breach the cloud provider; they just need to breach the endpoint or the pipeline. According to the field guide, there are four primary vectors for extraction:

1. Browser Session Extraction: Malware on a compromised laptop scrapes cookies and session tokens directly from the browser’s local storage.
2. Reverse-Proxy Phishing: Tools like Evilginx sit in the middle of a legitimate login flow. You log in successfully, MFA and all, but the proxy captures the session token along with your credentials.
3. API Token Leakage: Developers often inadvertently expose tokens in CI/CD pipelines, build logs, or environment variables.
4. Stolen Workload Tokens: Attackers compromise a serverless function or container and query the metadata service to steal the temporary cloud identity tokens assigned to that workload.

Step 2: The Session

This is where the attack becomes terrifying for SOC analysts. Once the attacker has the token, they import it into their own CLI tools.

Because the token is valid, the cloud provider sees the attacker’s traffic as a continuation of your legitimate session.

It generates almost no noise. In a standard attack, you see a “Failed Login” or a “Successful Login.”

In a Token Replay attack, the attacker creates no new “Authentication” event. They jump straight to “Resource Access” (e.g., listing users or downloading S3 buckets).

How to Hunt the Invisible

If you rely solely on Failed Login alerts, you will miss this attack entirely. Detection requires behavioral analysis comparing how the token is being used against how it was issued.

Here are four high-fidelity signals to look for:

1. The Teleporting Token

A token issued in one location should not suddenly be used in another.

The Signal

Identify tokens that were issued in Region A (e.g., Germany) but are being used to make API calls from Region B (e.g., South Korea) within a short timeframe.

The Hunt

Correlate the sourceIPAddress of the issuance event (like AssumeRole) with the IP address of subsequent data plane API calls.

2. The No Login Event

This is a critical indicator for AWS environments.

The Signal

STS credentials are being used to make API calls, but there is no corresponding ConsoleLogin or SSO Login event in the preceding timeframe.

The HuntIf you see GetRoleCredentials or AssumeRoleWithSAML activity from an IP address, but no prior authentication event from that user/IP, you are likely looking at a stolen session.

3. The Multiplying Identity

A single session token should generally be bound to a single machine.

The Signal

The exact same session token (STS token, OAuth token, or Azure PRT) is being used from multiple different IP addresses simultaneously.

The Hunt

In Azure, look for Primary Refresh Tokens (PRTs) roaming across different ASNs. In AWS, query for a specific userIdentity.accessKeyId appearing from more than one unique sourceIPAddress.

4. The Reconnaissance

Detection isn’t just about the token; it’s about what happens immediately after it appears.

The Signal

A sudden spike in reconnaissance APIs (Get, List, Describe) or the creation of persistence mechanisms (like new OAuth apps) immediately following a silent authentication.

The Response Playbook

If you suspect a Token Replay attack, changing the password is not enough , the attacker is already past the password. You must sever the connection.

1. Revoke Sessions: You must invalidate the active session tokens. In AWS, this means revoking active sessions and rotating keys. In Azure, you must revoke sign-in sessions and invalidate refresh tokens.
2. Investigate the Endpoint: Since tokens are often stolen from the endpoint, the user’s device is likely compromised by malware.
3. Check for Persistence: Look for new MFA devices, API keys, or Service Principals added during the window of compromise.

Ready to Master Cloud Forensics?

This article only scratches the surface of the detection logic required to defend modern cloud environments.

After years of jumping between the AWS CLI, Azure Portal, and Google Cloud Console, we realized that the single pane of glass promise is often a myth; the reality of our job is a chaotic mix of distinct logging architectures, disparate identity models, and endless context switching .

We compiled these notes not as a theoretical textbook, but as a tactical survival guide for the modern SOC analyst who needs to pivot instantly from dissecting AssumeRole chains in CloudTrail to hunting for impossible travel in Azure AD Sign-in logs .

This notebook is the consolidation of late-night investigations and lessons learned from the trenches, documenting the exact jq syntax needed to parse massive log dumps , the specific artifacts required to catch silent threats like Token Replay attacks , and the cross-platform strategies necessary to reconstruct a timeline when an adversary moves laterally across your multi-cloud estate .

The Cloud SOC Field Guide contains the exact SIEM queries (Splunk, KQL, Athena), CLI commands, and step-by-step forensic workflows to detect Token Replay, MFA Fatigue, IaC Poisoning, and more.

The Cloud SOC Analyst Manual (AWS-GCP-AZURE)

The Cloud SOC Field Guide: Multi-Cloud Forensics & Threat Hunting is a tactical, boots-on-the-ground manual…

You May Also Watch