Hands-On Penetration Testing on Windows
上QQ阅读APP看书,第一时间看更新

Configuring our SMB listener

We have the MSF console up and running, so let's set up our SMB listener. We run this command at the MSF prompt:

use server/capture/smb

As with any Metasploit module, we can review the options available in this SMB capture module by commanding: 

show options

The following screenshot illustrates the output of the preceding command:

Let's take a look at these settings in more detail:

  • CAINPWFILE defines where captured hashes will be stored, but in the cain format. Cain (the powerful sniffing and cracking suite mentioned earlier, written for Windows) will capture hashes as it does its job, and then you have the option to save the data for later. The file that's created puts the hashes in a format cain recognizes. You can point cain to the file that's created here, using this flag. We aren't using cain, so we leave this blank.
  • CHALLENGE defines the server challenge that is sent at the start of the authentication process. You'll recall that hashes captured off the network are not naked hashes like you'd find in the SAM, as they're password equivalents. They are encrypted as part of a challenge-response mechanism. What this means for us is we need to crack the captured hash with the same challenge, a number that's normally randomly generated – so we define it, making it a known value. Why 1122334455667788? This is simply a common default in password crackers.  The only key factor here is that we can predict the challenge, so, in theory, you can make this number whatever you want. I'm leaving it as the default so I don't have to toy around with cracker configuration later, but something to consider is whether a sneaky admin would notice predictable challenges being used. Seeing a server challenge of 1122334455667788 during SMB authentication is a dead giveaway that you're playing shenanigans on the network. 
  • JOHNPWFILE is the same setting as CAINPWFILE, but for John the Ripper. I know what the 19th-century British historian in you is saying: His name was Jack the Ripper. I'm referring to the password cracker, usually called John for short. We will be exploring John later, as it is probably the most popular cracker out there.  For now, I'll define something here, as the John format is fairly universal and it will make my cracking job easier.
  • SRVHOST defines the IP address of the listening host. It has to point at your attacking box. The default of 0.0.0.0 should be fine for most cases, but this can be helpful to define when we are attached via multiple interfaces with different assignments.
  • SRVPORT defines the local listening port, and as you can imagine, we'd only change this in special situations. This should usually stay at the default of 445 (SMB over IP).
The challenge/response process described here is NTLMv1. NTLMv2 has the added element of a client-side challenge. Crackers are aware of this and our SMB capture module will show you the client challenge when it captures an authentication attempt.

Let's define SRVHOST to the IP address assigned to our interface. First, I'll run ifconfig and grep out inet to see my IP address, as shown in the following screenshot:

Using the set command, we define SRVHOST with our IP address, as shown in the following screenshot

Even though this isn't technically an exploit, we use the same command to fire off our module, as shown in the following screenshot:

And that is it. It runs in the background so you can keep working. The listener is running and all you need is to point a target at your IP address.   

Check out the HTTP method for capturing NTLM authentication. Follow the same steps, except issue the following command at the MSF console prompt instead:  use auxiliary/server/capture/http_ntlm. This will create an HTTP link so the user will authenticate within their browser, which is potentially useful in certain social engineering scenarios. You can even SSL encrypt the session.