What is a replay attack?
A replay attack captures a legitimate piece of authentication data or a transaction and sends it again to impersonate the original party. The attacker never needs to know a password or break any encryption; they only need to capture a valid message and reuse it before it expires. The same idea applies whether the replayed item is a login exchange on the wire or a captured request to a web application.
What gets replayed
Several things can be captured and resent. An authentication exchange on a protocol that proves identity the same way each time can be recorded and replayed. A session token or cookie, which stands in for your credentials after login, lets anyone who presents it be treated as you, which is session hijacking by replay. A captured application request, such as a transfer call or a signed URL, can repeat the action. The indicators are a valid-looking authentication or request arriving twice, or one session appearing from two very different places.
A worked example
An attacker steals the session cookie a bank issues after a user logs in, for example with infostealer malware, then loads that cookie into their own browser. The server sees a session that already passed authentication, so it asks for no password and no second factor. This is why an adversary-in-the-middle phishing proxy is so effective: it relays a real login, lets the user complete MFA, and steals the resulting session cookie to replay.
How to defend against it
Make every exchange unique so a captured copy is worthless the second time. A nonce is a number used once: the server issues a fresh, unpredictable value, the client folds it in, and the response is accepted only once. A timestamp limits how long a message is valid, which is why synchronized clocks matter. Kerberos combines both, stamping each authenticator with the current time and rejecting a stale or already-seen one. For sessions, use short lifetimes, rotate the identifier after login, bind the session to the device, and mark cookies HttpOnly, Secure and SameSite. Encrypting the channel with TLS keeps the attacker from capturing anything to replay.
Replay vs. on-path attacks
An on-path attacker relays and can alter a live conversation in real time. A replay attack reuses something captured earlier; the original exchange is over, and the attacker simply sends the recorded copy again. Both can involve capturing traffic, but replay is defined by resending a valid message later.
Replay attack on the CompTIA Security+ exam
Replay is listed under objective 2.5, and CompTIA names it among both credential and application attacks. A scenario where a captured token, cookie or request is accepted a second time, or where authentication succeeds without the attacker knowing the password, points at replay. The distractors are a brute-force attack and a plain on-path attack. The defenses the exam wants are nonces, timestamps and short-lived, bound session tokens.