LLMNR, enabled by default on Windows machines since Vista, provides name resolution on networks in which a DNS server is unavailable.This is great, in the case where I want to share some files or connect to a network printer at home. It is also used in the case where dns resolution fails. Upon DNS lookup failure, a Windows client will send out an LLMNR multicast request asking "Is Server X out there?" When that client gets an answer "Yes, Server X is at 192.168.1.11!", the client trusts that answer. It's akin to walking into a bar and shouting out: "Did anyone drop a $20 bill?" Of course, this makes LLMNR useful for stealing credentials. It sets up a perfect information security demonstration: It shows that:
- Convenience trumps security.
- With a small bit of analysis, abusing a trust relationship can be trivial.
- The next logical step is to write some proof of concept code.
With a good understanding of how a client connects to a share using LLMNR for name resolution, a novice/intermediate coder could probably create an LLMNR spoofing tool in a few hours. Of course, this has already been done by professional coders who have covered the details, and added some very nice features. Without further ado, let me introduce you to Responder from Trustwave Spiderlabs, in the form of a demo.
My lab setup is simple. It consists of:
- A domain controller (only useful for DNS in this scenario) at 192.168.1.200
- An unsuspecting client running Windows 8.1 (or any post-Vista Windows OS) at 192.168.1.13
- An attacker machine running Responder. Responder is available as a standalone python script here: https://github.com/SpiderLabs/Responder, and it is included in Kali (which I am using), configured for nice placement of logs and hash files.
Disclaimer: In the United States, and possibly in other places, if you do this on a network you do not own and have permission to do security testing, I am almost certain you will be breaking the law. I won't go into it here, but the text of the CFAA is here.
Once the lab is built :
- Start Responder on the Kali box (192.168.1.11 in this lab) by invoking:
root@kali:# responder -I eth0#eth0 is the name of the network adapter.
- Try to connect to \\NONEXISTENT_SERVER from the client machine
- Look at the nice, easy hash stealing provided by responder
- Crack the hash with hashcat for a cleartext password
Here is a screenshot of Responder doing its thing:
Below is a screenshot of Wireshark, showing all of the pertinent packets. The pcap file is available here.
Below is a table showing each packet, and a description of what each one did:
| Packet #
|6||IGMPv3 membership report from 192.168.1.11 to 18.104.22.168|
|15||DNS query for NONEXISTENT_SERVER.corp.viamonstra.com|
|16||DNS Query Response: No such name NONEXISTENT_SERVER.corp.viamonstra.com|
|19||LLMNR query for NONEXISTENT_SERVER|
|20||LLMNR query from 192.168.1.13 to 22.214.171.124: NONEXISTENT_SERVER: type AAAA, class IN|
|21|| LLMNR Response from 192.168.1.11: NONEXISTENT_SERVER: type A, class IN, addr 192.168.1.11
*** This is the big lie!***
|26|| ARP: 26 16:18:10.858422 Microsof_00:cf:09 Broadcast ARP 60 Who has 192.168.1.11? Tell
|28-33||Set up connection and negotiate : These packets match up beautifully with the description of SMB packet exchange scenario described here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365233|
|34-36||The Coup D'etat: This is the NTLMSSP authentication, in which we receive our hash, shown below|
|38||Our Kali box gives a success message for the SMB connection setup|
|39-43|| Further negotiation with the eventual "Access Denied" message from the box running responder.
Now, we have the password hash for viamonstra\NEP, and it's time to crack it. One of the nice things about the responder setup in Kali is that it keeps the logs and captured hashes nicely organized. If you change directories to /usr/share/responder/logs, you'll see your captured hashes, in the form of SMB-NTLMv2-SSP-192.168.1.13.txt. Invoking hashcat will do the trick. I copied the txt file to my home directory, and invoked hashcat from there, using the following command:
hashcat -m 5600 SMB-NTLMv2-SSP-192.168.1.13.txt /usr/share/wordlists/rockyou.txt
As for the details of that command, Kali comes with wordlists built in, ready for extraction in the /usr/share/wordlists directory. The -m 5600 option tells hashcat the type of hash it's supposed to crack. Invoking hashcat --help will list the possibilities. As you can see from the screenshot below, the password has been cracked (P@ssw0rd), in just a few seconds.
I do hope to investigate how Responder does wpad spoofing soon, then describe some detection and mitigation tactics. For mitigation, it should be as simple as enabling the group policy: "Turn off multicast name resolution", located at: Computer configuration>Policies>Administrative Templates>Network>DNS Client. If I learn anything in my environment when I begin to deploy it, I'll share. Stay tuned.
Thanks for reading!
Cracking the hash with Kali:
Thanks to Bsides SLC 2016 for hosting the cool class where I was introduced to this technique.