Trick 1: "A replay attack is a type of on-path attack because it requires the attacker to intercept network traffic while positioned between two communicating devices." True or False?
FALSE — a replay attack is not an on-path attack, though an on-path position is one method for capturing the data that will later be replayed.
This is one of the most precisely tested distinctions in this chapter. The source material states it explicitly: "The replay itself is not an on-path attack."
The relationship between the two:
To perform a replay attack, the attacker needs captured network data. One way to capture that data is through an on-path attack (ARP poisoning, network tap, etc.) — the attacker positions themselves in the communication path to observe traffic. But this is the capture phase, not the replay itself. Once the attacker has the credential or session token, they end the on-path positioning and replay the captured data at a completely separate time, from their own system, directly to the server — no interception required.
Why the distinction matters:
An on-path attack requires continuous presence between victims. A replay attack can occur with the original victim completely offline, anywhere in the world. The original session can have ended hours ago. The attacker is not "between" anyone — they're simply presenting previously captured credentials directly to the target server. Recognizing this timing difference is essential for both identifying attacks and choosing defenses: on-path defenses (DAI, network segmentation) stop the interception phase; replay-specific defenses (salting, nonces, session expiry) stop the replay phase itself.
Exam tip: If a question says an attacker "captured credentials earlier and is now authenticating as the victim from a separate device while the victim is offline" — that's a replay attack, not an on-path attack. The "while the victim is offline" detail is the clearest signal.
This is one of the most precisely tested distinctions in this chapter. The source material states it explicitly: "The replay itself is not an on-path attack."
The relationship between the two:
To perform a replay attack, the attacker needs captured network data. One way to capture that data is through an on-path attack (ARP poisoning, network tap, etc.) — the attacker positions themselves in the communication path to observe traffic. But this is the capture phase, not the replay itself. Once the attacker has the credential or session token, they end the on-path positioning and replay the captured data at a completely separate time, from their own system, directly to the server — no interception required.
Why the distinction matters:
An on-path attack requires continuous presence between victims. A replay attack can occur with the original victim completely offline, anywhere in the world. The original session can have ended hours ago. The attacker is not "between" anyone — they're simply presenting previously captured credentials directly to the target server. Recognizing this timing difference is essential for both identifying attacks and choosing defenses: on-path defenses (DAI, network segmentation) stop the interception phase; replay-specific defenses (salting, nonces, session expiry) stop the replay phase itself.
Exam tip: If a question says an attacker "captured credentials earlier and is now authenticating as the victim from a separate device while the victim is offline" — that's a replay attack, not an on-path attack. The "while the victim is offline" detail is the clearest signal.
Trick 2: "Multi-factor authentication (MFA) prevents replay attacks — because even if the attacker captures the password hash, they would also need the second factor to authenticate." True or False?
FALSE — MFA prevents credential-based replay attacks against initial authentication, but provides no protection against session token replay attacks once authentication has succeeded.
This trick works because it sounds logically complete. If MFA prevents unauthorized logins, surely it prevents replay attacks? The answer depends entirely on what is being replayed.
Where MFA helps:
If the replay attack targets the authentication phase — for example, pass-the-hash where the attacker is replaying a captured username/hash to log in — then MFA adds a barrier. Even with the hash, the attacker also needs the second factor (TOTP code, push notification, hardware key). This is meaningful protection.
Where MFA does not help:
Once a user authenticates (including the MFA step), the server issues a session ID. From that point forward, the session ID is the authentication token. The password and MFA code are no longer relevant to the active session — they were consumed at login. If the attacker captures the session ID (from unencrypted HTTP, via XSS, via Firesheep on a coffee shop Wi-Fi), they can replay it to the server. The server accepts it. MFA is not asked for again. The attacker has full access to everything the victim's session can reach, with no second factor required.
The attack surface MFA can't reach:
Session ID replay, Firesheep-style sidejacking, and any post-authentication token theft bypass MFA completely because they target the session token rather than the credentials. The only effective defense against session token replay is HTTPS (deny capture), short session lifetimes (limit replay window), and HTTPOnly/Secure cookie flags (protect the token itself).
Exam tip: Answer choices that say "MFA prevents all replay attacks" or "MFA protects session tokens" are wrong. MFA is a control for the authentication phase only. Session-phase attacks require session-phase defenses.
This trick works because it sounds logically complete. If MFA prevents unauthorized logins, surely it prevents replay attacks? The answer depends entirely on what is being replayed.
Where MFA helps:
If the replay attack targets the authentication phase — for example, pass-the-hash where the attacker is replaying a captured username/hash to log in — then MFA adds a barrier. Even with the hash, the attacker also needs the second factor (TOTP code, push notification, hardware key). This is meaningful protection.
Where MFA does not help:
Once a user authenticates (including the MFA step), the server issues a session ID. From that point forward, the session ID is the authentication token. The password and MFA code are no longer relevant to the active session — they were consumed at login. If the attacker captures the session ID (from unencrypted HTTP, via XSS, via Firesheep on a coffee shop Wi-Fi), they can replay it to the server. The server accepts it. MFA is not asked for again. The attacker has full access to everything the victim's session can reach, with no second factor required.
The attack surface MFA can't reach:
Session ID replay, Firesheep-style sidejacking, and any post-authentication token theft bypass MFA completely because they target the session token rather than the credentials. The only effective defense against session token replay is HTTPS (deny capture), short session lifetimes (limit replay window), and HTTPOnly/Secure cookie flags (protect the token itself).
Exam tip: Answer choices that say "MFA prevents all replay attacks" or "MFA protects session tokens" are wrong. MFA is a control for the authentication phase only. Session-phase attacks require session-phase defenses.
Trick 3: "Pass-the-hash attacks require the attacker to crack the password hash to recover the plaintext password before they can use it for authentication." True or False?
FALSE — the defining feature of pass-the-hash is that no cracking is required. The hash itself is the authentication credential.
This misconception is extremely common and is why the attack is specifically named "pass-the-hash" rather than "crack-the-hash." The name literally describes what happens: the hash is passed to the server as-is.
Why the hash works without cracking:
Authentication systems like NTLM were designed to avoid transmitting plaintext passwords. The client hashes the password and sends the hash; the server compares the incoming hash against its stored hash. The server never sees the plaintext password during authentication. This means the hash is what the server actually validates.
An attacker who captures the hash has the exact value the server is checking. They don't need to know what password produced the hash — they just need to send the hash. The server receives it, compares it to the stored value, finds a match, and grants access. The plaintext password is irrelevant to the server's validation logic.
Why this confuses people:
We think of passwords as the credential and hashes as a representation we need to decode. But in authentication systems that operate this way, the hash IS the credential. The password is just a human-friendly way to generate the hash at login time. The server never needs the password — only the hash.
The correct attack requirement:
Pass-the-hash requires: (1) capturing the username and hash from network traffic; (2) a way to replay authentication (Impacket's psexec, mimikatz, etc.); (3) the hash value itself — nothing else. No password required. No cracking required.
Exam tip: Any answer that says pass-the-hash "requires cracking the hash" or "requires knowing the plaintext password" is wrong. The entire point of the attack is that neither is needed.
This misconception is extremely common and is why the attack is specifically named "pass-the-hash" rather than "crack-the-hash." The name literally describes what happens: the hash is passed to the server as-is.
Why the hash works without cracking:
Authentication systems like NTLM were designed to avoid transmitting plaintext passwords. The client hashes the password and sends the hash; the server compares the incoming hash against its stored hash. The server never sees the plaintext password during authentication. This means the hash is what the server actually validates.
An attacker who captures the hash has the exact value the server is checking. They don't need to know what password produced the hash — they just need to send the hash. The server receives it, compares it to the stored value, finds a match, and grants access. The plaintext password is irrelevant to the server's validation logic.
Why this confuses people:
We think of passwords as the credential and hashes as a representation we need to decode. But in authentication systems that operate this way, the hash IS the credential. The password is just a human-friendly way to generate the hash at login time. The server never needs the password — only the hash.
The correct attack requirement:
Pass-the-hash requires: (1) capturing the username and hash from network traffic; (2) a way to replay authentication (Impacket's psexec, mimikatz, etc.); (3) the hash value itself — nothing else. No password required. No cracking required.
Exam tip: Any answer that says pass-the-hash "requires cracking the hash" or "requires knowing the plaintext password" is wrong. The entire point of the attack is that neither is needed.
Trick 4: "Browser cookies are a security risk because they are executable files that can run malicious code on the user's computer." True or False?
FALSE — cookies are data files, not executable programs. They cannot run code. The security risk they present is the sensitive data they contain, particularly session IDs.
This trick appears basic, but the exam does test whether you understand what makes cookies dangerous — and it's not executability.
What cookies actually are:
A cookie is a small text file (or in-memory data structure) stored by the browser containing key-value pairs set by websites. A typical session cookie contains something like: "sessionid=3B80027A38FDF37C...". That's it — just text. The browser doesn't execute cookies. They don't contain code. They can't install malware. They can't spawn processes.
What makes cookies dangerous:
The danger is entirely in the data they hold. Specifically: session IDs. A session ID is a functional authentication token. Any system that receives a valid session ID treats the presenter as the authenticated user — no re-authentication required. An attacker who obtains a session ID from your cookie doesn't need to execute anything on your computer; they just include that value in their own HTTP request headers and the server welcomes them as you.
The two ways attackers target cookies:
(1) Network capture — if session cookies are transmitted over unencrypted HTTP, tools like Wireshark and Firesheep capture them from the network; the attacker never touches the user's computer. (2) Cross-site scripting — injected JavaScript running in the victim's browser can read cookie values (unless HTTPOnly flag is set) and send them to the attacker's server; this requires a server-side vulnerability, not malware on the endpoint.
Exam tip: "Cookies are dangerous because they can execute code" is always wrong. "Cookies are dangerous because they contain session IDs that can be stolen and replayed" is always correct. Keep the security risk conceptually separate from the technical mechanism.
This trick appears basic, but the exam does test whether you understand what makes cookies dangerous — and it's not executability.
What cookies actually are:
A cookie is a small text file (or in-memory data structure) stored by the browser containing key-value pairs set by websites. A typical session cookie contains something like: "sessionid=3B80027A38FDF37C...". That's it — just text. The browser doesn't execute cookies. They don't contain code. They can't install malware. They can't spawn processes.
What makes cookies dangerous:
The danger is entirely in the data they hold. Specifically: session IDs. A session ID is a functional authentication token. Any system that receives a valid session ID treats the presenter as the authenticated user — no re-authentication required. An attacker who obtains a session ID from your cookie doesn't need to execute anything on your computer; they just include that value in their own HTTP request headers and the server welcomes them as you.
The two ways attackers target cookies:
(1) Network capture — if session cookies are transmitted over unencrypted HTTP, tools like Wireshark and Firesheep capture them from the network; the attacker never touches the user's computer. (2) Cross-site scripting — injected JavaScript running in the victim's browser can read cookie values (unless HTTPOnly flag is set) and send them to the attacker's server; this requires a server-side vulnerability, not malware on the endpoint.
Exam tip: "Cookies are dangerous because they can execute code" is always wrong. "Cookies are dangerous because they contain session IDs that can be stolen and replayed" is always correct. Keep the security risk conceptually separate from the technical mechanism.
Performance Task: You are a security engineer at a company that has just experienced an incident: a server log shows an authenticated session for "dept_head_rivers" at 11:47 PM — but the department head left the office at 6:00 PM and confirms she did not access the server that evening. The same account authenticated successfully at 5:45 PM (the last legitimate session before she left). IT confirms the server uses NTLM authentication without salting, and the internal network is a flat /16 with all devices on the same VLAN. Describe your investigation steps, identify the most likely attack type, explain how the attacker captured the credentials, and provide a prioritized remediation plan addressing both the immediate compromise and the underlying vulnerability.
Model Answer:
Step 1 — Confirm the Attack Type:
The pattern is diagnostic: same account, same authentication hash, two sessions separated by hours with the victim offline for the second. This is a pass-the-hash replay attack. The attacker captured the username and NTLM hash during the 5:45 PM authentication and replayed it at 11:47 PM. No password cracking was needed — NTLM authentication accepts the hash as the credential, and the server had no mechanism to detect the replay.
Confirm by: reviewing NTLM authentication logs to verify the second authentication used an identical hash value; checking the source IP of the 11:47 PM authentication — if it's different from the department head's workstation IP, that's the attacker's device.
Step 2 — Identify the Capture Method:
Three candidates, given the flat /16 network:
(A) ARP poisoning — the attacker redirected 5:45 PM authentication traffic through their device. Run
(B) Network tap — physical device installed on the cable between the workstation and the switch. Check for unexpected hardware on the cable path; physical security review of accessible network points near the department head's workspace.
(C) Malware on workstation — keylogger or credential-harvesting malware capturing authentication data locally. Run endpoint security analysis on the workstation; check for unexpected processes, recently installed software, or network connections to external IPs.
The flat /16 VLAN makes ARP poisoning trivially easy — this would be the most likely first hypothesis given the network architecture.
Step 3 — Contain and Investigate the 11:47 PM Session:
(1) Immediately revoke all active sessions for "dept_head_rivers" and force re-authentication; (2) Review server access logs for what the 11:47 PM session accessed, modified, or exfiltrated — the attacker had authenticated access, so data impact must be assessed; (3) Preserve all logs — NTLM auth logs, network logs, switch ARP logs, endpoint telemetry — before rotation or overwrite.
Prioritized Remediation:
Priority 1 — Immediately address the capture vulnerability:
Enable Dynamic ARP Inspection (DAI) on the managed switches with DHCP snooping. This directly prevents ARP poisoning as a capture method on the flat network. Even before the authentication protocol is improved, this removes the most accessible capture technique.
Priority 2 — Address the replay vulnerability:
Migrate authentication to NTLMv2 (which incorporates a timestamp and client nonce, making each response unique and preventing direct hash replay) or, preferably, Kerberos (which incorporates timestamps by default — replaying a Kerberos ticket outside a short time window fails). Both prevent pass-the-hash by ensuring each authentication token is session-specific and time-limited.
Priority 3 — Network segmentation:
A flat /16 where all 65,000+ possible IP addresses share a single ARP domain is an architectural risk for ARP-based attacks. Segment the network into VLANs organized by function (workstations, servers, management, guests). Place the server in its own VLAN with a routed boundary — ARP poisoning from a workstation cannot cross the VLAN boundary.
Priority 4 — Encrypt authentication traffic:
Require SMB signing (which encrypts and authenticates SMB traffic, preventing NTLM hash capture from file server connections) and consider deploying a PKI to support certificate-based authentication, eliminating hash-based auth entirely.
Priority 5 — Endpoint detection:
Deploy or update endpoint detection and response (EDR) on all workstations to detect credential harvesting malware and anomalous authentication activity.
On the "flat network" finding:
The flat /16 is not just an ARP poisoning risk — it means every device can directly communicate with every other device, expanding the blast radius of any compromise. The segmentation recommendation isn't optional; it's the foundational network architecture control that limits the damage any single compromised device can cause. Document this as a critical finding separate from the immediate incident.
Step 1 — Confirm the Attack Type:
The pattern is diagnostic: same account, same authentication hash, two sessions separated by hours with the victim offline for the second. This is a pass-the-hash replay attack. The attacker captured the username and NTLM hash during the 5:45 PM authentication and replayed it at 11:47 PM. No password cracking was needed — NTLM authentication accepts the hash as the credential, and the server had no mechanism to detect the replay.
Confirm by: reviewing NTLM authentication logs to verify the second authentication used an identical hash value; checking the source IP of the 11:47 PM authentication — if it's different from the department head's workstation IP, that's the attacker's device.
Step 2 — Identify the Capture Method:
Three candidates, given the flat /16 network:
(A) ARP poisoning — the attacker redirected 5:45 PM authentication traffic through their device. Run
arp -a on the department head's workstation and the server — look for the server's IP mapped to an unexpected MAC. Review switch logs for anomalous ARP traffic around 5:30–5:50 PM.(B) Network tap — physical device installed on the cable between the workstation and the switch. Check for unexpected hardware on the cable path; physical security review of accessible network points near the department head's workspace.
(C) Malware on workstation — keylogger or credential-harvesting malware capturing authentication data locally. Run endpoint security analysis on the workstation; check for unexpected processes, recently installed software, or network connections to external IPs.
The flat /16 VLAN makes ARP poisoning trivially easy — this would be the most likely first hypothesis given the network architecture.
Step 3 — Contain and Investigate the 11:47 PM Session:
(1) Immediately revoke all active sessions for "dept_head_rivers" and force re-authentication; (2) Review server access logs for what the 11:47 PM session accessed, modified, or exfiltrated — the attacker had authenticated access, so data impact must be assessed; (3) Preserve all logs — NTLM auth logs, network logs, switch ARP logs, endpoint telemetry — before rotation or overwrite.
Prioritized Remediation:
Priority 1 — Immediately address the capture vulnerability:
Enable Dynamic ARP Inspection (DAI) on the managed switches with DHCP snooping. This directly prevents ARP poisoning as a capture method on the flat network. Even before the authentication protocol is improved, this removes the most accessible capture technique.
Priority 2 — Address the replay vulnerability:
Migrate authentication to NTLMv2 (which incorporates a timestamp and client nonce, making each response unique and preventing direct hash replay) or, preferably, Kerberos (which incorporates timestamps by default — replaying a Kerberos ticket outside a short time window fails). Both prevent pass-the-hash by ensuring each authentication token is session-specific and time-limited.
Priority 3 — Network segmentation:
A flat /16 where all 65,000+ possible IP addresses share a single ARP domain is an architectural risk for ARP-based attacks. Segment the network into VLANs organized by function (workstations, servers, management, guests). Place the server in its own VLAN with a routed boundary — ARP poisoning from a workstation cannot cross the VLAN boundary.
Priority 4 — Encrypt authentication traffic:
Require SMB signing (which encrypts and authenticates SMB traffic, preventing NTLM hash capture from file server connections) and consider deploying a PKI to support certificate-based authentication, eliminating hash-based auth entirely.
Priority 5 — Endpoint detection:
Deploy or update endpoint detection and response (EDR) on all workstations to detect credential harvesting malware and anomalous authentication activity.
On the "flat network" finding:
The flat /16 is not just an ARP poisoning risk — it means every device can directly communicate with every other device, expanding the blast radius of any compromise. The segmentation recommendation isn't optional; it's the foundational network architecture control that limits the damage any single compromised device can cause. Document this as a critical finding separate from the immediate incident.