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.
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 usingInterfaces
. There are two types ofRelays
:Gate Relays
(orGateways
) andNode Relays
.Gateway
- a specialRelay
that controls one C3 Network. A C3 Network cannot operate without an operationalGateway
. TheGateway
is the bridge back to the attacker’s infrastructure fromNode Relays
. It's also responsible for communicating back to a third-party C2 server (such as Cobalt Strike’s Teamserver).Gateways
should always be hosted within attacker-controlled infrastructure.Node Relay
- an executable to be launched on a compromised host.Node Relays
communicate throughDevices
either between one another or back to theGateway
.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 someRelay
and their purpose is to extendRelay's
capability. Currently there are three types ofInterfaces
:Channels
,Peripherals
andConnectors
.Devices
- common name forChannels
andPeripherals
. This abstraction is created to generalizeInterfaces
that are able to be used onNode Relays
.Channel
- anInterface
used to transport data between twoRelays
.Channels
works in pairs and do not support the one-to-many transmission (seeNegotiation Channels
).Negotiation Channel
- a specialChannel
capable of establishing regularChannel
connections with multipleRelays
. The negotiation process is fully automatic.Negotiation Channels
support only negotiation protocol and cannot be used in any other transmission.Gateway Return Channel (GRC)
- the configuredChannel
that aRelay
will use to send data back to theGateway
.GRC
may be a route through anotherRelay
. The firstChannel
(initial) on aNode Relay
is automatically set asGRC
for thatNode Relay
.C3 Minimal MTU
- the minimal portion of data that every C3 Channel is required to be able to send. CurrentlyC3 Minimal MTU
is 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.Peripherals
talk to their native controllers via aController
. 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 forPeripherals
andConnectors
.Device ID
- a dynamic ID that uniquely addresses oneDevice
on aRelay
.Agent ID
- a dynamic ID that uniquely addresses aNode Relay
.Node Relays
instantiated from the same executable will have differentAgent IDs
.Build ID
- a static ID that is built into everyRelay
. Stays unchanged over reboots.Route ID
- a pair of anAgent ID
and aDevice ID
. Used to describe one "path" to aNode Relay
(Node Relays
might be reachable via manyRoutes
).Route
- a "path" to aNode Relay
. EveryRelay
keeps a table of all of their childRelays
(and grandchildren, grand-grandchildren, and so on) along withChannel
Device IDs
used to reach that particularRelay
(seeRoute ID
). When a packet from theGateway
arrives to aNode Relay
, routing table is used to choose appropriateChannel
to send the packet through to the recipient.Update Delay Jitter
- delay between successive updates of anInterface
(in case ofChannels
- calls to OnReceiveFromChannel method). Can be set to be randomized in provided range of time values.
BSD 3-Clause License
Copyright (c) 2018-2019, MWR Infosecurity All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
-
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
-
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
-
Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.