I’ve written about infrastructure for red team operations before. Infrastructure are the servers, domains, and other assets that support your ongoing operation against a target network.
Sometimes, your infrastructure will become known and understood by the blue audience you’re working to train. At these times, it’s usually prudent to take steps to extend or change your infrastructure to stay one step ahead. That’s the subject of this blog post.
Rolling Redirectors
I highly recommend that you always use redirectors when you setup your initial infrastructure. A redirector is a server that forwards traffic to your Cobalt Strike team server. Ideally, your target network should never touch your team server infrastructure directly. It should always interact with you through a redirector.
If this is how your infrastructure is setup, then keeping ahead of your training audience is pretty easy. Simply stand up new redirectors, assign domains to these redirectors, and update your listener configuration to reference these new redirectors. Previously deployed Beacons will call home to the old configuration information but any new Beacons you spawn will call home to the new hosts.
Rolling Team Servers
Let’s say you want to re-roll an active team server to another server. Your plan is to copy Cobalt Strike to the new system, start it, configure it, and point your redirectors and domains to this new team server. This team server has Beacons calling back and you don’t want to lose them in this move. This is doable.
Early into Cobalt Strike’s life, I made the decision to design Beacon’s communication scheme to not depend on state in the team server. I did this to make sure Beacon sessions could recover in the event of a team server restart.
Beacon communication is dependent on one piece of state though: the key material for the team server. When you first create a Beacon listener, Cobalt Strike generates an asymmetric key pair for your team server. This file is .cobaltstrike.beacon_keys in the directory you ran the team server from. Copy this file to the folder you will run the Cobalt Strike team server from on the new system. If you don’t, you will not have control of any previously deployed Beacons calling home to the new team server.
When you roll team server infrastructure, it’s also imperative that you use the Malleable C2 profile. The Malleable C2 language compiles into a form that, quite literally, rewrites how Beacon and Cobalt Strike communicate with each other. If you do not bring your profile over to the new server, the team server will not know how to interpret callbacks and other messages from previously deployed Beacons.
If you move the key material over, keep the same Malleable C2 profile, and take care to point your old redirectors [or domains] at the new server–you will recover existing callbacks without trouble.
Migrating to New Team Servers
Rolling redirectors is a common task. Sometimes, I have to roll team servers, but this is more rare. I don’t like to take functional infrastructure down if I have to. My preference is to stand up new infrastructure and migrate existing accesses to it.
To migrate accesses from one team server to another:
Stand up new infrastructure. Take care to create your redirectors and assign domain names to your redirectors [or the team server itself].
Connect to the old infrastructure with your Cobalt Strike client.
If the accesses calling back to this old infrastructure are persistent, you have your work cut out for you. You will want to redeploy your persistence with new artifacts that point to the new infrastructure. A script to deploy persistence can help a great deal here.
If you just want to migrate existing callbacks, this is easy enough. Create a foreign listener on the old team server that points to your new one. Then highlight all of your Beacons, right-click, and select Spawn. This dialog will let you choose a listener to spawn on all of these sessions. Choose your foreign listener. As accesses check in on the old team server, you will see accesses show up on the new one.
The Spawn workflow is easy, but it’s not the best for OPSEC. It spawns a new process and injects your stager into it. You have the option to inject a Cobalt Strike listener into an existing process instead.
Here’s how to do that:
Highlight all of your Beacons and go to Explore -> Show Processes. This action will task all of the Beacons to send back a process list and these lists, for each of your sessions, will show up in one window. Here, you have the opportunity to sort your processes by name and mass inject your foreign listener into the same process on all of these sessions.
Parts 1 and 2 of Advanced Threat Tactics discuss infrastructure and operations. Part 4 of Advanced Threat Tactics discusses Session Passing.