C3 (Custom Command and Control) is a tool that allows Red Teams to rapidly develop and utilise esoteric command and control channels (C2). It’s a framework that extends other red team tooling, such as the commercial Cobalt Strike (CS) product via ExternalC2, which is supported at release. It allows the Red Team to concern themselves only with the C2 they want to implement; relying on the robustness of C3 and the CS tooling to take care of the rest. This efficiency and reliability enable Red Teams to operate safely in critical client environments (by assuring a professional level of stability and security); whilst allowing for safe experimentation and rapid deployment of customised Tactics, Techniques and Procedures (TTPs). Thus, empowering Red Teams to emulate and simulate an adaptive real-world attacker.
Attackers must establish command and control (C2) to gain influence within their target environments in order to pursue their goals and objectives. It is therefore arguably one of the most important parts of the cyber kill chain because without it any payloads that are successfully delivered operate blindly, cannot provide network level pivoting and near real-time interaction. It is no surprise then that organisations have been imposing more controls against what types of communications are allowed from systems and a priority has been placed on defensive teams to be able to effectively detect C2. This is emphasised by two out of the twelve columns of Mitre ATT&CK being related to this area, ‘Command and Control’ and ‘Exfiltration’.
The first proof of concept of C3 was presented at BlueHat v18 by William Knowles and Dave Hartley. Since then it has been refactored and some aspects reimagined into what it is today by a team of developers heavily influenced by members of the MWR Red Team.
C3 is designed to be an easy and intuitive interface that allows users to form complex paths during adversarial simulations. This section provides an in-depth guide of how to use C3, from compilation through to code execution.
See this blog post for a detailed tutorial.
For contribution guide (how to develop a Channel tutorials), see this page.
The most commonly used terms in C3:
Relays- stand-alone pieces of C3 Networks. They communicate using
Interfaces. There are two types of
Gateway- a special
Relaythat controls one C3 Network. A C3 Network cannot operate without an operational
Gatewayis the bridge back to the attacker’s infrastructure from
Node Relays. It’s also responsible for communicating back to a third-party C2 server (such as Cobalt Strike’s Teamserver).
Gatewaysshould always be hosted within attacker-controlled infrastructure.
Node Relay- an executable to be launched on a compromised host.
Node Relayscommunicate through
Deviceseither between one another or back to the
Interface- a high level name given to anything that facilitates the sending and receiving of data within a C3 network. They are always connected to some
Relayand their purpose is to extend
Relay'scapability. Currently there are three types of
Devices- common name for
Peripherals. This abstraction is created to generalize
Interfacesthat are able to be used on
Interfaceused to transport data between two
Channelsworks in pairs and do not support the one-to-many transmission (see
Negotiation Channel- a special
Channelcapable of establishing regular
Channelconnections with multiple
Relays. The negotiation process is fully automatic.
Negotiation Channelssupport only negotiation protocol and cannot be used in any other transmission.
Gateway Return Channel (GRC)- the configured
Relaywill use to send data back to the
GRCmay be a route through another
Relay. The first
Channel(initial) on a
Node Relayis automatically set as
C3 Minimal MTU- the minimal portion of data that every C3 Channel is required to be able to send. Currently
C3 Minimal MTUis equal to 64 bytes. Unless a chunk shorter than 64 bytes contains a complete packet, receiver Relay ignores it and sender Relay tries and re-sends last portion of data.
Peripherals- a third-party implant of a command and control framework.
Peripheralstalk to their native controllers via a
Controller. For example, Cobalt Strike’s SMB beacon.
Connectors- an integration with a third-party command and control framework. For instance the ‘External C2’ interface exposed by Cobalt Strike’s Teamserver through the externalc2_start command.
Binders- common name for
Device ID- a dynamic ID that uniquely addresses one
Agent ID- a dynamic ID that uniquely addresses a
Node Relaysinstantiated from the same executable will have different
Build ID- a static ID that is built into every
Relay. Stays unchanged over reboots.
Route ID- a pair of an
Agent IDand a
Device ID. Used to describe one “path” to a
Node Relaysmight be reachable via many
Route- a “path” to a
Node Relay. Every
Relaykeeps a table of all of their child
Relays(and grandchildren, grand-grandchildren, and so on) along with
Device IDsused to reach that particular
Route ID). When a packet from the
Gatewayarrives to a
Node Relay, routing table is used to choose appropriate
Channelto send the packet through to the recipient.
Update Delay Jitter- delay between successive updates of an
Interface(in case of
Channels- calls to OnReceiveFromChannel method). Can be set to be randomized in provided range of time values.