blog

Developing a custom C2 Framework: Encrypted Comms

Some of my readers know that I have been working on my own C2 Framework during the last 7 to 8 months. In this post I want to share the current state of its communication channel methodology.

Here is a general overview on how the C2 operates:

1. implant is delivered to the target (phishing, RCE, SMB, etc)
2. implant connects to the C2 teamserver using a custom encrypted communication channel
3. implant authenticates and registers on the teamserver
4. teamserver accepts new connection and starts listeners (HTTP, HTTPS-mTLS, SMB, DoH, DoQ, DNS-over-WARP, Wireguard)
5. implant listens constantly for new tasks with a predefined sleep mask
6. operator/leader connects to the teamserver via gRPC-mTLS
7. operator/leader creates a new task (for example a recon command)
8. teamserver registers the task into a FIFO queue and sends it to implant
9. implant executes task and sends output back to teamserver for shared retrieval
10. operator/leader can view the output as is
11. if implant receives a suicide command it will fully delete its presence on the host system

This flow also resembles the common functionalities of C2 frameworks (command-and-control) such as CobaltStrike, Covenant, Mythic, Silver, and Havoc. Also for reference, I have written 80% of the planned functionality already and it is in private beta. For the nerds under you here are the tech usage:

• Teamserver: Written in Golang (gRPC-mTLS and custom encryption channel)
• Implant: Written in Rust (custom encryption channel)
• Listeners:
  • HTTP: Base HTTP with encrypted comms
  • HTTPS-mTLS: Mutually Authenticated HTTPS
  • SMB
  • DoH: Custom DNS-over-HTTPS exfiltration and infiltration
  • DoQ: DNS-over-QUIC
  • DoW: DNS-over-WARP using Cloudflare WARP 1.1.1.1
  • Wireguard: Custom VPN exfiltration and infiltration
• Operator/Leader: Written in C++11 (gRPC-mTLS)

For now lets focus on the custom encrypted base communication layer as this is the part where I have spent most time working on it. I am coincidentally also a big fan of advanced cryptography so you might find its resemblance in the implementation accordingly.

Bidirectional Client-Server Communication

If the teamserver sends data to the implant and if the implant sends results back to the teamserver, the communication will go through the same flow.

Age Encryption and Secure Key Exchange

The first layer for our new encrypted communication channel is Age Encryption which is a new type of asymmetric encryption scheme that is originally inspired by PGP. Age means Actually Good Encryption. To take the initial plaintext and encrypt it with Age, we need the recipients public key. Once we have that, we can encrypt the plaintext using Age and the private key so that it is only decryptable by the recipients public key. After that, we enter the next encryption layer.

X-ChaCha20Poly1305

The next encryption layer is using X-ChaCha20Poly1305 for encryption and verification at the same time. This layer takes the previously Age encrypted output as a parameter. The raison-d’etre why I chose this mechanism for my second layer was, because I can use the ChaCha20 part as my symmetric encryption and directly use Poly1305 to verify if the encrypted ciphertext has been tampered or in anyways been modified. Also I use a 256bit dynamic key for ChaCha20. The output of this layer will be used for the third layer.

Streamlined NTRUprime

The third and final (kinda) encryption layer, again takes the ciphertext of the previous layer as an input parameter. I chose Streamlined NTRUprime since it is the strongest known Post-Quantum Safe scheme. First we will create a new keypair on each side (implant and teamserver) and then securely exchange it so we can encrypt the X-ChaCha20Poly1305 ciphertext. Then we take the finalc ciphertext and put it into the final layer.

HMAC-SHA512

The final layer for this communication scheme is a HMAC using SHA512. The HMAC is formed in the following format:

HMAC(Nonce:Timestamp:SHA512:Ciphertext)

The first part is a truly-random Nonce (Number-used-Once) that is used to prevent replay-attacks and to uniquely identify each implant and teamserver. The second part forms the current timestamp in unix millisecond epoch format. After that we add the SHA512 value of a hardcoded PSK (presharedkey) and finally add the previous ciphertext. With this HMAC we can prevent replay attacks, request-spoofing and are on a very safe side. After this, the data is sent to the counterparty for decryption where it goes the same way but inverted.