What is a replay attack? How it works and ways to prevent it

Think of a replay attack as cybercrime’s version of a movie rerun—only this one can empty your bank account or unlock your secure systems. 

In a replay attack, cybercriminals don’t need to decode your secrets; they just wait, record a legitimate action—like a login or transaction—and then replay it at just the right moment to trick the system into opening the gates. No brute force, no elaborate heist, just a well-timed encore. It’s one of the simplest tricks in the cyber playbook. 

So how do these attacks actually work—and what’s stopping someone from hitting “play” on your data? Read on to find out.

How does a replay attack work?

In a replay attack, the attacker doesn’t need to invent new data or break encryption. Instead, they intercept a real, encrypted message, save it, and send it again later. 

Even if they can’t decrypt the data, the system might still accept it as valid and carry out the same action—like processing a payment or granting access. 

That’s why techniques like using a unique “nonce” (a one-time value) are so important: they prevent old messages from being reused, even if the attacker can’t read or alter them.

Understanding the replay mechanism

Here’s how it usually plays out:

1. Capture: The attacker grabs sensitive data moving across a network, like a login token or payment approval, using tools like packet sniffers or positioning themselves between two parties (a classic man-in-the-middle setup).
2. Store: After capturing the data, the attacker keeps it somewhere safe—maybe on a hard drive, USB stick, or even cloud storage. They’re basically waiting for the right time to use it.
3. Replay: When the time comes, they resend the original data. If the system doesn’t check whether a request is fresh, it accepts the replayed message like it’s new, granting access or approving actions.

Why are digital systems vulnerable?

Most digital systems are built to trust what they recognize. If a system sees a valid token or request and doesn’t verify whether it’s fresh, unique, or already used, it’s easy for attackers to slip in a duplicate and trick the system into responding as if the request were new.

Why vulnerabilities happen:

• Missing timestamps or nonces: Without unique markers like timestamps or nonces, a system can’t distinguish between a new message and an old one being replayed. This is one of the most common causes of vulnerability to replay attacks.
• Weak session management: Systems that use long-lived tokens or fail to expire sessions promptly give attackers a broader window to reuse intercepted credentials. This includes APIs, web apps, and authentication systems that don’t rotate or invalidate tokens often enough.

What are the risks of a replay attack?

Replay attacks can cause serious damage, especially when they target systems that deal with sensitive information or financial transactions. Because the attacker sends a legitimate request, the system trusts it—and the damage can happen quietly.

Data breaches and identity theft

By replaying captured authentication data—such as tokens, session cookies, or even biometric verification responses—attackers can impersonate users and gain unauthorized access to accounts. Once inside, they may steal sensitive information like usernames, passwords, personal identification numbers, and financial details. This data is often used for identity theft or sold on dark web markets.

Replay attacks are particularly dangerous because they don’t require attackers to crack passwords or break encryption. Even two-factor authentication (2FA) can be bypassed if the system doesn’t verify the freshness of the request—especially in cases where 2FA tokens are valid for short windows and not tightly bound to specific sessions.

Financial fraud and online transactions

In systems that handle payments, a replayed transaction request can result in unauthorized transfers, refunds, or purchases. For example, if an attacker captures a legitimate payment approval and resends it, the system may process the same transaction multiple times—potentially draining funds or triggering unintended deliveries.

Without safeguards like unique transaction IDs, timestamps, or cryptographic verification, a system may treat a repeated request as new. This can lead to serious fraud, especially in automated or API-driven financial systems.

Cybersecurity threats in banking and e-commerce

Banking apps, digital wallets, and e-commerce platforms are frequent targets of replay attacks due to the high value of the data and transactions they handle. If an attacker reuses a session token or transaction request, they may hijack a user’s session, authorize account changes, or make unauthorized purchases.

Beyond financial loss, replay attacks can erode customer trust and expose businesses to legal liability. A successful attack can lead to data breaches, regulatory violations, and lasting damage to a company’s reputation.

Types of replay attacks

Replay attacks can happen in different ways depending on how the data is captured and reused. Here are the most common types you should know about. (If you’re new to some terms, here’s a handy internet security glossary.)

Network replay attack

In a network replay attack, the attacker intercepts valid data—like a login request or session initiation—as it travels between a user and a server. Later, they retransmit this exact data to the server.

If the system doesn’t check whether the message is new (using a nonce, timestamp, or session validation), it will accept the replayed request as genuine. These attacks often rely on packet sniffing in unsecured or poorly configured networks.

Wireless replay attack

Wireless networks are especially vulnerable to replay attacks due to the ease of intercepting over-the-air transmissions. In this version, an attacker captures a valid wireless frame—often part of a Wi-Fi handshake or authentication process—and replays it to trick the system.

Session replay attack

In this scenario, an attacker steals a valid session ID—typically stored in a cookie or URL—and reuses it to hijack a user’s session. This allows the attacker to access the account without knowing the user’s password.

This type of attack often stems from poor session management, like failing to bind sessions to IP addresses or user agents or not expiring sessions promptly.

JWT replay attack

A JSON web token (JWT) is a popular format for transmitting authentication data. In a JWT replay attack, an attacker intercepts a valid JWT—usually via an insecure connection or a cross-site scripting (XSS) attack—and resends it to impersonate the user.

