
Table of Contents After introducing 3 Broken Access Control Attacks in our first OWASP Top 10 post, we now move on to
To explain the LLMNR poisoning attack, we first go over the basics.
Link-local Multicast Name Resolution (LLMNR) poisoning causes traffic on a network to be intercepted and modified. This can be done with various tools without much knowledge and can lead to great damage. The aim is usually to collect information, obtain password hashes or exploit other gaps in the network. The whole thing falls under the Man-In-The-Middle attack techniques and opens up many new attack vectors.
LLMNR belongs to the protocol family of name resolution. Similar to NetBIOS, it is a cornerstone of Microsoft and Windows history. It is used whenever a computer / server sends a request and receives a negative response from the internal DNS. As soon as this is the case, the computer / server searches for the desired resource with the help of LLMNR via multicast. This procedure has been a Microsoft internal procedure for decades to ensure that the name resolution also works without the setting of DNS.
This procedure is intended to make it easier for the user and administrator, since fewer errors occur with regard to the name resolution, but at the same time it provides an attack vector which we will describe in a moment. Microsoft has enabled LLMNR in in every OS by default, but it is not needed in common corporate networks when 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 that an attempt is made to find an answer in the local network. This usually occurs if the user makes a mistake when searching for a network resource, is not in the correct network, has not configured a DNS server or, for example, has forgotten to connect to the VPN and thus cannot reach the desired network resource .
In this case, the attacker can send a response to the client that he knows the network resource and send him the IP of the desired resource. Using this IP, he should be able to reach the network resource, but arrives at the server hosted by the attacker.
The client now sends a request to the IP address it was given. In order to check the client's supposed authorization, however, the attacker now requires the client to authenticate itself. This can take place via basic auth or challenge response (such as Net-NTLMv2). After authentication, the client now receives an error message, so it looks like the resource was not found after all. In most cases, authentication takes place without user interaction.
If the attacker has obtained Basic authentications, he can access resources with these Base64-encoded credentials. If the attacker has obtained Net-NTLMv2 authentications, for example, he can try to crack them in order to obtain the password of the respective user.
In connection with other misconfigurations, it is also possible to forward challenge-response authentications to gain direct access to systems. However, this will be addressed in a later blog article.
For the technical implementation of the LLMNR poisoning attack just explained, the Responder tool can be used.
The following command can be used to start Responder:
responder -I
In the example photo, a client has authenticated to the attacker's response using Net-NTLMv2.
Responder offers a wide range of settings and servers and can also be configured for targeted attacks.
To prevent this type of attack, the simplest 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 over multicast.
Policy\Administrative Templates\Network\DNS Client
under Settings: "Disable multicast name resolution" * -> Enabled
* It is important to note here that the name of the GPO occurs twice in the German-language version. The lower of the two GPO's is the correct one in this context and should be applied by a push directly 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, tools are available which send targeted LLMNR requests for non-existent resources into the network. If you receive responses to these requests, there is an attacker in the network waiting for LLMNR requests.
If you have configured the GPO as recommended, it is worth monitoring traffic on UDP 5355 to check.
In the course of this, you will also see whether there were problems with the implementation of the GPO, or whether new systems may not have been configured according to this new standard. If you take this into account, you will have permanently closed an attack vector in the optimum case.
To actively detect an attacker on the network, tools such as Respounder, Conveigh or HoneyCreds can be used for this purpose. Respounder is used here as an example:
Attacker launches 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 performing the above GPO settings and honeypot, you may unfortunately find that there are attackers on your network.
Here it is possible to collect information about the attacker through the honeypot and to check whether the GPO was actually taken over by all clients.
If it is known from which IP the attack takes place, the port / MAC address of the attacker can be blocked after sufficient information has been obtained to prevent further activities.
Especially in an emergency, we advise you to call in professional help and document as much as possible.
When addressing the following ISMS framework controls, the vulnerability and its remediation plays a role:
ISO 27001:
A. 9.1.2 Access to networks and network services
A.13.1.2 Security of network services
BSI basic protection:
NET.1.1.A7
There is an entry in the MITRE ATT&CK framework for the vulnerability:
PSN-ID: PS-TN-2020-0007
Table of Contents After introducing 3 Broken Access Control Attacks in our first OWASP Top 10 post, we now move on to
The status report of the Federal Office for Information Security (BSI) 2022 shows: IT security in the public sector is increasingly
Interview with Christian Rosenzweig (Johner Institute) - Part 2 In the first part of our interview, we asked basic questions about