A user did everything right. She used a long, unique password, and her account is protected with multifactor authentication. One afternoon she clicked a link in an email that looked like it came from the IT team, signed in on the page it opened, and approved the login prompt on her phone. Nothing seemed wrong; the real site loaded. By evening, an attacker was reading her mailbox from another country, and the system never asked them for a password or a code.
Replay attacks and MFA bypass are how attackers defeat authentication without breaking it, by reusing something already valid or by stepping around the second factor. On the CompTIA Security+ SY0-801 exam they sit under objective 2.5, which expects you to read a scenario and name the attack and its defense. This lesson covers what a replay attack is, how pass-the-hash works, and the main ways MFA is bypassed, along with the nonces, tokens and phishing-resistant methods that stop them.
A replay attack captures something valid and sends it again
A replay attack captures a legitimate piece of authentication data 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. Replay is unusual because CompTIA lists it twice in this objective, once among credential attacks and once among application attacks, because the same idea applies whether the replayed item is a login handshake on the wire or a captured request to a web application.
What gets replayed varies:
- Captured credentials or an authentication exchange. On a protocol that proves identity the same way every time, an attacker who records the exchange can resend it. Older challenge-response schemes and some wireless and smart-card exchanges were vulnerable this way.
- Session tokens and cookies. After you log in, the server issues a session identifier, usually a cookie, that stands in for your credentials for the rest of the session. Anyone who steals that cookie and presents it is treated as you, which is session hijacking by replay.
- A captured request to an application. A "transfer $100" API call or a signed URL captured and resent can repeat the action, which is why this also appears as an application attack.
The indicators are a valid-looking authentication or request that arrives twice, or a session used from two very different places at once. The general defense is to make every exchange unique so that a captured copy is worthless the second time, which the next section covers. Encrypting the channel with TLS also helps, because an attacker who can't capture the token or exchange in the first place has nothing to replay.
Nonces, timestamps and Kerberos tickets make a captured message useless
The cure for replay is to ensure a captured message can't be accepted a second time. Three mechanisms do this, and they appear throughout the course.
A nonce is a number used once. The server issues a fresh, unpredictable value, the client folds it into its response, and the server accepts that response only once. Because the next login uses a different nonce, a replayed response fails. TLS handshakes, modern challenge-response authentication and anti-CSRF tokens all rely on nonces.
A timestamp limits how long a message is valid. If each request carries the current time and the server rejects anything outside a small window, a captured message is useless once the window closes. Timestamps require the two sides to have roughly synchronized clocks, which is one reason accurate time from NTP matters for security.
Kerberos, the authentication protocol behind Windows Active Directory domains, combines both. When a user authenticates, the Key Distribution Center issues time-limited tickets that the user presents to services instead of a password. Each exchange carries an authenticator stamped with the current time, and the service rejects a stale or already-seen one, so a captured ticket exchange can't simply be replayed. This is a good example to remember: if a scenario mentions Kerberos tickets or an authenticator with a timestamp, the design goal is replay resistance. (Clock skew beyond the allowed window is also why Kerberos logins fail when a machine's time drifts.)
Sessions apply the same thinking. Short token lifetimes, rotating a session identifier after login, binding a session to attributes such as the client, and marking cookies HttpOnly, Secure and SameSite all shrink what a stolen token is worth and how long it lasts.