JWTs are stateless and self-contained, meaning the token itself carries all the information needed to authenticate the user—such as their ID and roles—without needing to query a database. This makes JWTs efficient but also risky: once issued, a JWT remains valid until it expires, and servers typically don’t track its usage or whether it has been replayed.

If the server doesn’t verify whether a JWT is being reused inappropriately, an attacker can impersonate a user as long as the token is valid.

Kerberos replay attack

Kerberos is a network authentication protocol designed to provide secure authentication over an insecure network through the use of time-sensitive tickets. It’s widely used in enterprise environments. 

In a Kerberos replay attack, an attacker captures a valid ticket-granting ticket (TGT) or service ticket and replays it to gain unauthorized access. (Fun fact: In security circles, a stolen or forged TGT is often referred to as a “golden ticket,” while forged service tickets are called “silver tickets”—a nod to how powerful and dangerous these credentials can be in the wrong hands.)

Kerberos includes built-in protections (timestamps and mutual authentication), but if clocks aren’t synchronized or additional validation steps are skipped, these protections can fail.

Real-world examples of replay attacks

To really see why replay attacks are a serious threat, it helps to look at real examples where they have caused real damage. 

In 2022, attackers stole session tokens from Slack employees. These tokens were then used to access private GitHub repositories containing Slack’s internal code. Although the attackers didn’t steal passwords, they didn’t need to—by replaying the stolen session tokens, they bypassed authentication entirely. This is a textbook example of a replay attack: the attacker captured a valid authentication token and reused it to trick the server into granting access. While often categorized as “session hijacking,” the mechanism at work here is replay—sending a previously valid token back to the system to impersonate a legitimate user.

In another well-documented incident, vulnerabilities in Citrix NetScaler ADC and Gateway, two enterprise networking products used for load balancing, secure remote access, and application delivery, allowed attackers to capture authentication session data and reuse it to hijack user sessions. This flaw impacted thousands of organizations across healthcare, retail, and manufacturing. Once inside, attackers didn’t need credentials—replayed session tokens gave them immediate access to internal systems and sensitive data. Citrix issued emergency patches in October 2023 after reports of widespread exploitation.

Replay attacks also extend to the physical world. Researchers have used a HackRF One—a low-cost radio device—to capture and replay the wireless signal from everyday consumer remotes, including those for Christmas tree lights, garage doors, and cars. 

These real-world attacks show that replaying previously valid data—whether it’s a session token or a wireless command—can be enough to bypass security entirely. When systems don’t check whether a request is unique, fresh, or bound to a specific user or device, they’re wide open to this kind of attack.

How to prevent a replay attack

Understanding how replay attacks work is only half the battle—preventing them is where real security starts. Here are some of the most effective methods.

Using nonces and timestamping

A nonce (short for “number used once”) is a random or pseudo-random value attached to a request. When a system receives a message with a nonce, it checks whether that value has already been used. If it has, the request is immediately rejected. This prevents attackers from resending old requests, because reused nonces are invalid.

Timestamps add an expiration window to messages. If a request arrives outside of the expected time frame, it’s discarded as potentially malicious. Combined, nonces and timestamps ensure that every message is both unique and timely, which makes successful replays extremely difficult.

Implementing multi-factor authentication (MFA)

Multi-factor authentication (MFA) adds an extra step that makes replay attacks much harder to pull off.

Instead of just relying on a password, MFA asks for a second proof, like a code from your phone or an app. Even if an attacker manages to replay a stolen password or session token, they’d still be stuck without the second piece.

MFA works because it ties access to something the attacker probably doesn’t have. Without it, a replayed request would just hit a wall.

Secure communication protocols (TLS, HTTPS)

Transport layer security (TLS), used in HTTPS, encrypts data in transit between clients and servers. This encryption prevents attackers from easily capturing or altering messages using man-in-the-middle techniques. Even if someone intercepts the data, they can’t read or replay it without the correct cryptographic keys.

Session tokens and login credentials transmitted over unencrypted HTTP are highly vulnerable to replay attacks. TLS ensures that these tokens are protected in transit, minimizing interception risks.

VPNs can add an additional layer of encryption across your internet traffic, especially on unsecured networks. While they’re not a primary defense against replay attacks, they reduce exposure to traffic sniffing, which is often the first step in a replay attack. Learn how VPNs protect you from hackers.

Replay attack vs. man-in-the-middle attack

Replay attacks and man-in-the-middle (MitM) attacks both target data in transit, but they differ in complexity, goals, and techniques.

In a replay attack, the attacker captures a legitimate message (such as a login request, payment approval, or token) and resends it unchanged at a later time. The attacker does not modify the message—they simply rely on the fact that the system may accept a valid message again if freshness isn’t verified (e.g., no nonce, timestamp, or session control). It’s a passive form of attack with active reuse of captured data.

In a MitM attack, the attacker inserts themselves between two communicating parties, intercepting and possibly modifying or injecting messages in real time. This can involve decrypting messages (if TLS isn’t used properly), stealing credentials, or altering commands before forwarding them. 

To sum it up:

• Replay attack: Resend legitimate messages to trick the system into performing an action again.
• MitM attack: Actively intercept, read, modify, or inject messages between users or systems.

Note that replay attacks are often considered a subset or consequence of MitM attacks—because MitM techniques (e.g., network sniffing) are often how attackers capture the original messages they later replay. However, once the data is captured, a replay attack can also occur later and offline from the original communication.