This new version of 1768.py, my tool to decode Cobalt Strike beacon configs, brings proper decoding of malleable instructions.

And the license ID statistics have been updated, and 3 new private RSA keys have been added.

Fields 0x000b (Malleable_C2_Instructions), 0x000c (http_get_header) and 0x000d (http_post_header) contain instructions on how to transform data. Until now, my tool did not properly parse these instructions, because I had no need for them. It just extracted the strings found inside the binary data of these fields.

But this has changed, now that I’m improving my tools to parse and decrypt Cobalt Strike network traffic: I need these instructions to properly parse traffic.

Let’s start with a malicious beacon, that uses the default profile:

Field Malleable_C2_Instructions (0x000b) contains instructions on how to transform the data send by the team server to the beacon. For the default profile, like this sample, the instructions are just a print statement: this means that the received data can be decrypted as-is, that no transformation prior to decryption is necessary.

Field http_get_header (0x000c) contains instructions on how to generate the HTTP request that the beacon sends to the team server to obtain tasks it should execute. By default, this is done with a GET request. For the default profile, like this sample, the instructions explain how to transform the metadata. The encrypted metadata has to be BASE64 encoded, and then transmitted via the Cookie header.

Field http_post_header (0x000d) contains instructions on how to generate the HTTP request that the beacon sends to the team server to report the results (callbacks) of the tasks it has executed. By default, this is done with a POST request. For the default profile, like this sample, the instructions explain how to transform the session id and the encrypted callback data.

The session id has just to be transmitted via the id parameter in the POST request.

For the encrypted callback data (output), the instructions are just a print statement: this means that the data to be transmitted can be transmitted as-is, that no transformation prior to posting is necessary.

That was a malicious beacon with a default profile.

Now let’s take a look at another malicious beacon, with a custom profile:

For the received data (field 0x000b or the input, e.g., encrypted tasks received by the beacon), the following instructions need to be applied:

1. Receiving the data (print)
2. Removing 1522 bytes from the end of the received data
3. Removing 84 bytes from the beginning of the remaining data
4. Removing 3931 bytes from the beginning of the remaining data
5. Decoding this remaining data with a BASE64 decoder for URLs
6. XOR-ing the BASE64 decoded data with a 4-byte key that is found at the beginning of the remaining data

Remark that 1768.py reports these instructions twice: once in a human-readable format (see screenshot), and once in an encoded format between [] that my other tools can parse: [7:Input,4,1:1522,2:84,2:3931,13,15]

This data is transmitted by the beacon to the team server, via an HTTP request (GET in this sample). The headers to be included in this HTTP GET request are specified in field 0x000c:

And the metadata needs to be encoded and transmitted as follows (field 0x000c, Build Metadata):

1. Encoding the encrypted metadata with a BASE64 encoder for URLs
2. prepending value __cfduid= to this base64-encoded data
3. Including the resulting data in the GET request via the Cookie header

For the transmitted data (field 0x000d or the output, e.g., encrypted callbacks sent by the beacon), the following instructions (Build Output) need to be applied:

1. XOR-ing the encrypted data with a 4-byte key random key, that is prepended to the XORed data
2. Encoding the resulting data with a BASE64 encoder
3. Transmitting the data (print)

Field 0x000d also specifies the headers that need to be added to the POST request:

And field 0x000d also specifies how to transform and transmit the session id. The following instructions (Build SessionId) need to be applied:

1. XOR-ing the session id with a 4-byte key random key, that is prepended to the XORed data
2. Encoding the resulting data with a BASE64 encoder for URLs
3. Including this encoded data to the POST request via parameter __cfduid
   

The encoded instructions (for my other tools) are: [7:Output,15,13,4]

Remark: although I show these instructions for HTTP communication, they are also applied for other protocols, like HTTPS and DNS.

1768_v0_0_9.zip (https)
MD5: 2AFD580D2BDA78F6FA8A240947661E1F
SHA256: 45841091C6AF270A508674B31389CCB1ED44346CD3A146FBE7AFC21940B00548