Replay Attacks in Practice

Example 1 · Pass-the-Hash Attack Walkthrough

A step-by-step walkthrough of a pass-the-hash replay attack on a Windows network authentication system.

Network setup:

• Finance employee workstation: authenticating to an internal file server
• Authentication protocol: NTLM (transmits username + NTLM hash of the password)
• Attacker's device: on the same subnet, running ARP poisoning to intercept authentication traffic

Phase 1 — Attacker positions for capture:

The attacker runs an ARP poisoning attack (as described in Chapter 48) to redirect traffic between the finance workstation and the file server through their device. The file server's IP now maps to the attacker's MAC in the workstation's ARP cache, and vice versa.

Phase 2 — Legitimate authentication occurs:

At 4:15 PM, the finance employee logs into the file server. The workstation sends an NTLM authentication exchange:

• Username: finance_user
• NTLM hash: 5f4dcc3b5aa765d61d8327deb882cf99 (the hash of the actual password)

This exchange passes through the attacker's device. The attacker records: username "finance_user" and hash "5f4dcc3b5aa765d61d8327deb882cf99". The attacker also relays the exchange to the real file server. The legitimate authentication succeeds. The employee has no indication anything unusual occurred.

Phase 3 — Attacker replays the hash:

At 2:47 AM, the employee is on a plane. The attacker sends their own NTLM authentication request to the file server:

• Username: finance_user
• NTLM hash: 5f4dcc3b5aa765d61d8327deb882cf99

The file server receives a valid username/hash pair. The hash matches the stored hash for "finance_user." Authentication succeeds. The attacker now has full access to the file server as the finance employee.

Why the attack worked:

The file server had no way to distinguish the 2:47 AM authentication from the 4:15 PM authentication. Same username, same hash, same result. The server's job is to verify the hash matches — it did. No mechanism existed to ask "has this exact hash/nonce pair been used before?" or "does this authentication request match an expected context?"

What would have stopped it:

If the file server used challenge-response authentication with a nonce (a unique challenge issued by the server for each authentication attempt), the client would compute the hash as: Hash(password + nonce). Each authentication produces a different hash — even for the same password. The attacker's captured hash (computed with the 4:15 PM nonce) is useless for the 2:47 AM authentication (which will use a different nonce).

Example 2 · Firesheep and the HTTPS Wake-Up Call

The story of Firesheep illustrates why session hijacking on open Wi-Fi was a widespread, easily exploitable vulnerability — and how it was mitigated at scale.

The vulnerability (2010):

When a user logged into Facebook at a coffee shop's open Wi-Fi, the login itself used HTTPS — the password was protected. But after authentication, Facebook issued a session cookie over HTTP. Every subsequent page request — clicking links, loading the news feed, posting status updates — transmitted that session cookie in plaintext over the open Wi-Fi network.

Any device on the same Wi-Fi network with a wireless adapter in monitor mode could capture all of this traffic. The session cookie was right there in the HTTP headers of every single request, completely unencrypted.

What Firesheep did:

Eric Butler released Firesheep at a developer conference in October 2010. It was a Firefox extension that automated the entire session hijacking process:

1. User opens Firesheep on a laptop connected to any open Wi-Fi network
2. Firesheep passively monitors all Wi-Fi traffic on the network
3. For any user it detects logging into a supported site (Facebook, Twitter, Amazon, etc.), it extracts the session cookie
4. The session cookie appears as a clickable tile in the Firesheep sidebar with the user's name and profile photo
5. Click the tile → Firesheep injects the session cookie into Firefox → you are now logged in as that person on that site

No technical knowledge required. No tools to configure. The entire session hijacking process reduced to a single click.

The impact:

Firesheep was downloaded over 2.8 million times in the first month. It demonstrated, irrefutably, that sitting at any coffee shop with open Wi-Fi meant anyone could be logged into your social media accounts if those sites were using HTTP for post-login traffic. The response from the industry was rapid: Facebook, Twitter, and others moved to HTTPS-everywhere within months — encrypting all traffic including post-login pages and cookie transmission.

Why it doesn't work the same way today:

Modern sites that enforce HTTPS for all traffic (not just login) ensure that session cookies are only transmitted over encrypted connections. An attacker monitoring Wi-Fi traffic captures TLS ciphertext — the session cookie is inside the encrypted tunnel and cannot be extracted. Firesheep's specific automation became useless, though the underlying technique (session cookie capture on unencrypted traffic) remains valid wherever HTTPS is not enforced.

Example 3 · The Personal VPN Use Case

Why a personal VPN addresses session hijacking on public networks — and what its limitations are.

Scenario without VPN:

A consultant connects her laptop to a hotel's open Wi-Fi. She opens her company's internal web portal, which still uses HTTP for some features. Her session cookie is transmitted in plaintext. An attacker sitting in the hotel lobby with a Wi-Fi monitoring setup captures her session token and uses it to access the company portal as her.

