上QQ阅读APP看书，第一时间看更新

Hash capture with LLMNR/NetBIOS NS spoofing

Windows machines are brothers, always willing to help out when a fellow host is feeling lost and lonely. We're already used to relying on DNS for name resolution. We're looking for a name, we query our DNS server, and if the DNS server doesn't have the record matching the request, it passes it along to the next DNS server in line. It's a hierarchical structure and it can go all the way up to the highest name authorities of the entire internet. Local Windows networks, on the other hand, are part of a special club. When you share the same local link as another Windows computer, you can broadcast your name request and the other Windows boxes will hear it and reply with the name if they have it. Packets of this protocol even have a DNS-like structure. The main difference is it isn't hierarchical; it is only link-local, and it can't traverse routers. (Can you imagine the large-scale distributed DoS if it could?) This special Windows treat is called LLMNR or its predecessor, NetBIOS NS. It doesn't have to be on, and secure networks should be disabling it via group policy to let DNS do its job. However, it's very commonly overlooked.

I know what the hacker in you is saying: Since LLMNR and NetBIOS NS are broadcast protocols and rely on responses from machines sharing the link, we should be able to forge replies that point a requestor to an arbitrary local host. An excellent point! And since we're talking about local Windows resources, redirecting a request for a file share to our listener is going to cause the victim to authenticate, except this time we wait for the target to initiate the communication – no social engineering tricks required here.

Let's get straight to it. There are a few ways to do this, including with Metasploit. But I'll show you the real quick-and-dirty way of doing this in Kali: with responder, a straightforward Python tool that will simply listen for these specially formatted broadcasts and kick back a spoofed answer. Remember, we're listening for broadcasts – no promiscuous sniffing, no ARP spoofing, no man-in-the-middle at all. We're just listening for messages that are actually intended for everyone on the subnet, by design.

Fire up responder's help page to review its features with:

# responder -h

Obviously, this is a pretty sophisticated tool, but we'll keep it simple. We identify our interface with -I, force an authentication method downgrade with --lm, and -v for verbosity so we can see more of the action.

You'll notice in the help page that --lm is considered legacy and won't work beyond Windows XP/2003. While this may be true for LM hashes per se, it will cause slightly weaker NTLM authentication depending on how the client is configured. I always keep this one turned on for this purpose.

After running this command, we see responder is up and running with its ears wide open:

# responder -I eth0 --lm -v

Meanwhile, back at our target PC: oh, dagnabbit! I fat-fingered the name of the printer file share I need to access. Oh well, I guess I'll try again:

Meanwhile, back at our attacking Kali box: excellent, we have ourselves an NTLMv1 authentication attempt. The only downside to this tool is it doesn't take the time to gift-wrap the goodies, so prepare this input for your cracker accordingly:

You probably noticed that we did not define a server challenge! That's right, we didn't, so the challenge was randomly generated and you'll want to make sure your cracker is using the right challenge value.

We've looked at nabbing Windows hashes off the network. Now, we have some juicy-looking credentials to break open and hopefully leverage to log in to all kinds of services, as we know how insidious password reuse is, no matter how good your pen test client's training might be. Let's move on to the art of password cracking.