Skip to content

Encryption

This documentation provides a detailed overview of the encryption protocol utilized for securing the internal communications between the Command and Control (C2) system and its agents. The design of this encryption ensures it operates seamlessly behind the scenes, such that plugin operations remain unaffected by these security measures. This specificity in knowledge requirement is directed towards developers engaged in crafting custom agents or modifying the C2 framework. It ensures that while these developers are equipped to uphold or advance the protocol's security aspects, plugin developers can focus solely on their plugins' functionality, without the need to delve into the encryption mechanism's intricacies. This approach optimizes the development process, ensuring security enhancements are centralized and do not impose additional complexity on plugin development.

Main logic

  • When the Command and Control (C2) system generates an agent, it typically incorporates at least one listener Type-Length-Value (TLV) structure into the agent's configuration, as outlined in the "C2 and agent communication protocol" document. To facilitate encryption, the C2 is also required to embed an "Agent generic configuration" TLV structure into the agent. This structure is detailed in the same document at section 2.6 and is advised to be placed before any Listener TLVs within the agent's configuration.
  • The "Agent generic configuration" TLV structure must include a specific child value, designated as 0x1, which contains the RSA public key in DER (Distinguished Encoding Rules) format. Upon successfully parsing this information, the agent initiates the use of this RSA public key for encryption purposes. Furthermore, if the "Agent generic configuration" TLV structure includes another child value, labeled 0x2, this value is interpreted as the GUID (Globally Unique Identifier) or UUID (Universally Unique Identifier) associated with the public key. This inclusion enhances the security framework by ensuring that each agent's communication is securely encrypted, leveraging the RSA public key for encryption and potentially utilizing a unique identifier for the key, thereby fortifying the integrity and confidentiality of the C2-agent communication channel.
  • Upon detecting the presence of a public key, the agent proceeds to generate a symmetric AES (Advanced Encryption Standard) key, which is then embedded into the metadata under field 0x10. This metadata, encrypted using the provided public key, is subsequently integrated into an "Encrypted metadata" TLV (Type-Length-Value) structure, as detailed in the "C2 and agent communication protocol" document at section 3.3. Additionally, if a UUID (Universally Unique Identifier) or GUID (Globally Unique Identifier) for the public key was specified, this identifier is also incorporated into the TLV as a sub-value under 0x2. This process results in three potential representations of metadata:
    • NO ENCRYPTION: plain metadata in TLV type 0x11
    • ENCRYPTION BUT NO UUID/GUID SPECIFIED: encrypted metadata with type 0x11 inside TLV with type 0x12
    • ENCRYPTION AND UUID/GUID SPECIFIED: encrypted metadata with type 0x11 inside TLV with type 0x12 along with UUID/GUID value
  • Both command TLVs sent by the C2 and result TLVs sent by the agent are encrypted with the AES key and wrapped inside the "Encrypted data" TLV (described in the "C2 and agent communication protocol" document at section 3.4).

Symmetric cipher modes

The agent selects the symmetric cipher mode and advertises that choice to the C2 in agent-metadata field 0x11 (see C2 protocol §2.2). The C2 honours that value for every subsequent encrypted exchange with the agent.

0x11 value Algorithm Key size IV / nonce size Authentication
0x00 none — no encryption — — —
0x01 (default) AES-128-CBC with PKCS#5 / PKCS#7 padding 16 bytes 16-byte IV —
0x02 AES-128-GCM 16 bytes 12-byte nonce 16-byte authentication tag

Implementation notes:

  • The AES key transported in metadata field 0x10 is always 16 bytes (AES-128) regardless of the selected mode. Implementations of custom agents or relays must not send a different key length.
  • For GCM mode, the 16-byte authentication tag is appended to the ciphertext (ciphertext || tag). Decryption consumes the trailing 16 bytes as the tag — implementations must reject inputs shorter than 16 bytes.
  • The IV / nonce is transported in the Encrypted data TLV field 0x04. For GCM the nonce must be 12 bytes and must be unique for each message under the same key; reusing a GCM nonce with the same key catastrophically breaks confidentiality and authenticity, so generate it from a cryptographically secure RNG for every outgoing packet.
  • Although the wire format permits omitting field 0x04 (null IV), the production server always emits a fresh IV / nonce when encryption is active. Custom listeners and agents should rely on the IV being present and should not depend on the null-IV fallback path.

Details - metadata encryption

  • When the metadata exceeds the size limit of the public key, it necessitates partitioning the data into segments that align with the key's capacity. For instance, with a 4096-bit key pair, if the metadata is 600 bytes in size, the encryption process would divide the metadata into two blocks suitable for the key's encryption threshold. This approach ensures that each segment of the metadata is encrypted securely within the constraints of the key's size.