There are a good number of situations when we find ourselves abusing the LLMNR and NBT-NS protocols on an infrastructure penetration test, more specifically on an Active Directory setup. These 2 protocols are enabled by default on most of the Windows operating systems. What are they doing is they facilitate the communication between network machines when searching for a DNS hostname regardless if it’s a share, a server or a web hostname.
The overview picture of the attack vector:
- the victim is looking for a non-existing hostname
- the DNS server cannot resolve the request
- we reply and resolve the hostname resolution query
- we ask the victim for authentication
This is possible because the protocols are working on hostname resolution queries that are broadcast in the network, so the faster we are in the response time and depending on how close we are to the victim, the more successful we will be.
We can abuse this vulnerability with the help of some automated tools. My personal favorite tool for approaching this type of scenario is Responder. We know that Responder is specifically developed to abuse the protocols. For a high end overview, what it does is it listens on the network for LLMNR and NBT-NS traffic and tries to respond to them accordingly to the settings defined by us.
When the victim requests an unknown or non-existing hostname, we are there to intercept and respond properly depending on the scenario. There are a couple of choices we can make depending on the aggression and stealthiness in which we like to approach the engagement. In this article I would like to talk more about the Basic Authentication functionality.
Basic Authentication
If the victim is asking for an unknown web hostname, we can actually respond to the request and greet the victim with a basic authentication HTML web page that is built by default in the functionalities of Responder.
Responder -I <adapter> -b
The -b parameter stands for the basic authentication functionality of the tool. If we analyze the HTTP.py file we can observe that the code creates a local web server. Firstly, the web application serves the user with a Basic Authentication prompt. After that, the web page is loading a resource found in a remote non-existing host. This action will further trigger the hostname resolution attack that will ask for SMB authentication and capture the NTLM hash.
As we can assume, this type of attack, specifically this functionality, can be considered a social-engineering attack. The success rate depends on the interaction with the victim.
Making adjustments
In both cases of completing the basic authentication or not, the victim is presented with an unknown web page. This can be confusing and suspicious for users. This can be even more dangerous if a fellow user from the IT Staff or someone with technical knowledge sees the Basic Authentication prompt box. In this scenario, our stealthy position can surely be compromised and in the worst case, we can be caught.
With this problem in mind we started looking for ways to upgrade the basic authentication functionality. We surely want those IT Staff credentials, and we are actually looking to target them but we also want to keep ourselves hidden. We can try to serve the victim with another feedback, a one that is more positive then the hollow blank page.
So we thought the most comfortable and efficient way is to redirect the victim to a Google search for the requested web hostname.
We can achieve this by modifying the Responder.conf configuration file found in the home folder of the tool. By looking into it, we can see the line of code that specifies the HTML behavior of the -b mechanism. In order to achieve what we planned, we can insert the following piece of code:
Of course, when thinking about it, the imagination is the limit so we can do lots of fun stuffs with this. For example, we can surely get rid of the basic authentication prompt and we can go for a much smoother approach like exploiting an XSS vulnerability from an internal network web application. Or we can try to create a phishing page to simulate an internal web application which has a login form.
The parameter HTMLToInject contains the value which will be reflected and executed in the web application created by Responder. This is our point of injection in which we will add our custom JavaScript and HTML code.
Conclusion
Indeed, back in the days this was pretty handy because the purpose of these two protocols was designed to help a DNS resolution query in which a hostname is found and fetched to the requester. Nowadays, these protocols are not that helpful anymore. They are introducing new problems like the one presented in this article. Moreover, it exposes the internal network and gives the attacker an easy,passive and efficient method to get privileged access inside a network.
If we look on most of the guidelines for network security hardening we can observe that it is highly recommended to disable these specific protocols.
Mitigation
There are a couple of changes that can be made in order to successfully deflect this type of attacks that are based on the LLMNR and NBT-NS protocols.
We need to disable the LLMNR broadcasts on all the network machines. This can be achieved by modifying the Group Policy entries regarding this protocol. There are a good number of articles on the Internet that explains the procedure . Unfortunately, disabling the NBT-NS broadcast cannot be done from the Group Policy and needs to be done manually.
As a note, if the network includes Windows versions 2000 or earlier, NBT-NS may need to stay enabled (https://technet.microsoft.com/en-us/library/cc728457(v=ws.10).aspx) so this could raise a big security consideration.
Also, the Responder has a functionality to exploit bad WPAD configuration. To mitigate this attack vector, we can add an entry for “wpad” to our DNS server. Note that the DNS entry does not need to point to a valid WPAD server. As long as the hostnames queries are resolved, the atack will be prevented.