In order to explain the LLMNR poisoning attack, we will first go into the basics.
Link-local multicast name resolution (LLMNR) Poisoning causes data traffic on a network to be intercepted and modified. This can be done using various tools without much knowledge and can lead to great damage. The goal is usually to collect information, obtain password hashes or exploit other gaps in the network. The whole thing falls under Man-In-The-Middle attack techniques and opens up many new attack vectors.
LLMNR belongs to the name resolution protocol family. Similar to NetBIOS, it is a veteran of Microsoft and Windows history. It is used whenever a computer/server sends a request and receives a negative response from the internal DNS. Once this is the case, the computer/server looks for the desired resource via multicast using LLMNR. This process has been an internal Microsoft procedure for decades to ensure that name resolution works even without setting DNS.
This procedure is intended to make it easier for the user and administrator, as there are fewer Errors related to the name resolution arise, but at the same time presents a Attack vector ready which we will describe shortly. Microsoft has LLMNR in activated by default on every OS, although it is not required in normal company networks if an internal DNS server is in use and every system in the network uses it.
As explained above, LLMNR comes into play when the DNS server cannot provide a suitable answer.
This means an attempt is made to find an answer in the local network. This usually occurs when the user is searching for a network resource mistyped, is not on the right network, has not configured a DNS server or, for example, has forgotten to connect to the VPN and therefore cannot reach the desired network resource.
In this case, the attacker can send the client feedback that he knows the network resource and send him the IP of the desired resource. This IP is supposed to be used to reach the network resource, but it arrives at the server hosted by the attacker.
The client now sends a request to the IP address provided to it. So that the supposed authorization of the client can be checked, the attacker now requires authentication from the client. This can take place via basic auth or challenge response (such as Net-NTLMv2). After authentication, the client now receives an error message so that it appears as if the resource was not found after all. In most cases, authentication takes place without user interaction.
If the attacker has received Basic authentication, he can access resources using these Base64 encoded credentials. For example, if the attacker has received Net-NTLMv2 authentication, he can try to crack it in order to obtain the password of the respective user.
In connection with other misconfigurations, it is also possible to forward challenge-response authentications in order to gain direct access to systems. However, this will be discussed in a later blog article.
The tool can be used to technically implement the LLMNR Poisoning attack just explained Reply .
The following command can be used to start Responder:
responder -I
In the example photo, a client authenticated itself with Net-NTLMv2 in response to the attacker's response.
Responder offers a variety of settings and servers and can also be configured for targeted attacks.
To prevent this type of attack, the easiest and most effective way is to disable LLMNR on the computer/server directly or via GPO.
Very few services today have a real need for queries of this type via multicast.
Policy\Administrative Templates\Network\DNS Client
under settings: “Disable multicast name resolution” * -> Activated
* It is important to note that the name of the GPO appears twice in the German-language version. The lower of the two GPOs is the right one in this context and should be used directly by a push or at the next restart on the client.
Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client
under settings: “Turn OFF Multicast Name Resolution” -> Enabled
In order to detect an attacker in the network, there are tools that send targeted LLMNR requests for non-existent resources into the network. If you now receive answers to these requests, there is an attacker in the network who is waiting for LLMNR requests.
If you have configured the GPO as recommended, it is worth monitoring traffic on UDP 5355 to check.
This will also help you see whether there were any problems implementing the GPO or whether new systems may not have been configured according to this new standard. If you take this into account, you will ideally have permanently closed an attack vector.
To actively detect an attacker in the network, tools such as: Responder, Conveigh or HoneyCreds be used. Here using Respounder as an example:
Attacker starts the responder
IP address used by the attacker
Responder attack detected from IP 192.168.50.20
git clone https://github.com/codeexpress/respounder
cd respounder
go build -o respounder respounder.go
./respounder -hostname test123
After carrying out the above GPO settings and the honeypot, you may unfortunately find that there are attackers in your network.
Here it is possible to use the honeypot to collect information about the attacker and check whether the GPO has actually been adopted by all clients.
If it is known from which IP the attack is coming, the attacker's port / MAC address can be blocked after sufficient information has been obtained in order to prevent further activities.
Especially in an emergency, we advise you to seek professional help and to document as much as possible.
When dealing with the following ISMS framework controls, the vulnerability and its elimination play a role:
ISO 27001:
A. 9.1.2 Access to Networks and Network Services
A.13.1.2 Security of Network Services
BSI Baseline Protection:
NET.1.1.A7
There is an entry in the MITER ATT&CK framework for the vulnerability:
PSN ID: PS-TN-2020-0007
