Replay Attacks Flashcards

An attack where the attacker captures legitimate network data and retransmits it later to impersonate the original sender. The data — authentication credentials, session tokens, or transaction requests — was genuine when first transmitted. Systems without freshness validation accept the replay as authentic. The attacker does not need to remain in the communication path during the replay; capture and replay are separate events. Prevented by encryption (denies capture), salting/nonces (makes each credential one-time-use), and session expiry.

A replay attack that authenticates using a captured password hash without knowing the plaintext password. Authentication systems like NTLM transmit a hash of the password rather than the password itself; the server verifies the hash matches its stored value. The attacker captures the username + hash during a legitimate authentication and retransmits it to authenticate as the victim. No password cracking required — the hash is the functional credential. Mitigated by nonce-based challenge-response authentication (each login produces a unique hash that cannot be reused).

Key distinction the exam tests: on-path attacks operate in real-time — the attacker must stay between victims during the attack. Replay attacks are asynchronous — the attacker captures data once and replays it separately, hours or days later, without needing the original communication to still be active. On-path attacks are often the capture method for a replay attack, but the replay itself is independent. The original victim can be completely offline when the replay occurs; the attacker is impersonating them, not intercepting their live traffic.

A unique token issued by a web server after successful authentication, stored in a browser cookie and transmitted with every subsequent HTTP request to maintain the logged-in session. The server accepts a valid session ID as proof of prior authentication — no re-entry of credentials required per request. Whoever presents a valid session ID is treated as the authenticated user. If captured from network traffic or via XSS, the session ID allows impersonation for the lifetime of the session. Protected by HTTPS (prevents network capture), HTTPOnly flag (prevents script theft), Secure flag (HTTPS-only transmission), and short expiry times.

A replay attack where a stolen session token is used to access a web server as an authenticated user — without credentials. "Sidejacking" refers specifically to capturing the session token from network traffic (eavesdropping on the side of the communication). After a user authenticates, the session ID is transmitted with every request; if any of those transmissions are unencrypted, the session ID is exposed. The attacker replays the session ID in their own requests. The server cannot distinguish the attacker's requests from the real user's. Strong passwords are irrelevant — authentication already occurred; only the token matters.

A 2010 Firefox extension that automated one-click session hijacking against users on the same open Wi-Fi network. It captured HTTP session cookies from unencrypted traffic, displayed a list of hijackable accounts (Facebook, Twitter, others) with the users' names and photos, and allowed the attacker to assume any session with a single click. Required no technical skill. Downloaded 2.8 million times in its first month. Its release was a pivotal moment that accelerated the industry shift to HTTPS-everywhere. Today, sites enforcing HTTPS for all traffic prevent Firesheep-style attacks by encrypting all session cookie transmissions.

A defense against pass-the-hash where each authentication uses a unique challenge value (nonce/salt), making every resulting hash one-time-use. The server issues a fresh nonce for each authentication attempt. The client computes Hash(password + nonce). Even if the attacker captures this hash, replaying it fails — the next authentication request will use a different nonce, and the old hash won't match. The server is configured to reject any nonce/hash combination it has already accepted. Salting breaks the core assumption of replay attacks: that captured credentials remain valid for reuse.

Two cookie attributes that protect session IDs: HTTPOnly — prevents JavaScript from reading the cookie value; blocks XSS-based session token theft even if a script is injected into the page. Secure — instructs the browser to only transmit the cookie over HTTPS connections, never HTTP; prevents accidental exposure over unencrypted channels. Both should be set on all session cookies. HTTPOnly addresses the client-side script attack vector; Secure addresses the network transmission attack vector. Neither is a substitute for HTTPS itself, but both add defense-in-depth for session protection.

Three primary methods an attacker uses to capture data for a replay attack: (1) Network tap — physical hardware copies all traffic from a cable segment; requires physical access; very hard to detect. (2) ARP poisoning — redirects victim's traffic through attacker's device using forged ARP replies; requires same subnet; detectable via DAI. (3) Malware on victim's computer — captures authentication data locally on the device before or during transmission; requires malware delivery. The replay itself doesn't specify which capture method was used — any method that produces the credential or token enables the replay.

A partial encryption strategy where traffic is encrypted from the device to a VPN concentrator, protecting the most dangerous segment (untrusted local network) even if end-to-end HTTPS isn't enforced everywhere. Addresses replay attack risk on public Wi-Fi: an attacker monitoring coffee shop or hotel Wi-Fi sees only encrypted VPN tunnel traffic and cannot extract session cookies. Limitation: after the VPN concentrator, traffic may still travel unencrypted to the destination. Best used as a fallback when HTTPS-everywhere isn't achievable, particularly on untrusted networks.