Password Auditing with Metasploit

October 02, 2013

In today's Whiteboard Wednesday, David Maloney dives into password auditing techniques with Metasploit. He goes over the three main techniques which are brute force or online password attacks, hash cracking or offline attacks and password recovery attacks. To learn more about these techniques, watch the video above. Make sure to download Metasploit for password auditing!

Video Transcript

Hi, I'm David Maloney, a software engineer here at Rapid Seven on the Metasploit team. Today we're going to be talking about password auditing with Metasploit. So, when we're talking about password auditing, at least in terms of Metasploit, we're talking about three main areas. That's brut force, or online password attacks, offline attacks which are hash cracking, and password recovery attacks.

Show more Show less

So, to start off, let's talk about brut forcing. This is a topic most people have heard at least a little bit about. These forms of online attacks are when we try to log into a service with guest credentials over and over again. This is an extremely noisy technique and will very often trip alerts in the network that you're working in, and has the added drawback of potentially locking out accounts on the system.

However, it's the most surefire way to gain valid credentials on a service. In Metasploit Pro we have the ability to generate word lists based on rules that are defined by the user as well as to accept user input lists of user names and passwords, and use those to attempt to brut force various services on a target network. In the case of most of these services the gaining of successful credentials in brut force will result in a shell, which is of course one of our ultimate goals in Metasploit. So, brut force with proper word lists equals a command shell. Awesome.

So, that's our first technique of password testing. In addition to that we have the ability to steal passwords hashes from a number of places. A much safer way of gaining actual plaintext credentials is to take those hashes and crack them via various methods. Most of these we're going to accomplish with through the use of John the Ripper, which ships with all versions of Metasploit, Framework all the way up through Pro, and we have modules that handle the specific rule sets.

So, with Metasploit we can crack password hashes for the Windows operating system, most versions of Unix, Oracle, Postgrey, MySQL, and Microsoft sequel server, and all those with the exception of Postgrey use John the Ripper to crack those hashes. Postgrey we use a custom cracking routine that just does some brut force computation.

So, the beautiful thing here is that all of this ties together. So, if we manage to steal password hashes from somewhere in the environment, and we crack them and get plain text passwords, we can then take those cracked passwords and feed them back to the brut forcer to again gain a command shell, our ultimate goal. But, in the case of Windows passwords, if we have the actual NTLM has, we can use the SMB service to perform what's known as a pass the hash technique.

This is where we don't actually have to know what the plain text value of the password is, we can actually pass the NTLM hash as it is over the SMB protocol, and SMB will except it and validate that hash against the password itself, and we never have to know what the password actually is, and again that brings us back to our lovely command shell.

So, we have the ability to guess passwords online, to steal hashes and crack them later, or in the case of Windows just pass them right on and not care what they are. In addition to that, once we've actually gained a shell on a system, there are a number of different systems that will store passwords in some form. The operating system itself will of course always have to store it's passwords somewhere, but various connection software like FTP clients, SSH connection managers, RDP clients, servers, all have to store passwords in some form.

Now, if it's a client software like an FTP client or an SSH client, it has to store them in a way that it's reversible. So, you don't want to store them in plain text, although some of them do that, but you can't just hash them. So, you use some sort of encryption method to safely store those passwords on the local system so that when the program goes to make its connection it reverses the encryption on that password and sends it on to the server to authenticate. The problem is that most applications do this in a really ineffectual manner.

Some of them will use quote unquote custom encryption methods, which are easily reversible, and most of them use some form of static encryption key, which is a big no-no. The reason this is a no-no - well, there's two reasons this is a no-no. One is that the key is the same then for all users of the applications, so once you know the key you have it for everybody.

So, you can decrypt everyone's password in the entire world for that particular application. The other reason is that that encryption key is hard-coded somewhere into the application itself, which means that you can neither dissemble or debug that application and find that encryption key and use it to decrypt the passwords for your own purposes.

So, we have a number of modules in Metasploit that are post exploitation modules that search out these stored passwords, whether they're on a file system, the windows registry, in a database somewhere, doesn't matter. We find them, we've reverse engineered a lot of these encryption mechanisms, and we are able to locate the password, decrypt it, and save it back into the Metasploit database again, which can then be reused in our brut forcing sessions.

Because we have a known credential, this makes our brut forcing attack much quieter. If we've crack hashes, or if we've recovered passwords, we now have known credentials and we can tell our brut forcer, just use the credentials we know about. Now we don't have all these bad failed log-in attempts that are setting up alarms in our environment, and again we end up with a command shell.

So, you can see here we have three quick and easy ways to audit password experience within any network environment and determine just how much of a risk you're being exposed to by passwords. Thank you and we'll see you next week.