A replay attack is an attack in which an adversary captures a valid message, credential or transaction and retransmits it later so that the receiving system accepts it as genuine. Among malware & attacks in cybersecurity it stands out because the attacker usually does not need to decrypt or understand the data: a correctly signed or encrypted message is reused exactly as it was sent.
Replay works whenever a receiver checks that a message is authentic but not that it is fresh and unique. The classic defenses therefore add freshness: nonces, timestamps, sequence numbers and challenge-response protocols that bind each message to a single moment or session.
How a replay attack works
A replay attack follows a simple pattern of capture, store and resend. The attacker gains a position to observe traffic, records a message that produces a useful effect, and later sends a copy to the same or a different receiver.
- Interception: the attacker sniffs a network, compromises an endpoint, records a radio signal or steals a token from logs or browser storage.
- Selection: the attacker identifies a message with value, such as a login exchange, a session cookie, a payment instruction or a door unlock code.
- Retransmission: the message is sent again, sometimes immediately and sometimes days later.
- Acceptance: the receiver validates the signature or MAC, finds it correct and performs the action again.
The key insight is that cryptographic integrity does not imply freshness. A message authenticated with HMAC-SHA256 remains perfectly valid when copied, because the copy is bit-for-bit identical. Only a protocol element that changes every time, and a receiver that remembers or verifies it, makes the copy detectable.
Common forms and targets
Replay appears in many technologies, from web sessions to car keys. The table groups the most common forms by what is replayed and the resulting impact.
| Scenario | What is replayed | Impact |
|---|---|---|
| Session token replay | Stolen session cookie or bearer token | Account access without password or MFA |
| Authentication replay | Captured hash or login message, as in pass-the-hash | Impersonation on the network |
| Transaction replay | Signed payment or API request | Duplicate transfers or orders |
| Radio replay | Fixed-code remote or wireless sensor signal | Opening gates, garages or older vehicles |
| Wireless handshake replay | Protocol messages in Wi-Fi key setup, as in the KRACK flaws | Nonce reuse and decryption |
| Blockchain cross-chain replay | Signed transaction valid on two forked chains | Unintended transfer on the second chain |
Today, session token replay is the most consequential form for most organizations. Infostealer malware harvests browser cookies, and attackers import them into their own browsers to bypass multi-factor authentication entirely, because the token represents a login that already succeeded.
Defenses that guarantee freshness
Every replay defense answers the same question: how does the receiver know this message is new? The options differ in state requirements, clock dependence and suitability for distributed systems.
| Mechanism | How it works | Requirement | Weakness |
|---|---|---|---|
| Nonce | Unique random value per message; receiver rejects repeats | Store of recently seen nonces | Storage grows without expiry |
| Timestamp window | Message valid only within a short interval | Synchronized clocks | Replay possible inside the window |
| Sequence number | Counter must increase for each message | Per-session state | Resynchronization after loss |
| Challenge-response | Receiver sends a fresh challenge that must be signed | Extra round trip | Not suitable for one-way messages |
| Rolling code | Transmitter and receiver advance a shared counter | Synchronized counters | Vulnerable to jam-and-replay tricks |
| Channel binding | Token tied to a key or TLS session | Client key management | Requires protocol support |
Robust designs often combine a timestamp with a nonce: the timestamp limits how long nonces must be stored, and the nonce closes the window inside the allowed interval. Kerberos, for instance, uses timestamps with a default clock skew tolerance of five minutes and a replay cache for authenticators.
Replay protection in modern protocols
Well-designed protocols build replay resistance in from the start. TLS uses fresh random values and per-record sequence numbers, so recorded records cannot be injected into another session. The exception is TLS 1.3 0-RTT early data, which is explicitly replayable and should only carry idempotent requests.
FIDO2 and passkeys resist replay through server-generated challenges and signature counters, which also defeats phishing proxies that forward credentials. In web APIs, sender-constrained tokens such as DPoP or mutual TLS bind an access token to a client key, so a stolen token alone is useless. Payment APIs use idempotency keys to ensure a retried request is processed only once.
Replay compared with related attacks
Replay is often discussed together with interception attacks, but the attacker’s role is narrower. The comparison clarifies the boundaries.
| Attack | Attacker capability | Modifies messages |
|---|---|---|
| Replay attack | Records and resends valid messages | No |
| Man-in-the-middle attack | Relays and alters traffic in real time | Yes |
| Relay attack | Forwards live messages over distance, as with keyless car entry | No, but in real time |
| Credential stuffing | Tries leaked passwords on other services | Not applicable |
| Brute-force attack | Guesses secrets systematically | Not applicable |
A common mistake is assuming that encryption alone prevents replay. Encryption hides content, but an encrypted command that is replayed still executes unless the protocol checks freshness.
Detection and practical mitigation
- Keep session lifetimes short and rotate refresh tokens on every use.
- Bind sessions to device characteristics or keys and alert on sudden location changes.
- Require step-up authentication for sensitive actions such as payments or password changes.
- Reject duplicate nonces and stale timestamps on all signed API requests.
- Protect endpoints against infostealers, the main source of reusable tokens.
Explained without jargon
Imagine someone records the sound of a person saying a password at a door, then plays the recording later and the door opens. That is a replay attack: reusing a genuine message instead of creating a fake one. The attacker does not need to understand the message, only to copy it.
The protection is to make every message usable only once. Systems add a unique number or a time stamp to each message, so a recording from yesterday is recognized as old and refused.
A typical use case
An employee at a consulting firm installs a cracked utility that secretly contains infostealer malware. The malware copies browser cookies, including an active session token for the company’s cloud email. Two days later, an attacker imports the cookie into a browser abroad and opens the mailbox without any password or MFA prompt.
The security team detects the session through an impossible-travel alert and revokes all sessions for the account. To reduce future exposure, the firm shortens session lifetime to eight hours, enables token binding offered by its identity provider and requires step-up authentication before mailbox rules can be changed. A replayed cookie from another device is now rejected, and the window for any stolen token is much shorter.