Scenario with personal VPN:

The consultant connects to a personal VPN service before accessing anything. Her device establishes an encrypted tunnel to the VPN concentrator (a server elsewhere on the internet). All her traffic is encapsulated in this encrypted tunnel before leaving her device.

An attacker on the hotel Wi-Fi monitoring traffic sees only: encrypted VPN tunnel traffic from her device to the VPN server. The attacker cannot see what sites she's visiting, what data she's sending, or what cookies she's transmitting. The session cookie for the company portal is never visible on the hotel network.

The limitation:

After the VPN concentrator, traffic continues to the destination server. If the connection between the VPN concentrator and the company portal is unencrypted HTTP, someone monitoring that segment could capture the session cookie. But the most dangerous interception point — the untrusted hotel network, where the attacker is physically present — is protected. This is the "encrypt end-to-somewhere" model: not perfect, but eliminating the highest-risk exposure point.

VPN vs. HTTPS:

A VPN protects the local network segment; HTTPS protects the entire transmission end-to-end. HTTPS-everywhere is the better defense when achievable. A VPN is the appropriate fallback when connecting to services that don't fully enforce HTTPS, or when the network itself is untrusted (public Wi-Fi, hotel networks, conference center networks).

Exam Scenario 1 · Identifying a Replay Attack

Scenario: An IT administrator reviews authentication logs and finds that a server shows two successful logins for the same user account within a four-hour window. The first login was at 3:00 PM and ended when the user logged out at 5:30 PM. The second login appeared at 7:45 PM, using the same credential hash, originating from a different IP address. The user confirms they did not log in at 7:45 PM.

Question: What attack has occurred, and what should the investigation focus on?

Answer: This is a pass-the-hash replay attack. The second login used the same credential hash as the first, from a different IP — consistent with an attacker who captured the hash during the 3:00 PM authentication and replayed it from their own device at 7:45 PM. The investigation should focus on: (1) how the hash was captured during the 3:00 PM session — was there anomalous ARP traffic, an unknown device on the network, or malware on the user's workstation; (2) what the 7:45 PM session accessed — what data was touched during the unauthorized session; (3) whether authentication is using challenge-response with unique nonces that would invalidate replay attacks going forward.

Exam Scenario 2 · Session Hijacking on Open Wi-Fi

Scenario: A security researcher sets up a demonstration at a conference. She connects to the conference's open Wi-Fi and runs Wireshark in monitor mode. Within ten minutes, she extracts five distinct session tokens from HTTP traffic visible on the network. She uses one of these session tokens to access a popular project management site as one of the conference attendees, verifying the vulnerability without viewing any private data. The attendee used a strong, unique 20-character password. The site enforces HTTPS for its login page but not for authenticated sessions.

Question: What vulnerability allowed this, and why did the strong password provide no protection?

Answer: The site issued session cookies over HTTP after login. Once authenticated, all subsequent page requests transmitted the session token in plaintext. Wireshark captured these tokens passively from the open Wi-Fi traffic. The strong password was irrelevant because the session token, once issued, is accepted by the server as proof of prior authentication — the server never asks the user to re-authenticate for each request. The attacker presented a valid session token, and the server treated them as the authenticated user. The password's strength only mattered during the initial authentication; it provides no protection against token theft after authentication succeeds. Fix: enforce HTTPS for all traffic (not just login), and set the Secure flag on session cookies to prevent them from being transmitted over HTTP.

Exam Scenario 3 · Choosing the Right Defense

Scenario: A company is reviewing its authentication infrastructure. Three issues have been identified: (A) internal Windows file server authentication uses NTLM without challenge-response nonces; (B) the company intranet portal transmits session cookies over HTTP; (C) employees routinely work from coffee shops on open Wi-Fi without any encryption. The company wants to address each issue with the most targeted and effective control.

Question: Match the correct primary control to each issue.

Answer:

Issue A (NTLM without nonces): Upgrade to challenge-response authentication that incorporates a server-generated nonce into each authentication exchange (e.g., NTLMv2 or Kerberos, which includes timestamps and nonce values). This ensures each authentication hash is unique and previously captured hashes cannot be replayed.

Issue B (session cookies over HTTP): Enforce HTTPS for all pages, not just login, and set the Secure and HTTPOnly flags on session cookies. This prevents session tokens from being transmitted in plaintext and prevents JavaScript from reading them. This directly addresses Firesheep-style session hijacking.

Issue C (coffee shop Wi-Fi): Mandate use of a corporate or personal VPN when connecting from untrusted public networks. This encrypts the highest-risk network segment (the local Wi-Fi) and prevents passive capture of any traffic from the employee's device on the shared network.