Replay Attack vs. On-Path Attack — Key Differences
| Property | On-Path Attack | Replay Attack |
|---|---|---|
| Attacker Position | Must remain between victims during the attack | Captures data once; replays later — no ongoing positioning required |
| Timing | Real-time — intercepts communication as it happens | Asynchronous — capture and replay are separate events, potentially hours or days apart |
| Original Connection Required? | Yes — attack operates on the live connection | No — replay can happen after the original session ends, with the original victim offline |
| What Is Captured | All traffic in both directions | Specific valuable data: auth credentials, session tokens, transaction data |
| Modification Capability | Can read and modify traffic in transit | Replays original captured data — no modification (the data is valid as-is) |
| Relationship | Often used as the capture method for a replay attack | Often uses on-path capture as its data gathering phase |
| Primary Defense | DAI, network segmentation, HTTPS | Encryption (deny capture), salting/nonces (invalidate replayed tokens) |
Replay Attack — General Flow
1. Target identification — attacker identifies valuable network traffic to target: authentication exchanges, session token transmissions, or financial transaction requests
2. Data capture — attacker obtains raw network data using: network tap (physical), ARP poisoning (redirects traffic through attacker), or malware on victim's device (captures locally before transmission)
3. Data extraction — attacker identifies the valuable component from the captured traffic: password hash, session ID, transaction token
4. Storage — attacker stores the captured credential; the original session may have ended, the victim may be offline — the replayed credential is stored independently
5. Replay — attacker retransmits the captured data to the target server, impersonating the original sender; server has no mechanism to distinguish fresh credential from replayed one and grants access
6. Access — attacker operates on the server with the victim's authentication level; the victim is unaware their credential has been replayed
Pass-the-Hash — Step by Step
1. Normal user authentication begins — victim's client computer prepares an authentication request; the password is hashed locally (e.g., NTLM hash), and the username + hash are transmitted to the server
2. Attacker intercepts the exchange — during transmission, attacker captures a copy of the authentication exchange (via ARP poisoning, network tap, or malware); attacker receives: username + hashed password — identical to what the server receives
3. Legitimate authentication completes — the real user's username + hash reaches the server; server verifies the hash matches its stored hash; authentication succeeds; victim is now logged in
4. Attacker stores the hash — attacker now holds a valid username + hash pair; the plaintext password is unknown and irrelevant; the hash is the functional credential
5. Replay authentication — attacker sends their own authentication request to the server containing the captured username + hash; server receives a valid username/hash pair; no mechanism to detect the replay; authentication succeeds
6. Attacker has server access — attacker is now authenticated as the victim; full access to whatever the victim's account can reach on the server
Why Pass-the-Hash Works: The Hash IS the Credential
In authentication systems that transmit hashed passwords (such as NTLM), the hash is what the server actually validates. The server stores a hash of the password and compares incoming hashes against it. The server never sees the plaintext password during authentication — only the hash.
This means the hash is functionally equivalent to the password for authentication purposes. You don't need to reverse the hash (which is computationally infeasible for strong hash functions) — you just need to present the hash directly. The server cannot tell whether the hash was generated from a password typed by the real user, or extracted from captured network traffic by an attacker.
The fix — salting with nonces: The server issues a unique challenge value (nonce/salt) for each authentication attempt. The client incorporates this nonce into the hash computation. Even if the attacker captures the resulting hash, it is only valid for that specific nonce — which the server never issues again. Replaying the hash in a new authentication attempt fails because the new authentication will have a different nonce, and the old hash doesn't match it.
Session Hijacking — Web Session Flow
1. User authenticates — victim provides username and password to the web server; server verifies credentials
2. Server creates session ID — server generates a unique, random session identifier (e.g., "3B80027A38FDF37C..."); stores it server-side as representing an authenticated session for this user
3. Session ID delivered to browser — server sends the session ID to the browser in an HTTP Set-Cookie header; browser stores it as a cookie
4. Browser uses session ID for subsequent requests — every subsequent HTTP request the browser makes to this site automatically includes the Cookie header with the session ID; server looks up the session ID and responds as the authenticated user
5. Attacker captures session ID — if the session ID is transmitted over unencrypted HTTP, the attacker passively captures it from network traffic; tools: Wireshark, Kismet, Firesheep; XSS can also steal it from within the browser
6. Attacker replays session ID — attacker crafts HTTP requests including the stolen session ID in the Cookie header; server recognizes valid session ID; responds as if attacker were the authenticated victim
Data Capture Methods Compared
| Method | How It Works | Requires | Detectable? |
|---|---|---|---|
| Network Tap | Physical hardware device copies all traffic from a cable segment to the attacker | Physical access to network cabling/equipment | Very difficult — produces no network traffic; hardware-only detection |
| ARP Poisoning | Corrupts ARP caches to redirect victim's traffic through attacker's device | Same subnet as victim; no password | Yes — anomalous ARP traffic in packet capture; DAI will block it |
| Malware on Victim | Software on victim's computer captures data before/during transmission | Malware delivery (phishing, drive-by); local device access | Endpoint detection; behavioral analysis |
| Passive Wi-Fi Capture | Monitor mode adapter captures all traffic on open/shared Wi-Fi | Physical proximity to Wi-Fi network | Difficult — passive only; no transmission required from attacker |
| Cross-Site Scripting | Injected script steals cookie from inside the victim's browser | XSS vulnerability on target site; victim visits page | Requires server-side detection of XSS; CSP can block script execution |
Header Manipulation Tools
| Tool | Type | What It Does |
|---|---|---|
| Wireshark | Packet capture (passive) | Captures and analyzes all network packets; displays HTTP headers, cookie values, session tokens in plaintext from unencrypted traffic |
| Kismet | Wireless packet capture (passive) | Captures wireless traffic; identifies devices, APs, and unencrypted communications including session cookies on open Wi-Fi |
| Firesheep | Browser extension (session capture) | Automated session cookie capture on shared Wi-Fi; one-click session hijacking against sites using HTTP; now largely ineffective due to HTTPS-everywhere |
| Tamper | Browser extension (request modification) | Intercepts and modifies browser HTTP requests; allows manual editing of headers and cookies before they are sent to the server |
| Scapy | Packet manipulation library (Python) | Constructs arbitrary network packets from scratch; used to forge HTTP requests with stolen session tokens in Cookie headers |
| Cookies Manager+ | Firefox add-on (cookie editing) | Allows direct viewing and editing of all stored browser cookies; used to inject stolen session ID values for replay |
Defense Stack
| Control | Attack Addressed | How |
|---|---|---|
| HTTPS / TLS (end-to-end) | Session ID capture via network monitoring | Encrypts all traffic including cookie headers; attacker captures only ciphertext; session IDs are never transmitted in plaintext |
| VPN (end-to-somewhere) | Session ID capture on untrusted networks | Encrypts traffic from device to VPN concentrator; protects the most vulnerable segment (public Wi-Fi); partial coverage only |
| Salting / Nonce-based auth | Pass-the-hash replay | Each authentication uses a unique challenge; hash is valid only for that challenge; previously captured hashes cannot be replayed |
| HTTPOnly cookie flag | XSS-based session cookie theft | Prevents JavaScript from reading cookie values; injected scripts cannot extract session IDs even if XSS succeeds |
| Secure cookie flag | Session ID exposure over HTTP | Browser only transmits cookie over HTTPS; prevents accidental exposure if HTTP version of site is visited |
| Short session lifetimes | Session ID replay | Session IDs expire quickly; reduces window during which a captured session ID remains valid for replay |
| Session binding (IP/UA) | Session ID replay from different device | Server ties session to originating IP or user-agent; replaying from a different device triggers invalidation or re-authentication |
| Encryption of auth traffic | Pass-the-hash | If authentication exchange is encrypted, attacker captures ciphertext rather than usable username/hash pairs |