When on a pen test, you’re going to get password hashes. It’s going to happen. Something that I like to see is where the credentials we have may also be used throughout the rest of the target network. There’s a couple different tools that you can use to rapidly check system hashes across an IP range, and I try to detail some of them below.
Note: THIS IS GOING TO GENERATE A LOT OF NOISE! I can’t reiterate that obvious fact enough. If you’re trying to not get caught, you do NOT want to rapidly check whether a single hash works against a large IP range.
Metasploit’s smb_login:
Metasploit has a module for verifying that the OS hash you’re specifying is valid for one or more IP addresses. It’s the auxiliary/scanner/smb/smb_login module, and definitely worth checking out. Armitage and Cobalt Strike both invoke this module when performing a “Check all creds” scan within their respective tools.
After loading the smb_login module, you’ll want to configure your options, I’ve provided mine below:
When I attempt to use this module (and really, any password checking tool listed here), I try to be as target as possible, so I typically disable the blank password check and the username as password option (unless either is actually the username and password). The reason I do this is because I’m testing a hash I already have obtained from another machine, not attempting to performing an online brute force attack.
After configuring the module with all the options it needs, you should run it and see something similar to the following (hopefully):
Hydra:
Hydra is probably among one of the most popular online password attacking tools out there today. It supports a large number of protocols, and what’s awesome is that Hydra does support checking windows hashes! To do this, we need to provide the user account we’re checking with the “-l” switch, provide the password hash with the “-p” switch, and the IP of the machine that we want to check (or a file with a list of IP addresses that we are attempting to check against). We also need to provide a couple options with the “-m” switch, specifically that we are checking a local account (or you can tell it to check a domain account) and that we’re providing a hash vs. a cleartext password. Finally, we tell Hydra the protocol that we want to target, and in this case, it’s smb.
When it’s all said and done, your console should look similar to the following:
Medusa:
Medusa is another tool that can be utilized to check Windows hashes against a large range of IP addresses. In this example, we’ll create files to store everything that we need to pass into Medusa. The “-H” switch is going to contain the list of IPs that we want to check, the “-C” switch is a file that contains our username and password hash we are checking, the “-M” switch tells medusa the protocol that we want to check, and the “-m” switch informs Medusa that we’re going to be checking with a password hash vs. a cleartext password.
Our password hash file should be in the following format:
Tester:1001:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::
Your console should look similar to the following:
One thing you could do is pipe the output into grep and just search for the “SUCCESS” string, and as you’re running your hash check, you’ll receive all the systems you are able to successfully log into.
Note: Upon being nearly completed with this article, a friend sent me another already published article on testing the speeds of online password tools, which can be viewed here.
So you can log in to a system just using the hash, not the password?
Yeah, ha, it’s how the OS itself interacts with other Windows systems. Now, you can’t just open a RDP connection to another machine, and type the hash, but you can use hashes you have to psexec into other machines without a problem.Wikipedia actually has a decent writeup on how it works. But if you use psexec, or any of the other tools I showed to interact with a Windows machine, you can log right in with the hash because Windows is basically interpreting the hash as the password.
Is there a patch to stop this from happening?
Nope. You can change how Windows is configured to prevent this, but you’ll basically break windows. Best defense – don’t let people get hashes and make sure all local accounts have different passwords in relation to other computers on the network.
In response to some of the comments, Microsoft actually has a pretty good write up on this, including the in depth technicals, and mitigations, in the document here. http://www.microsoft.com/en-us/download/details.aspx?id=36036