We ended yesterday’s story with what we hope was a successful password spray.  Let’s assume that we can then use one of the accounts we harvested in that exercise to VPN in and RDP to a host on the inside network.  
That’s a pretty safe assumption – it’s pretty common to get Domain Admin access from at least one of the harvested accounts in a password spray.

So, where do we go next from there?  Well, let’s take a look at LLMNR – Link Layer Multicast Name Resolution.  What’s that you say?  Think back, think waaaay back to Windows 95.  Back in those days, IP was pretty new to Windows admins, and name resolution tended to use WINS as much or more than DNS.  If you didn’t happen to have WINS or DNS set up, clients would send a local multicast request out on port UDP/5355 for name resolution.  And yes, that is still with us today.

But surely Windows 7 or 10 won’t actually *use* that, right?  Wrong-O!  LLMNR is still very much in the name resolution search order.  If you mis-type a server name when looking for or mounting a network share, mistype a printer name, or have a script that runs but targets a server that has been renamed or retired, the host will also make the LLMNR request.  For instance, trying to access "\\clown\college" will generate this packet:

A pentester can use a tool like responder to exploit this.  Responder for instance will respond with “Yes, That’s Me” to the LLMNR request, and the host will then attempt to connect, sending the user’s credentials to authenticate the connection (userid and password hash).  Running "responder -i <ip address> -I eth0" and capturing that same request as above will give you:
 

Oops.  You can then take that has as-is, feed it into hashcat (which just saw an awesome update yesterday by the way), and crack the password.  First, put just the hash we’re targeting into a text file, then use a decent dictionary.  Rockyou works nicely, the 1.7 million "consolidated" dictionary is my current go-to, but Troy Hunt's most recent 0.5 billion "pwnedpasswords" list might be a better option, stay tuned.
The syntax for today is hashcat64.bin –m 5600 hashes.in –a 6 -1 ?s?d dictionary.in ?1?1
This takes the dictionary file, and adds 2 digits of special characters / numeric digits to each word in the dictionary.

With 4 decent GPU’s, 1.7 million plus the 2 digits for one account goes pretty quick – 10 minutes does the job.

What does this mean?  What’s the point we’re making? The point of all this (aside from gathering credentials for the next pivot in your pentest) is to demonstrate that any malware or attacker capture these LLMNR packets once they are on the target network, and turn them into passwords.  If you are on the right subnet, the chances of capturing Domain Admin level credentials is almost 100% - people tend to embed credentials into scripts, creds turn into hashes once they hit the wire, and collecting the LLMNR packets gets you those hashes.

From a broader perspective, the real point and the real recommendation is that the customer should take a solid look at some hardening guides for both Windows and Active Directory - the Center for Internet Security is a good place to start for this ( https://www.cisecurity.org/cis-benchmarks/ ).  The best advice is to start at the top of the guide and work your way to the end, assessing each benchmark to see what it might break or affect in your environment.  I've never seen disabling LLMNR cause a problem in a production environment by the way, but please let us know in our comment form if you have!!

What should you recommend to your client?  Back to the specific recommendation, LLMNR is absolutely, positively NOT REQUIRED.  It can be easily disabled in Group Policy, and that setting should be applied globally (Computer Configuration / Policies / Admin Templates / Network / DNS Client / Turn off multicast name resolution).  LLMNR can also be disabled in the registry, for any stations that are not domain members.  Stand up a packet sniffer periodically, and look for udp/5355 packets to catch any stations that might have been missed.

===============
Rob VandenBrink
Compugen