A replay attack is when an attacker captures a valid network message (like a login or payment request) and sends it again to trick a system into granting access or repeating an action. The attacker doesn’t need to read or change the contents—just re-transmit them at the right time. Replay usually rides on a compromised or untrusted network path (malware on the device, rogue Wi-Fi, or local MitM) and succeeds when the protocol lacks freshness checks such as nonces, timestamps, or one-time tokens.
Replay can bypass passwords and some MFA flows by reusing session cookies, bearer tokens, or previously valid requests. That can mean unauthorized logins, duplicated transactions, or account changes without the victim realizing.
Intercept: capture an authenticated request or token on a weak or compromised path.
Store: hold the message until it’s useful or the token is still valid.
Re-send: transmit the same bytes to the server to repeat the original effect.
Pivot: use the resulting session to pull data, change settings, or move laterally.
Identical requests hitting an API with the same payload and headers within short intervals.
Successful logins that skip fresh MFA challenges, followed by token reuse from new IPs.
Duplicate transaction IDs or nonce failures in logs.
Sudden activity from untrusted networks shortly after a user’s legitimate action.
Enforce TLS with strict certificate validation; block captive portals and rogue APs on sensitive devices.
Add freshness: nonces, one-time tokens, signed requests, and short token lifetimes.
Bind tokens to context (client TLS key, device ID, or IP range) and invalidate on change.
Use SameSite+HttpOnly+Secure cookies; rotate sessions after auth and on privilege changes.
Require server-side replay detection (nonce store, timestamp windows, idempotency keys).