This chapter covers NTLM relay attacks and the Responder tool, two of the most dangerous techniques in the Windows authentication ecosystem. Understanding these attacks is critical for the PT0-002 exam, as they appear in the 'Attacks and Exploits' domain (Objective 3.4) and typically account for 5-8% of exam questions related to SMB and authentication attacks. We will dissect the mechanics of NTLM relay, how Responder automates the attack, defensive measures, and exactly what the exam expects you to know.
Jump to a section
Imagine a large corporate mailroom (the network) where employees send and receive interoffice mail. The mailroom uses a system where each employee has a badge (their NTLM credentials) that they swipe to authenticate before sending a package. An attacker (Responder) positions themselves as a fake mailroom clerk. When an employee arrives to send a package, the attacker says, 'Oh, the main mailroom is busy; just give me your package and badge, and I'll process it for you.' The employee hands over the package and swipes their badge. The attacker then takes the badge, rushes to the real mailroom, and says, 'I'm Employee X; I need to send this package.' The real mailroom processes it, thinking it's the legitimate employee. The attacker never knows the password (the actual NTLM hash); they only need to borrow the badge for a moment to impersonate the employee. This is exactly how NTLM relay works: the attacker captures the NTLM authentication attempt (the badge swipe) and relays it to a target server (the real mailroom) to gain access without ever cracking the hash.
What is NTLM Relay?
NTLM relay is an attack where an attacker intercepts an NTLM authentication attempt and forwards (relays) it to another server to authenticate as the victim. Unlike pass-the-hash, which requires cracking or extracting the hash, relay attacks leverage the authentication handshake in real-time. The attacker never needs to know the password or the hash—they simply act as a middleman.
The NTLM Authentication Protocol
NTLM uses a challenge-response mechanism. The client sends a NEGOTIATE message, the server responds with a CHALLENGE (a random 8-byte nonce), and the client computes an HMAC-MD5 of the challenge using the user's password hash. This response is sent back. In a relay attack, the attacker positions themselves between the client and the intended server. They receive the client's NEGOTIATE and forward it to the target server. The target server sends a CHALLENGE to the attacker, who forwards it to the client. The client computes the response and sends it to the attacker, who relays it to the target server. The target server verifies the response and grants access—thinking it's the legitimate client. The attacker now has an authenticated session.
Key Components and Defaults
LLMNR (Link-Local Multicast Name Resolution): UDP port 5355. Used by Windows to resolve names when DNS fails. Responder listens for LLMNR queries and responds with its own IP, tricking clients into sending NTLM authentication.
NBT-NS (NetBIOS Name Service): UDP port 137. Similar to LLMNR but older. Also used for name resolution fallback.
mDNS (Multicast DNS): UDP port 5353. Used by Apple Bonjour and some Linux systems. Responder can also spoof mDNS.
SMB (Server Message Block): TCP port 445. The most common target for relay attacks. Once the attacker relays authentication, they can access files, execute commands, or perform SMB relay to other services.
HTTP/HTTPS: Responder can also capture and relay HTTP authentication (NTLM over HTTP).
WPAD (Web Proxy Auto-Discovery): Responder can spoof WPAD to force browsers to send NTLM authentication.
How Responder Works
Responder is a Python tool that listens for name resolution requests (LLMNR, NBT-NS, mDNS) and responds with its own IP address. When a client attempts to connect to a resource (e.g., \\fileserver\share), it first tries DNS. If DNS fails, it falls back to LLMNR (Windows Vista+) or NBT-NS. Responder answers with its IP, so the client sends its NTLM authentication to the attacker's machine. By default, Responder captures the hashes but does not relay them. To relay, you must use the -r flag or combine with a relay tool like ntlmrelayx.py from Impacket.
NTLM Relay Attack Steps
Listen for name resolution requests: Run Responder with sudo responder -I eth0 -dw. This enables LLMNR, NBT-NS, and WPAD poisoning.
Client falls back to LLMNR/NBT-NS: When a user mistypes a share path (e.g., \\fileservr) or DNS fails, Windows broadcasts an LLMNR query.
Responder answers: It claims to be the requested server, providing its IP.
Client initiates NTLM authentication: The client sends an SMB connection request with NTLM negotiation.
Relay the authentication: Instead of just capturing the hash, the attacker uses ntlmrelayx.py to forward the authentication to a target server (e.g., a domain controller). The target server sees the attacker as the client and grants access.
Perform actions: Once authenticated, the attacker can execute commands, dump hashes, or move laterally.
Defenses
Disable LLMNR and NBT-NS: Via Group Policy or registry. This is the most effective mitigation.
Enable SMB Signing: Forces SMB packets to be signed. If signing is required, the relayed authentication will fail because the attacker cannot sign on behalf of the client without the session key. However, many environments do not enforce signing.
Use Extended Protection for Authentication (EPA): Binds the NTLM authentication to the TLS channel, preventing relay over HTTP/HTTPS.
Enable SMB Encryption: Windows 10/Server 2016+ supports SMB encryption, which prevents relay.
Network segmentation: Limit SMB access to only necessary servers.
Monitor for LLMNR/NBT-NS traffic: Use tools like Wireshark to detect poisoning.
Related Tools
Impacket ntlmrelayx.py: The primary relay tool. It accepts incoming authentications from Responder and relays them to targets. Supports SMB, HTTP, LDAP, and more.
Inveigh: A PowerShell-based tool similar to Responder, useful in restricted environments.
Bettercap: An ARP spoofing tool that can also capture NTLM hashes.
Exam Focus Numbers
LLMNR: UDP 5355
NBT-NS: UDP 137
mDNS: UDP 5353
SMB: TCP 445
Default Responder settings capture but do not relay; use -r to relay.
SMB signing: Disabled by default on many Windows versions (enabled on domain controllers).
Common Command Syntax
# Start Responder to capture hashes
sudo responder -I eth0 -dw
# Start Responder with relay mode
sudo responder -I eth0 -dw -r
# Use ntlmrelayx.py to relay to a target SMB server
sudo ntlmrelayx.py -t smb://192.168.1.10 -smb2support -debug
# Combine Responder and ntlmrelayx.py (run in separate terminals)
# Terminal 1: sudo responder -I eth0 -dw
# Terminal 2: sudo ntlmrelayx.py -t smb://192.168.1.10 -smb2supportPoison Name Resolution
The attacker runs Responder on an interface. Responder listens for LLMNR (UDP 5355), NBT-NS (UDP 137), and mDNS (UDP 5353) queries. When a victim attempts to connect to a hostname that fails DNS resolution (e.g., a typo or unreachable server), Windows broadcasts an LLMNR query. Responder answers with its own IP address, claiming to be the requested host. The victim's machine now thinks the attacker's IP is the legitimate server and initiates an SMB connection to the attacker.
Capture NTLM Authentication
The victim's machine sends an SMB connection request to the attacker's IP. This triggers NTLM authentication: the victim sends a NEGOTIATE message. The attacker (posing as the server) responds with a CHALLENGE (an 8-byte random nonce). The victim computes an HMAC-MD5 of the challenge using its NTLM hash and sends the AUTHENTICATE response. The attacker captures this response, which includes the NTLM hash (or Net-NTLMv1/v2 hash). By default, Responder saves these hashes for offline cracking.
Relay to Target Server
Instead of just capturing, the attacker uses ntlmrelayx.py to relay the authentication. The attacker's machine opens a connection to the target server (e.g., a domain controller or file server). It sends the victim's NEGOTIATE message to the target. The target responds with its own CHALLENGE. The attacker forwards this challenge to the victim (who thinks it's from the legitimate server). The victim computes the response and sends it to the attacker, who relays it to the target. The target verifies the response and establishes an authenticated session with the attacker's machine, thinking it's the victim.
Perform Post-Exploitation
Once the relay is successful, the attacker has an authenticated SMB session as the victim. The attacker can then enumerate shares, read files, upload executables, or execute commands via scheduled tasks or service control. For example, using Impacket's smbexec.py or psexec.py, the attacker can run commands on the target server with the victim's privileges. If the victim is a domain admin, the attacker can compromise the entire domain.
Maintain Access and Cover Tracks
The attacker may set up persistence (e.g., creating a local admin account) or use the authenticated session to dump credentials (e.g., using secretsdump.py). To cover tracks, the attacker can disable logging or delete event logs. However, relay attacks often generate 4625 (failed logon) and 4624 (successful logon) events on the target server, with the source IP being the attacker's machine, which can be traced if monitored.
Scenario 1: Internal Penetration Test of a Corporate Network
A penetration tester is engaged to assess the internal network of a company with 5,000 Windows workstations and 200 servers. The tester sets up Responder on a laptop connected to the internal switch. Within minutes, LLMNR queries start coming in from users who mistype share paths or from automated scripts that fail DNS resolution. The tester captures dozens of NTLM hashes. Using hashcat with a wordlist, several weak passwords are cracked. However, the tester also uses relay: pointing ntlmrelayx.py at a domain controller that has SMB signing disabled. A user who is a local admin on a file server authenticates, and the tester relays that authentication to the file server, gaining access to sensitive HR documents. The tester then uses the compromised account to move laterally, eventually gaining domain admin privileges. The tester recommends disabling LLMNR and NBT-NS via Group Policy and enforcing SMB signing on all servers.
Scenario 2: Red Team Operation Against a Healthcare Provider A red team is tasked with simulating an advanced persistent threat (APT) targeting a hospital network. The team deploys a Raspberry Pi running Responder in a hidden location (e.g., under a desk). The Pi captures NTLM authentications from nurses and doctors accessing patient records. The team uses relay to a web application that uses NTLM over HTTP (without EPA). They gain access to the medical records system and exfiltrate patient data. The healthcare provider had not implemented EPA on their web servers, making them vulnerable. The red team's report highlights the need for Extended Protection for Authentication and regular scanning for rogue devices.
Scenario 3: Misconfiguration Leading to Relay A company has SMB signing enabled on domain controllers but not on file servers. An attacker relays authentication from a client to a file server. The file server accepts the relayed authentication because signing is not enforced. The attacker reads confidential files. The company learns that SMB signing must be enabled on all servers, not just domain controllers. They also implement network access control (NAC) to prevent unauthorized devices from connecting to the network. The attacker's device would have been blocked by NAC if it had been deployed properly.
PT0-002 Objective 3.4: Given a scenario, perform attacks on authentication and authorization systems. This includes NTLM relay, pass-the-hash, and Kerberos attacks. The exam expects you to understand the attack flow, the tools used (Responder, ntlmrelayx.py), and the defenses.
Common Wrong Answers:
1. 'NTLM relay requires cracking the hash.' This is false; relay uses the authentication handshake without needing the plaintext password or hash.
2. 'Responder automatically relays captured hashes.' By default, Responder only captures hashes; you must use the -r flag or combine with ntlmrelayx.py to relay.
3. 'SMB signing prevents all relay attacks.' SMB signing prevents relay only if it is enforced (required). If it is enabled but not required, relay can still work because the attacker can drop the signing flag.
4. 'NTLM relay only works over SMB.' It can work over HTTP, LDAP, and other protocols that use NTLM.
Specific Exam Numbers:
- LLMNR port: UDP 5355
- NBT-NS port: UDP 137
- SMB port: TCP 445
- Default Responder command: responder -I eth0 -dw
- Relay command: ntlmrelayx.py -t smb://target -smb2support
Edge Cases: - If SMB signing is required, the relay will fail because the attacker cannot sign the packets without the session key. The exam may present a scenario where signing is 'enabled' but not 'required' – relay still works. - EPA (Extended Protection for Authentication) prevents relay over HTTPS by binding the channel. The exam may test that EPA mitigates relay over HTTP/HTTPS but not over SMB. - IPv6: LLMNR works over IPv6; the exam may ask about LLMNR over IPv6.
Eliminating Wrong Answers: - If a question mentions 'cracking' or 'offline attack', it is likely pass-the-hash or hash cracking, not relay. - If a question says 'captures hashes' but not 'relays', it is referring to Responder's default behavior. - If a question asks for mitigation, the most effective is disabling LLMNR/NBT-NS, not just enabling SMB signing (since signing may not be enforced).
NTLM relay attacks capture and forward authentication handshakes to impersonate victims.
LLMNR operates on UDP 5355; NBT-NS on UDP 137; both are used for name resolution fallback.
Responder by default only captures hashes; use -r or ntlmrelayx.py to relay.
SMB signing must be enforced (required) to prevent relay; enabled but not required is insufficient.
Extended Protection for Authentication (EPA) prevents relay over HTTPS by binding the TLS channel.
The most effective mitigation is to disable LLMNR and NBT-NS via Group Policy.
NTLM relay works over multiple protocols: SMB, HTTP, LDAP, etc.
These come up on the exam all the time. Here's how to tell them apart.
NTLM Relay
Relays the entire authentication handshake in real-time.
Does not require knowing the password or hash.
Works against NTLMv1 and NTLMv2.
Mitigated by SMB signing, EPA, and disabling LLMNR/NBT-NS.
Tools: Responder + ntlmrelayx.py
Pass-the-Hash
Uses a stolen hash to authenticate without relaying.
Requires the hash (often extracted from memory or SAM).
Works only for NTLMv1; NTLMv2 has protections (like session binding).
Mitigated by KB2871997 (restricts remote use of local accounts).
Tools: Mimikatz, psexec, wmiexec
Mistake
NTLM relay requires the attacker to crack the hash.
Correct
Relay does not require cracking. The attacker uses the captured authentication handshake in real-time to authenticate to a target server without ever knowing the password or hash.
Mistake
Responder automatically relays captured hashes by default.
Correct
By default, Responder only captures hashes. To relay, you must use the `-r` flag or combine with a relay tool like ntlmrelayx.py.
Mistake
SMB signing prevents all NTLM relay attacks.
Correct
SMB signing prevents relay only if it is enforced (required). If signing is enabled but not required, the attacker can drop the signing flag, and the relay succeeds.
Mistake
NTLM relay only works over the SMB protocol.
Correct
NTLM relay can work over any protocol that uses NTLM authentication, including HTTP, HTTPS, LDAP, and SMTP, as long as the attacker can intercept and forward the authentication messages.
Mistake
Disabling LLMNR alone fully mitigates NTLM relay attacks.
Correct
Disabling LLMNR helps but does not prevent all relay attacks. NBT-NS and mDNS can also be poisoned. Additionally, attackers can use other methods like ARP spoofing or rogue DHCP to intercept traffic.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
NTLM relay forwards the entire authentication handshake to a target server in real-time, allowing the attacker to authenticate without knowing the hash. Pass-the-hash uses a stolen hash (e.g., from Mimikatz) to authenticate directly, but requires the hash to be extracted and often only works for NTLMv1. Relay is more stealthy but requires the victim to be actively authenticating.
No, by default Responder only captures and logs hashes. To relay, you must either use the `-r` flag (which enables relay mode) or pipe the captured authentications to a tool like ntlmrelayx.py. The exam expects you to know this distinction.
LLMNR uses UDP port 5355. NBT-NS uses UDP 137. mDNS uses UDP 5353. These are the ports Responder listens on for name resolution poisoning.
Yes, NTLM relay can work over HTTP/HTTPS if the web application uses NTLM authentication. However, Extended Protection for Authentication (EPA) can prevent relay over HTTPS by binding the authentication to the TLS session.
The most effective defense is to disable LLMNR and NBT-NS via Group Policy, as this removes the attack vector. Additionally, enforce SMB signing (set to required) on all servers and enable EPA for web applications. Network segmentation and monitoring for LLMNR/NBT-NS traffic also help.
Only if SMB signing is set to 'required' (enforced). If it is 'enabled' but not required, the attacker can drop the signing flag, and the relay will succeed. The exam often tests this nuance.
ntlmrelayx.py is an Impacket tool that accepts incoming NTLM authentications (e.g., from Responder) and relays them to a target server. It supports multiple protocols (SMB, HTTP, LDAP) and can be used to execute commands or dump credentials after successful relay.
You've just covered NTLM Relay Attacks and Responder — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?