Cloudy with a chance of redirectors
Leveraging a powerful Operator plugin to provision red team tools in the cloud
Operator is a command-and-control (C2) platform that is built around the concept of plugins. As a core system, Operator can manage agents, adversaries and attacks. But plugins can extend this to do pretty much anything. In this post, we’re going to deep-dive into the Cloud plugin, which is one of the most important plugins when it comes to running a realistic red team exercise.
First off, how do you get the Cloud plugin? After opening Operator head to the Plugins section and click on Cloud and follow the prompt to install it. You should be welcomed with this view:
Prior to Operator version 1.0, you will see a slightly different design but the functionality and options are the same.
So what can you do with this plugin?
Provision pre-compromised Windows or Linux servers
Provision full-blow test ranges with a SIEM
Let’s explore each.
#1: Provision redirectors
Why use redirectors? Safely accept connections over the internet.
A redirector is simply a Linux server that can accept network connections from the internet and proxy (redirect) them to a different computer. Redirectors are essential for a few reasons:
You can deploy an agent anywhere in the world and have it connect to your redirector instead of your desktop directly. Adjusting your firewall rules to accept agent beacons locally could create a dangerous security hole.
When you use a redirector, agents don't know your IP address. If the defense finds your agent and notices it is contacting IP address 188.8.131.52, they may start blocking traffic to that location. If 184.108.40.206 represents your redirector, you can simply deploy a new redirector to get around the defense. If this were your Operator IP address, you would have to configure a much different approach to work around the blocking (such as moving your physical location or using a dynamic VPN).
Operator redirectors work like this:
From the Cloud plugin, provision a redirector in either Amazon Web Services (AWS) or Google Cloud Provider (GCP) account. This will create the Linux server in your own account and establish a reverse-SSH tunnel between it and your Operator app.
Once provisioned (it usually takes 30 seconds) you can turn it on (look for the tunnel icon in your Operator dashboard) by clicking the host name. When a redirector is on, all agent ports (check the Settings section) will be connected to your redirector. This means, if you deploy an agent pointed at your redirector, the connection will now be directed to your desktop app.
Once your redirector is on, you can deploy a Pneuma agent to test it:
./pneuma -address 220.127.116.11:2323
You should see an agent beacon in.
If you have an Operator professional license, a tool called Switchboard will be automatically installed on any newly provisioned redirector. Switchboard is a systems application that allows you to easily share an agent’s beacons with teammates.
After provisioning a new redirector, you’ll see a new “manage” button appear on each host when you are turning them on or off. Clicking manage opens up this modal window representing your Switchboard options:
Here you can see everyone using your redirector. By default, it’ll be just you. But you can give your Switchboard’s host and password to a teammate, who can enter it in their Operator instance to connect.
From this modal window, anyone connected can enter the ports they want to “own” on the redirector. In the above example, you can see that the redirector’s 2324 port will direct all TCP connections to my (david[at]prelude[.]org’s) Operator instance.
Switchboard allows a team to share a single agent. For example, when running a security exercise, I may have all agents directed into my Operator instance. Then after a few hours I may have a teammate take over. Instead of redeploying the agents with a new address, my teammate can simply open Switchboard and “steal” the port from me, redirecting the agent to their Operator instance.
What did people do before this? Red teamers would typically install a network load-balancer, like HAProxy or a connection handling program, like SOCAT, and manually manage the connections via terminal.
#2: Provision pre-compromised servers
Why provision test servers? You may work on a MacOS and not have access to a Windows computer to test an attack on. Provisioning a real test machine allows you to quickly test your TTPs.
While redirectors are the main duty of the Cloud plugin, it’s not the only thing it can do. A second big feature of this plugin is the ability to quickly provision pre-compromised servers in your AWS environment.
Heading back to the Cloud plugin, you can select either a Linux or Windows server to deploy:
You simply select:
An agent to drop on the server after it is provisioned in order to compromise it
A redirector to point the agent toward
Which tools you want to install on the new server. A tool is an independent piece of software you want to provision with the server, such as a splunk or sysmon agent (above example). Different operating systems will offer different tools.
After deploying a server - and ensuring your chosen redirector is turned on - you should receive a beacon within 5-6 minutes.
The Editor section contains a handy utility for quickly testing TTPs against any connected agent. Just simply click the DEPLOY button when viewing any TTP to bring up the following modal window:
What did people do before this? Red teamers would typically use VMWare (expensive) or Virtual Box (not very user friendly) to deploy agents on different operating systems and test TTPs. Both of these options take significant resources (RAM/CPU) to run.
#3: Provision full-blow test ranges with a SIEM
Why provision a test range with a SIEM? Use this to quickly verify if your analytics are working.
The last feature of the Cloud plugin is the ability to deploy multi-machine test ranges, including a connected SIEM.
The process is the same as provisioning a single server, except select Splunk in the option list. The only new thing you’ll need to do here is enter how many Windows servers you want installed in your new range. The sysmon and splunk tools will be automatically selected and installed on all servers in your range.
After deploying, you will receive beacons from however many servers you entered into the range. Within 10 minutes, you will also receive an alert message with web authentication details to your newly provisioned Splunk SIEM.
What did people do before this? Red and blue teamers would either have a persistent test range set up somewhere, which could be labor-intensive to share, or they simply wouldn’t test analytics at all.
Hopefully this post helps you navigate through one of Operator’s most useful plugins. The Cloud plugin is a simple to use provisioning tool which manages the complexities of redirector connection handling and test range deployments.
Get your redirectors online. Test TTPs against real machines. Verify if your SIEM analytics are actually working. Do all of this - quickly - with the Cloud plugin.