Red Teaming and Command & Control in Cybersecurity Explained

Red teaming, in an information security context, is an adversarial-based offensive activity against an organisation's assets, whether this is infrastructure, applications or people. Red teaming is a specialised penetration testing service offering wherein the attacker assumes the role of an advanced threat actor and attempts to compromise agreed upon components inside the target. The threat actors use Tactics, Techniques and Procedures (TTPs) in their compromise campaigns. It is designed to be stealthier than a typical penetration test and test the defences of a network against a persistent attacker. It is also goal driven to provide focus and guide the test towards what the targeted organisation sees as its most valuable assets rather than the common misconception of "get domain admin". Mitre's ATT&CK framework, provides a comprehensive breakdown of all the different tactics in a red teaming engagement and outline of all different techniques inside each tactic.

Command and Control - Theory

Command and Control (C2 for the remainder of this post) is a dedicated tactic in the Mitre ATT&CK framework consisting of different techniques, each describing different ways to achieve a persistent connection between the 'implants' (software agents running on exploited workstations providing the ability to run commands and retrieve results) and the command and control server. 

Protocols

Choosing the C2 protocol is not a trivial task as, in most cases, this governs whether a persistent connection will be established back to the attacker. Select a protocol operating on a non-standard port (trying to get an HTTPS connection out on ports  8080 or 8443), or make uneducated assumptions, (assuming there is no proxy present on the exploited organisation’s  infrastructure) and, no matter the sophistication of the attack delivery or payload, you will still end up empty-handed.

Having said all that, one can - in the vast majority of cases - count on two protocols being allowed to communicate with external servers, namely HTTP(S) and DNS, so a very large part of implants use one of these protocols to reach their C2 servers.

Purpose and operational security considerations

Each of the above protocols has its strengths and weaknesses and depend on implementation. HTTP may be a bit more monitored/controlled (see site categorisation) on a customer's infrastructure while DNS may go unnoticed. On the other hand, HTTP can be used to transfer a fair amount of data at once while with DNS, you will end up making so many requests there is a good chance you will end up losing the covertness it initially provides.

Another thing one will need to consider when choosing a C2 protocol is the purpose of using the particular protocol. In any red team engagement, we try to use different tools, protocols, hosting providers and infrastructure in order to achieve operational security and resilience. For the topic at hand, in each red team exercise we are using at least two different C2 channels, sometimes, even more, depending on the geographic spread of the target organisation. Regardless of the number, they all fall conceptually into two discrete categories:

• Short haul: These are C2 channels that provide a semi-interactive communication channel between the implant and the C2 server. As such they have extremely short call-back timeouts.
• Long haul: These are C2 channels mostly related to persistence, making sure that the operators can restore access to the targeted organisation. As such, there is no real need for short call-backs, and even then, the call-back is not necessarily massive in terms of transmission size. There have been engagements where, although this channel existed and deployed, it was never used because access to exploited endpoints was never lost. Think of it as an insurance policy, you don't use it per se, but you are glad it is there should you know what hits the fan.

A Deep Dive into Red Teaming and Command & Control Protocols

Putting all the above in practical use, in red teaming engagements we are using a mixture of domain names, protocols and tools to make sure we are executing the engagement in a timely, yet operationally secure manner.

• Short haul: We are using an HTTP(S) based C2 connection for all our semi-interactive access. There are a few available C2 frameworks that make heavy use of this protocol for implant communication (we will be having a post out soon where we have a first look at some of these frameworks, installing and running a sample implant deployment. Our suggestion is, test, pick and use one that makes more sense to you and the infrastructure you are attacking. By testing, we mean running it in a controlled environment, going through all its functionality and noting down the IoCs it produces).
• Long haul: We especially like DNS for that. It is simple (well, kind of!) and, in the vast majority of cases, it can egress even the most restrictive environments. Despite its apparent benefits though, offensive toolkits were slow to implement support for the DNS protocol for their C2 communications. Even the gold standard of adversarial toolkits, CobaltStrike, did not have a pure DNS communication channel until version 4.0 released in early December 2019. You can configure your long-haul implants to pingback once or twice per day, and you have a pretty below-the-radar, C2 channel established.

If you couple the above with two or more domains, each one is serving a particular type of C2 protocol, then you have a pretty resilient C2 capability. In reality, the short-haul implants have a higher risk of being identified. By introducing a long-haul implant, you provide yourself with the ability to respin a short-haul implant with different IoCs, thereby bypassing any custom detection the targeted organisation put in place to detect the red team operators.

DNS tooling for C2 communications

We talked about the lack of tooling regarding the implementation of a DNS-based C2 protocol. We were more or less limited to using DNS-Shell from Sensepost or writing our own implant. DNS-Shell worked well enough for a while, provided we were happy with its single-channel limitation (a server can only communicate with a single implant). While we are not spreading long haul implants on every workstation/server we hop onto, we do have 3 or 4 running in different parts of the targeted organisation's infrastructure. As a result, just spinning a few instances means we bypass DNS-Shell's limitation. The client-side utilises PowerShell; the enhanced optics Microsoft built on the recent PowerShell versions encouraged us to move forward.

Eventually, we built our implant communicating over the DNS protocol, so we introduce you to RETURNINGPATIENT.

Hello RETURNINGPATIENT!

So, we built RETURNINGPATIENT to fill the gap we had with a reliable DNS-based C2 channel. In deciding to create RETURNINGPATIENT, we had a clear vision of the purpose of this tool and, while we were often tempted to stray away and add features, we stayed true to our initial design decisions.

There will be a more detailed presentation of RETURNINGPATIENT but for the sake of this post RETURNINGPATIENT:

1. Is a single-purpose, very specific tool;
2. Is designed as a long haul C2 communication channel;
3. Utilises only DNS as a call back mechanism;
4. Is written in .Net Core 3 (C#) implant and Web2py (Python3) server;
5. Supports three functions:
1. check back: to check back and see if it has any pending actions.
2. execute command: execute a shell command
3. download file: specifically used to download and deploy [new] short haul implants
6. Does not support or care at all about lateral movement, privilege escalation or any other red teaming lifecycle actions
7. Supports multiple users and multiple campaigns running off the same server.
8. Encrypts the data being sent back to the server using AES symmetric encryption.

RETURNINGPATIENT is available here.

We will be following up with a more detailed post going over installation and a simple workflow to help you get up and running with RETURNINGPATIENT.