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 by the AES key using AES/CBC/PKCS5Padding encryption and are wrapped inside "Encrypted data" TLV(described in "C2 and agent communication protocol" document at 3.4)

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.