You are here

kgeil's blog

Responder: Stealing hashes in 50 packets or less

Submitted by kgeil on Thu, 09/15/2016 - 00:18

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: 

  1. Convenience trumps security.
  2. With a small bit of analysis, abusing a trust relationship can be trivial.
  3. 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.

My current lab is the testing environment built from the hydration kit described in Kent Agerlund's awesome and affordable SCCM book.  The instructions are here.

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 : 

  1. 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.
  2. Try to connect to \\NONEXISTENT_SERVER from the client machine
  3. Look at the nice, easy hash stealing provided by responder
  4. Crack the hash with hashcat for a cleartext password

Here is a screenshot of Responder doing its thing:

Screenshot on Kali box


Below is a screenshot of Wireshark, showing all of the pertinent packets.  The pcap file is available here.

Wireshark screenshot


Below is a table showing each packet, and a description of what each one did:

 Packet #
Details
 6  IGMPv3 membership report from 192.168.1.11 to 224.0.0.22
 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 224.0.0.252: 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
        192.168.1.13
 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!
Kevin


Cracking the hash with Kali:

Screenshot of responder and hashcat

Thanks to Bsides SLC 2016 for hosting the cool class where I was introduced to this technique.

tagging:

Pages

Subscribe to RSS - kgeil's blog