LLMNR/NBT-NS Poisoning and SMB Relay

By responding to LLMNR/NBT-NS network traffic, adversaries may spoof an authoritative source for name resolution to force communication with an adversary controlled system. This activity may be used to collect or relay authentication materials.

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are Microsoft Windows components that serve as alternate methods of host identification. LLMNR is based upon the Domain Name System(DNS) format and allows hosts on the same local link to perform name resolution of other hosts. NBT-NS identifies systems on a local network by their NetBIOS name.

Adversaries can spoof an authoritative source for name resolution on a victim network by responding to LLMNR (UDP 5355)/NBT-NS (UDP 137) traffic as if they know the identity of the requested host, effectively poisoning the service so that the victims will communicate with the adversary controlled system. If the requested host belongs to a resource that requires identification/authentication, the username and NTLMv2 hash will then be sent to the adversary controlled system. The adversary can then collect the hash information sent over the wire through tools that monitor the ports for traffic or through Network Sniffing and crack the hashes offline through Brute Force to obtain the plaintext passwords. In some cases where an adversary has access to a system that is in the authentication path between systems or when automated scans that use credentials attempt to authenticate to an adversary controlled system, the NTLMv2 hashes can be intercepted and relayed to access and execute code against a target system. The relay step can happen in conjunction with poisoning but may also be independent of it.

Several tools exist that can be used to poison name services within local networks such as NBNSpoof, Metasploit, and Responder.


Here will use Responder a very well-known and popular tools with Red Teamers and Penetration Testers. Responder as the Name implies is a responding tool for LLMNR traffic when a Windows uses DNS for resolving Names but when the name is not found it goes back to LLMNR and NBT-NS traffic to resolve a name, when this is not found and Responder is Running this just say's "Hey yeah, this is me.." Now let's show a sample.


In this demonstration the user is trying to access an un-existing Share since it cannot find it then Responder just responds saying that it's the share the user is looking for and request for a Hash to authenticate

We can check it out ourselves by just using the Run Application and search for a share.

Last updated