When conducting Red Team engagements, more than one Command and Control (C2) framework would typically be used as part of our delivery process and methodology. We would be unintentionally limiting our options if we only had one Command and Control framework to depend upon, which would be less realistic when comparing it to an attack from real threat actors who seem to have infinite time and resources available.
The use of multiple Command and Control frameworks is essential. When performing a Red Team engagement, all activities must be performed as close to reality as possible to assume due diligence.
1. What is a Command and Control (C2) framework?
A Command and Control (C2) framework is the infrastructure used by an attacker or adversary, which contains a collection of tools and methods used to communicate with devices where an initial foothold was gained during the initial compromise. The Command and Control communication method and infrastructure, also known as C2, are typically used during a Red Team attack emulation engagement, equivalent to how a real threat actor would perform an attack.
1.1. MITRE ATT&CK Tactics List
The MITRE ATT&CK framework lists tactics, techniques, and various sub-techniques (https://attack.mitre.org/tactics/TA0011/) that threat actors use to communicate with assets they control within the target organization's network:
- T1071 – Application Layer Protocol (SMB, SSH, or RDP)
- T1092 – Communication Through Removable Media (malicious USB)
- T1132 – Data Encoding (Base64 and Gzip)
- T1001 – Data Obfuscation (steganography)
- T1568 – Dynamic Resolution (dynamically to evade detection)
- T1573 – Encrypted Channel (encryption of communications)
- T1008 – Fallback Channels (alternative communications channel)
- T1105 – Ingress Tool Transfer (copy tools to compromised devices)
- T1104 – Multi-Stage Channels (first-stage and second-stage capabilities)
- T1095 – Non-Application Layer Protocol (ICMP, UDP, and SOCKS)
- T1571 – Non-Standard Port (HTTPS over port 8088 instead of 443)
- T1572 – Protocol Tunneling (encapsulate protocols in a tunnel)
- T1090 – Proxy (traffic redirection through a proxy)
- T1219 – Remote Access Software (Team Viewer, LogMeIn, and VNC)
- T1205 – Traffic Signaling (Port Knocking)
- T1105 – Web Service (Google or Twitter)
The tactic list described above can be seen as the starting block; the primary characteristics of a C2 framework are to handle most of the stages or activities that might need to be executed during Red Team engagements. A good Command and Control framework would contain most (if not all) of the tactics to be used as the preferred choice.
2. When are Command and Control frameworks used during Red Teams?
When comparing Red Team exercises with traditional Penetration Tests, characteristically, during Red Teams, there is much emphasis on not being detected by the target company’s internal security department, usually called the Blue Team. Staying undetected is one of the main reasons why C2 communication occurs in this specific way, as “stealth” is very important.
If you are interested in becoming a Red Teamer, look at Idan Ron’s interesting blog – “Want To Become A Red Teamer? This Is What You Need To Know” (https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/want-to-become-a-red-teamer-this-is-what-you-need-to-know/).
The type of communication method that C2 frameworks use is called beaconing, where a compromised device would routinely or irregularly “phone” home to the C2 infrastructure. When the compromised device connects outbound with the external C2, it checks for instructions to run, which can happen at regular or random intervals. For example, the beacon check-in times could be minutes or hours apart, making detection much harder than a constant outbound communications connection.
Considering the MITRE ATT&CK framework tactics list mentioned earlier, C2 frameworks can do much more than just running a couple of commands on the compromised device. Payloads or tools could be dropped, which can assist with activities such as the following (including but not limited to):
- moving laterally
- initiating multi-stage attacks
- exfiltrating data
3. Inside The Red Team Toolbox
Having a C2 framework in your Red Team toolbox can be critical to have during a Red Team engagement. A working beacon to the externally controlled C2 framework can be considered the pivotal starting point from where an attack emulation consultant begins the digital attack phase in a Red Team engagement.
3.1. The Red Team Attack Kill Chain
The Attack Kill Chain is the attack path or steps an adversary will follow during an emulated attack. The MITRE ATT&CK framework (https://attack.mitre.org/) has a holistic framework that defines various TTPs (Tactics, Tools, and Procedures), which can be used by both attackers and defenders when either emulating or preventing the steps in an Attack Kill Chain.
The actions being followed in a typical Red Team Attack Kill Chain consist of (but are not limited to) the following phases:
- Reconnaissance (OSINT – Open-Source Intelligence)
- Weaponization (payload/malware development)
- Delivery (for example, Phishing)
- Exploitation (of vulnerabilities)
For these steps to be successful, the adversary will have to be able to execute malware or some type of payload. During this stage, if successful, the payload would run a beacon that would call outbound to the C2 framework. The Red Team consultants will then proceed to try and achieve the objectives agreed with the client at the start of the engagement.
3.2. Red Team Dechaining
A vital characteristic of a Red Team emulation is that when a security control successfully blocks an attack attempt, the engagement doesn’t stop. The security control would be artificially “bypassed”, and the engagement will continue.
During Red Team engagements, this is typically the next phase after attacking from an external standpoint. The attack “dechain” is when the engagement is resumed from an “assumed breach” position. The Red Team consultants will then continue to follow the Attack Kill Chain from this “dechain” or “assumed breach” perspective.
This would emulate the attacker having a foothold within the network; for example, a user has clicked a malicious link, a payload has been executed, and a successful beacon has been obtained, which is calling back to the attacker’s command and control infrastructure.
4. Having Multiple Command and Control Frameworks
Even though having a C2 framework in your Red Team toolbox is critical, it is recommended to have more than one. The C2 frameworks could be either commercial or open source, as long as you have additional options when you run into comprehensive preventative security controls in a customer’s network.
Having more options allows Red Team consultants to leverage the various strengths of different C2 frameworks. Using lesser-known or less-used Command and Control frameworks could come in handy when the payload needs to, for example, bypass anti-virus. This is also extremely valuable when the Blue Team (security team of the organization) only monitors for specific traffic originating from a well-known C2 framework and can result in a lesser-known C2 beacon traveling undetected through the network.
Good commercial C2 frameworks worth mentioning are the following:
Open-source C2 frameworks that are interesting:
There are various types of C2 frameworks. An interesting compiled list with characteristics and abilities can be found here at the C2 Matrix (https://www.thec2matrix.com/matrix). It is recommended to choose the frameworks that are most appropriate to use when trying to achieve the predefined objectives during the attack emulation stage.
It is considered best practice to use multiple Command and Control frameworks. The most obvious reason is to expand your options during a Red Team engagement. This will help to achieve due diligence and give your clients a more realistic, rounded, and holistic result.
