Understanding LLMNR and NBT-NS Poisoning with Responder
Understanding LLMNR and NBT-NS Poisoning with Responder When I first started learning Responder, the usual explanation was pretty simple: Run Responder, wait for a Windows machine to make a request, capture an NTLMv2 hash, and crack it. That is enough to use the tool in a lab, but it does not really explain what is happening in the background. The interesting part is not the Responder command itself. The interesting part is why a Windows machine sends authentication to us in the first place. Once I understood that part, the whole attack made much more sense. This blog is my attempt to explain the complete flow in a simple way — starting from DNS failure, then LLMNR/NBT-NS poisoning, NTLM authentication, NetNTLMv2 capture, cracking, and finally NTLM relay. --- Where the Problem Starts Let's say we have a small Active Directory environment. A user wants to access a file share and enters: Before Windows can connect to the server, it needs to know the IP address of fileserver. Normally DNS handles this. Everything works normally. Now imagine the user makes a typo: The workstation asks DNS for something like: DNS has no record for that hostname. At this point Windows may try other local name-resolution methods. This is where LLMNR and NBT-NS become important. --- LLMNR LLMNR stands for: It normally uses: For IPv4, LLMNR commonly uses the multicast address: The easiest way I think about LLMNR is this: Instead of asking only a DNS server, the machine starts asking other systems on the local network. Something like: That is where the weakness comes from. Any system that can see the request may be able to answer it. And an attacker can simply lie. The victim has no strong way of knowing that the attacker actually owns that hostname. --- NBT-NS NBT-NS stands for: It is an older Windows name-resolution mechanism and normally uses: From an attacker's point of view, the important idea is very similar to LLMNR. A workstation is trying to resolve a hostname locally. The attacker sees the request and responds before the legitimate destination is found. So the problem is not really complicated: That is the basic trust issue Responder abuses. --- What Responder Is Actually Doing People often say that Responder "steals passwords." That is not exactly what happens. Responder first tricks a victim into connecting to the attacker's machine. After that, the victim may automatically try to authenticate. Responder has different components for this. At a high level: The poisoning side tells the victim: The rogue service waits for the victim to connect and authenticate. That second part is where NTLM comes into the picture. --- Walking Through the Attack Let's use the same example. Victim: Attacker: The user wants to access: but accidentally types: DNS cannot resolve it. The workstation then sends a local name-resolution request. Conceptually: Responder sees that request and replies: Now the victim thinks our attack machine is the server it was trying to reach. The poisoning worked. But at this point we still do not have a password or a hash. The next step happens because of the protocol the victim is trying to use. --- Why Does the Victim Send Authentication? The user was trying to access: That is an SMB path. So after resolving filesrever to our IP address, Windows tries to connect to: Responder can run a rogue SMB service and accept that connection. The important part is that Windows may automatically try to authenticate using the currently logged-in user's domain credentials. The user does not necessarily see a password box. Windows is trying to provide single sign-on style authentication in the background. That convenience becomes useful to an attacker when the workstation has been tricked into connecting to the wrong machine. --- NTLM Does Not Send the Password Directly Windows normally does not send this over the network: NTLM uses a challenge-response process. At a very high level: The server gives the client a challenge. The client uses password-derived credential material to calculate a response. The server verifies that response. When Responder controls the server side of this exchange, it can capture the authentication material sent by the client. That usually includes things such as: This captured challenge-response is what we usually call: --- NT Hash and NetNTLMv2 Are Different This is one distinction I think every person learning Active Directory attacks should understand properly. An NT hash is derived from the user's password. In a simplified form: The NT hash is long-term password-derived credential material. It is the kind of credential we usually talk about during attacks such as: NetNTLMv2 is different. It is generated during an authentication exchange. A simplified flow looks like this: The simple way I remember it is: Because of this, a NetNTLMv2 capture is not something we can simply use as an NT hash with Pass-the-Hash. --- What Hashcat Is Actually Doing If we capture a NetNTLMv2 response with Responder, we can try to recover the original password offline. Hashcat uses mode 5600 for NetNTLMv2. For example: Hashcat is not decrypting the response. It is guessing passwords. For every candidate password, Hashcat performs the same NTLMv2 calculations and compares the result with the response we captured. For example: No match. Then: No match. Then maybe: If the calculated response matches the captured response, Hashcat knows that the password guess was correct. That is why this attack can be performed offline. Once we have captured the authentication: This is why weak passwords can make a captured NetNTLMv2 response very valuable. --- What If the Password Is Strong? A captured hash does not automatically mean we are getting the password. A password such as: may be found using a decent wordlist. Something like: is a very different story. Even if the poisoning worked perfectly, cracking may not be practical within the assessment window. This is where NTLM relay becomes interesting. Instead of cracking the password, we may be able to use the live authentication itself. --- NTLM Relay The basic idea is: The attacker sits between the victim and another server. At a high level: Once this part is clear, a lot of other Active Directory attacks start making more sense. --- Why SMB Signing Matters SMB is one of the most common relay targets. During internal enumeration, we usually care about whether SMB signing is required. You may see something like: Enabled and Required are not the same thing. A host can support SMB signing without forcing every client to use it. For classic SMB relay, hosts where signing is not required are much more interesting. If SMB signing is required, the attacker cannot simply continue using the authenticated SMB session in the normal relay fashion without the proper signing material. This is why: is an important finding during internal network testing. But it does not automatically mean full compromise. The privileges of the relayed account still matter. Relaying a normal domain user to a machine where that user has no useful permissions may not give us much. Relaying an account that has local administrator rights on the target is a completely different situation. --- NTLM Relay Is Not Only SMB SMB is usually the first example we see when learning NTLM relay, but the concept is wider than that. NTLM authentication can appear across different services. Depending on the environment, targets may include things such as: Different protocols have different protections. Things such as: can affect whether a relay path is possible. So instead of asking only: I prefer to ask: That gives a much better picture of the actual risk. --- Responder Analyze Mode On a real internal assessment, I would not always start by poisoning everything immediately. Responder has an analyze mode: In this mode it listens but does not actively poison requests. If a victim asks: Responder only observes the request. It does not answer: This can be useful before doing anything active. We can see things such as: On a production network, this is a much better way to understand the environment before actively responding to clients. --- Network Position Matters Responder is not magic. The attacker normally needs to be in a position where the victim's local name-resolution traffic is visible. LLMNR is link-local multicast. NBT-NS is normally local broadcast-style traffic. Routers do not simply forward this traffic across every VLAN. For example: This is a useful position. But if the victim is in VLAN 10 and the attacker is sitting in VLAN 50, running Responder does not automatically give visibility into all of VLAN 10's local multicast and broadcast traffic. This is one reason Responder is commonly used after getting some form of internal network access. --- Poisoning Is Not the Same as Sniffing Another thing worth clearing up is that Responder is not simply sniffing everyone else's credentials. Normally: The victim is talking directly to the legitimate file server. With poisoning: The attacker changes where the victim sends the connection. That is the real starting point of the attack. The core issue is not only that NTLM exists. The issue starts because a workstation may ask an unauthenticated local network to resolve a hostname and trust a false response. NTLM authentication then turns that poisoned connection into something useful. --- A User Typo Is Only One Example Most demos use something like: because it is easy to explain. But in a real corporate network, name-resolution traffic can appear for many other reasons. For example: In a large environment, it is completely possible to start Responder and receive authentication without manually making anyone type a bad hostname. Some forgotten application or old shortcut may already be generating those requests. --- Be Careful in Production Responder actively lies to systems on the network. That means it can also break things if used carelessly. Imagine a workstation genuinely trying to reach: DNS has a temporary issue. Responder answers first. The workstation may now try to connect to the attack machine instead of the actual printer. From the user's point of view, the printer simply stopped working. That is why I would not blindly enable every aggressive Responder option on a production network. Before doing active poisoning during an assessment, I would always think about: Getting a credential is not worth causing an outage for the client. --- Mitigation There is no single fix for this whole attack chain because different weaknesses are being combined. At the name-resolution layer: At the relay layer: At the credential layer: Each control breaks a different part of the attack. --- Final Attack Flow This is the flow I use to remember the whole concept: Responder is only one tool in this chain. The important thing is understanding why the victim connects to us, why Windows tries to authenticate automatically, what exactly gets captured, and what we can do with that authentication afterward. Once that part is clear, Responder stops feeling like a tool where we just run a command and wait for hashes. We actually understand what is happening on the network. See you in the next blog. Until then, keep enumerating and stay curious. by Madhav