Advisory: Pass-the-Hash — Authentication Bypass via Captured Credential Replay
Executive Summary
A replay attack captures legitimate authentication data transmitted between a client and server during a genuine login, then retransmits that exact data at a later time to the same server. The server has no mechanism to distinguish a fresh authentication from a replay of a previously captured one and accepts the replay as valid. Pass-the-hash is the specific replay attack variant targeting Windows NTLM authentication: the attacker captures a user's password hash from network traffic, then presents that hash directly to the server to authenticate — without knowing the underlying plaintext password. This advisory documents the pass-the-hash mechanism, the capture methods, and the architectural controls that eliminate replay viability.
Why Password Hashes Are Authentication Tokens
Windows NTLM (NT LAN Manager) authentication does not transmit plaintext passwords. When a user authenticates, the client hashes the password using the NT hash function and transmits the hash to the server. The server compares the received hash to the hash stored for that account. If they match, authentication succeeds.
This is a meaningful improvement over transmitting plaintext passwords — the password itself never travels over the network. However, the hash is functionally equivalent to the password from an authentication perspective: whichever party holds the correct hash can authenticate successfully. An attacker who captures the NTLM hash for an account has captured the authentication credential. Cracking the hash to recover the plaintext password is not required — the hash is submitted directly to the authentication endpoint, and the server accepts it.
This is not a bug in a specific implementation — it is a characteristic of challenge-response authentication that does not incorporate per-session freshness values (nonces or salts) into the challenge response.
Attack Sequence
| Phase | Action | Attacker Requirement |
|---|---|---|
| Capture | Attacker captures the NTLM authentication exchange from network traffic during a legitimate user login; exchange contains username and password hash | Network access on the traffic path — ARP poisoning, rogue switch port, compromised network device, or malware on the client performing local capture |
| Extraction | Password hash is extracted from the captured authentication exchange using tools such as Responder, Mimikatz (from memory), or a packet analyzer | Captured network traffic or local access to the victim's system memory where hashes are cached |
| Replay | Attacker submits the captured username and hash to the target authentication server; server receives a valid hash for the claimed username; authentication succeeds | Network access to the authentication endpoint |
| Post-authentication | Attacker has an authenticated session as the victim account; can access all resources the victim account is authorized to access | — |
Detection Indicators
- Authentication success events from source IP addresses or devices inconsistent with the account's normal usage patterns
- Impossible travel: the same account authenticates from two geographically separated locations within a time window that physical travel cannot bridge
- Authentication from accounts at times inconsistent with normal user patterns (2:00–5:00 AM authentication for an account whose owner's work hours are 9:00–17:00)
- Lateral tool activity (Mimikatz process signatures, LSASS memory access patterns) indicating credential harvesting from memory on a compromised host
Recommended Mitigations
- Nonce-based authentication (salting): Configure authentication to incorporate a server-generated nonce (a unique per-session random value) into the challenge-response exchange. The client hashes the password combined with the nonce, producing a response that is valid only for that specific authentication attempt. A captured response cannot be replayed — the nonce was consumed in the original exchange, and the server will generate a different nonce for the next attempt. Kerberos implements this correctly; NTLM without NTLMv2 and extended protection does not.
- Migrate from NTLM to Kerberos: Kerberos uses time-stamped tickets with short validity windows and mutual authentication. Where NTLM is still in use for legacy compatibility, restrict it to only those systems that cannot support Kerberos, and enable NTLMv2 with Extended Protection for Authentication (EPA).
- Encrypt authentication traffic end-to-end: TLS encryption on the authentication channel prevents passive capture of hash exchanges. An attacker monitoring the wire captures ciphertext rather than authentication tokens.
- Least privilege and account segmentation: Limit the scope of damage when a hash is captured. High-privilege accounts (domain admins, service accounts) should not be used for interactive logins on workstations where their credentials might be cached in memory and extractable via Mimikatz-class tools. Tiered administration with separate accounts for administrative tasks limits credential exposure.
Advisory: Session Hijacking via Cookie Theft — Replay of Web Authentication State
Executive Summary
Web applications maintain authenticated state through session IDs — unique tokens stored in browser cookies and transmitted with every request to the server. A user who authenticates once is identified for all subsequent requests by their session ID rather than re-submitting credentials. Whoever holds a valid session ID holds the authenticated session: an attacker who captures the session cookie can impersonate the victim for the lifetime of that session without knowing the account password. Session hijacking — also called sidejacking — is the replay attack variant targeting this web session layer. The 2010 Firesheep demonstration made this vulnerability visible to a non-technical audience and directly drove the HTTPS adoption that largely eliminated the most accessible form of the attack.
Technical Analysis — The Session ID as Authentication Credential
After a user authenticates to a web application, the server creates a session record and generates a session ID — a long, random string (e.g., 3B80027A38FDF37C4A9D2E5...). The session ID is sent to the browser as a cookie. On every subsequent HTTP request to the same site, the browser automatically includes the cookie in the request headers. The server looks up the session ID, confirms it belongs to an active, authenticated session, and responds accordingly. The user stays logged in because the browser presents the session token, not because authentication is being repeated.
Security implication: the session ID is the authentication credential for the duration of the session. Stealing the session ID is functionally equivalent to logging in. The attacker does not need the password — they need only to present the session ID in their own HTTP requests to the server, and the server treats them as the authenticated user.
Case Study — Firesheep (October 2010)
In October 2010, security researcher Eric Butler released Firesheep, a Firefox browser extension that automated session hijacking against users on the same open Wi-Fi network. Firesheep used passive packet capture to monitor unencrypted HTTP traffic. When it detected a session cookie for a recognized site (Facebook, Twitter, Amazon, and others) in the plaintext traffic of another user on the network, it displayed that user's name and profile picture in a sidebar. Clicking the user's entry in the sidebar caused Firesheep to extract the session cookie from the captured traffic and replay it against the site, logging the attacker in as the victim — with one click, no technical knowledge required.
Firesheep worked because those sites transmitted session cookies over unencrypted HTTP, even after the initial HTTPS login. A user would authenticate over HTTPS, but all subsequent page browsing was over HTTP — and the session cookie traveled in plaintext with every HTTP request. Any device on the same open Wi-Fi network could read those requests and extract the cookie.
The industry response was rapid and sustained: within 18 months of Firesheep's release, Facebook, Twitter, and most major web platforms had moved to HTTPS by default for all pages, not only the login page. Firesheep accelerated a transition that had been technically available for years but had stalled due to the perceived overhead of TLS encryption.
Session Cookie Capture Methods
| Method | Mechanism | Applicable Scenario |
|---|---|---|
| Passive network capture | Wireshark, Kismet, or similar tools collect unencrypted HTTP traffic on shared network segment; session IDs visible in Cookie request headers | Open Wi-Fi, shared Ethernet hub, or ARP-poisoned network segment; requires HTTP (not HTTPS) |
| Cross-site scripting (XSS) | Injected JavaScript executes in the context of the legitimate site and reads document.cookie; transmits cookie value to attacker server | Any site with an XSS vulnerability; effective even over HTTPS — attacker reads the cookie from within the victim's browser |
| ARP poisoning + HTTP interception | ARP poisoning redirects victim's traffic through attacker; attacker reads session cookies from HTTP requests in transit | Local network with ARP poisoning capability; requires HTTP |
| Physical access to browser storage | Direct access to browser cookie storage files on victim's device | Physical device access or malware with file system read capability |
Recommended Mitigations
- HTTPS everywhere (end-to-end): The primary defense against network-capture-based session hijacking. Encrypting all HTTP traffic — not just the login page — prevents passive observers from reading session cookies in transit. Session cookies transmitted over HTTPS are encrypted in the TLS tunnel and cannot be extracted from network captures. Modern browsers and frameworks default to HTTPS, and HTTP Strict Transport Security (HSTS) prevents downgrade attacks.
- Secure cookie flag: The
Secureflag on a session cookie instructs the browser to transmit the cookie only over HTTPS connections — never over HTTP. Prevents accidental cookie exposure if a user navigates to an HTTP URL. Implement on all session cookies at the server configuration level. - HTTPOnly cookie flag: The
HTTPOnlyflag prevents JavaScript from reading the cookie value. Blocks XSS-based cookie theft — an injected script that runsdocument.cookiereceives an empty string for HTTPOnly-flagged cookies. Implement alongside the Secure flag for all session cookies. - Short session lifetimes with inactivity timeout: A session ID that expires after 15–30 minutes of inactivity limits the window in which a captured token remains useful. Combined with binding sessions to the originating IP and User-Agent string, replayed sessions from a different device context can be detected and invalidated.