In our previous briefings, we dissected the campaigns of UNC6040’s vishing attacks and UNC6395’s supply chain compromise. The common thread weaving through these devastating breaches wasn’t a software zero-day or a brute-forced password; it was the abuse of a legitimate, fundamental component of the modern cloud: the OAuth token.
This isn’t a problem limited to a few threat actors. Throughout 2024 and 2025, a wave of attacks has exploited the core logic of OAuth, allowing adversaries to bypass MFA and breach major corporations like Google, Allianz Life, and Louis Vuitton by tricking users into authorizing malicious applications. The attackers don’t need to break in when they can be invited in through a legitimate, token-based handshake.
This is the threat of the OAuth Replay Attack. It’s an attack on the very architecture of trust that connects our cloud applications. To defend against it, you must understand that the target isn’t just your password; it’s the digital key that password unlocks.
The Attacker’s Playbook: Stealing the Keys to the Kingdom
An OAuth Replay attack hinges on a simple principle: if an attacker can steal a valid token, they become you. The token itself is a “bearer” token, meaning whoever bears it has the authority to use it. The attack unfolds by targeting different stages of the OAuth lifecycle.
- The Interception (Authorization Code Theft): In the initial OAuth handshake, a temporary “authorization code” is passed through the user’s browser. Attackers use malicious browser extensions or compromised redirect URLs to snatch this code in transit. They then race the legitimate application to exchange that code for a full-fledged access token, effectively hijacking the session before it even begins.
- The Smash and Grab (Access Token Theft): The most common target is the access token itself—the short-lived key that grants direct access to your data. These tokens are often stored in browser local storage, where they can be stolen by cross-site scripting (XSS) attacks, or inadvertently leaked in logs or public code repositories. Once stolen, the attacker can “replay” it from their own systems to access your APIs.
- The Long Game (Refresh Token Theft): This is the crown jewel. A refresh token is a long-lived credential, sometimes valid for months, whose sole purpose is to get new access tokens. Stealing one is like getting a master key that can cut new keys on demand. This is precisely how UNC6395 maintained persistent access to victim environments long after the initial compromise, turning a momentary breach into a long-term surveillance operation.
Why This Attack is So Deceptive
The danger of OAuth replay lies in how it subverts our security assumptions. It’s a ghost in the machine, using legitimate pathways for malicious ends.
- It’s a Feature, Not a Bug: This vulnerability is a direct result of a deliberate design choice in OAuth 2.0, which prioritized ease of use for developers over the complex cryptographic signatures required by its predecessor, OAuth 1.0a. This simplicity fueled the connected cloud, but at the cost of creating bearer tokens that are inherently replayable.
- Possession is Authorization: A bearer token is like a physical keycard. The server doesn’t care who is holding the card, only that the card itself is valid. When an attacker steals your token, the server has no native way to distinguish the malicious “replay” from your legitimate request.
- It Bypasses the Front Gate: An attacker with a stolen refresh token doesn’t need your password and doesn’t have to pass an MFA challenge. They use the token at the API layer to mint new access tokens directly, completely bypassing the user-facing login process and its associated security controls.
Defending Against Token Replay: A New Security Model
Protecting against this threat requires moving beyond traditional perimeter defenses and adopting a new model focused on the security of the tokens themselves.
1. See the Invisible (Detection & Monitoring)
You cannot fight what you cannot see. Gaining visibility into token lifecycles is the critical first step.
- Practice Token Genealogy: Log and monitor the entire lifecycle of a token—from the issuance of an authorization code, to the generation of access/refresh tokens, to every API call made. In Salesforce, this means operationalizing your
EventLogFileand Connected App usage data. - Hunt for Anomalies: A single token being used from two geographically impossible locations at once is a definitive sign of a replay attack. Baseline the normal API behavior of your integrated apps and alert on deviations, such as an application suddenly accessing new types of data or pulling data at unusual times.
2. Shrink the Target (Tactical Hardening)
Make stolen tokens less valuable by limiting their lifespan and usability.
- Enforce Short Lifespans: Reduce the validity period of access tokens from hours to minutes. This drastically shrinks the window of opportunity an attacker has to use a stolen token.
- Rotate Refresh Tokens: Implement refresh token rotation, a mechanism where using a refresh token immediately invalidates it and issues a new one. This ensures that if a refresh token is stolen and replayed, you can detect the reuse and revoke the entire credential family.
3. Change the Locks (Architectural Evolution)
The ultimate solution is to move away from simple bearer tokens to a “proof-of-possession” model.
- Adopt DPoP and mTLS: These emerging standards—Demonstrating Proof-of-Possession (DPoP) and mutual TLS (mTLS)—cryptographically bind a token to the device that requested it. With these controls, a stolen token is useless to an attacker because they cannot “prove” they are the legitimate owner. Demand these features from your SaaS vendors and prioritize them for new in-house applications.
The shift to the cloud was about agility and interconnection. The next shift in security must be about ensuring that trust is not a vulnerability. As attackers focus their efforts on identity and authorization, our defenses must evolve to protect not just the login screen, but the powerful tokens that lie beyond it.
Disclaimer: The information provided in this blog post is for educational and informational purposes only. While Xenicore strives to present accurate and up-to-date information, the cybersecurity landscape is constantly changing. We make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, or suitability of the information contained herein. Any reliance you place on such information is therefore strictly at your own risk. This article may contain links to external websites that are not provided or maintained by or in any way affiliated with Xenicore.