Protect Your Hashes

Posted on November 21, 2014 by ashley

Joseph Key, SSCP, Information Security Analyst

More specifically, your NTLM domain hashes. “How is this possible?” Believe it or not, the explanation is quite simple and often overlooked.

Since the release of Vista in 2007, within every default Windows domain implementation lies the protocol Link-Local Multicast Name Resolution (LLMNR). This protocol is based on Domain Name System (DNS) packet structure and allows hosts to perform name resolution for other hosts on the same network. Its default use is to provide a secondary method for systems to locate one another if your network’s DNS servers fail. So, when your clumsy-fingered employees search for \pintserver instead of \printserver, and DNS fails to provide an IP address for the requested resource, LLMNR helps by asking every system on the network “who is \pintserver”.

Sounds pretty nice, right? Not so much unfortunately, or fortunately depending on which color hat you wear. As a part of offensive security, seeing this protocol blasting through TCPDUMP often induces a maniacal grin because I know that I am only a few steps away from attaining unauthorized access to your systems and data. Before we get too deep into how much I love LLMNR or more importantly how much you shouldn’t, let’s go over exactly how it works.

How LLMNR Works

First, a user makes an attempt to request for a resource, such as an internally hosted Website or network drive, \Storag-1 instead of \Storage-1 for example.  That user’s computer sends the requested host name to the internal DNS server and given the misspelling, the DNS server sends a reply that states the resource cannot be found.

Next, without any warning to the user, the computer falls back on LLMNR as the protocol to resolve \Storag-1 into an IP address the computer can use. The problem with this is that it broadcasts the “who has” request to every system on the network. If the misspelled requested resource exists, then it will reply with a packet stating its location, DNS entries update and all is right in the world.

The Vulnerability

But what if I am on your network conducting a penetration test or I am an evil hacker plotting to steal all of your secrets? For starters, one could host a server that will reply to any LLMNR broadcast on the network, which can easily be done with a most excellent tool, Responder. Once that happens, your user’s system will automatically believe and then attempt to negotiate a domain session with that server, sending the user’s domain password in NTLMv2 hash format straight to me. All that is left is to use tools such as Hashcat or John the Ripper to crack the hash at my leisure offline. Worse still, I can attempt to downgrade the authentication method to receive the password in NTLMv1 format making hash cracking even easier. Work smarter, not harder is what my father always told me as a child.

How the Attack Works

Let’s take a look at how this attack works. First, we setup our malicious server to catch these mistyped resource requests. “-i” is the IP address of the operating system you are running Responder on and “-d” enables the tool to respond to domain suffix queries.

Figure 1: Server Setup

Joe Blog 1

Now we wait for a user to make a typo when attempting to connect to a NAS.  When a user finally makes a mistake our tool takes over and handles all of the hard work, responding to the victim and negotiating a session.

Figure 2: Resource Request Error

Joe Blog 2

Figure 3: Captured Password Hash

Joe Blog 3

If we take a look at the wireshark capture of the above events, we can gain a better understanding of what is going on behind the scenes. In Figure 4, we see our DNS server failing to resolve the “Stor-1” hostname.

Figure 4: DNS Hostname Resolution Failure

Joe Blog 4

Once the DNS server fails to resolve the hostname, LLMNR takes over and starts broadcasting requests on the network. In Figure 5, you can see our malicious server at x.x.x.220 responding to our victim’s request at x.x.x.54. Once our malicious server poisons the LLMNR response, the victim starts the SMB session negotiation, resulting in the capture of the victim’s NTLMv2 password hash. The SMB session negotiation is show in Figure 6.

Figure 5: LLMNR Interaction between Attacker and Victim

Joe Blog 5

Figure 6: SMB Negotiation

Joe Blog 6

How to Mitigate against the Attack

Now that we understand the risk associated with LLMNR, we are better equipped to protect our systems against this type of attack. The most effective way to stop LLMNR poisoning is by disabling the protocol through enabling the “Turn off Multicast Name Resolution” setting in the Local Group Policy Editor and disabling NetBIOS Name Service.

Figure 7: Enable “Turn off Multicast Name Resolution” setting

Joe Blog 7

Figure 8: Disable NetBIOS Name Service

Joe Blog 8

Posted in Cybersecurity


Test de Penetrare, Scanare de Vulnerabilitati, MoldovaTeste de Penetrare, Scanari de Vulnerabilitati, Moldova