An aggregator for digital forensics blogs
This new version of 1768.py, my tool to analyze Cobalt Strike beacons, adds some small changes, like extra tests and defines more field names.
1768_v0_0_10.zip (https)This new version of my tool to decrypt Cobalt Strike metadata, now supports transformations.
By default, encrypted metadata in Cobalt Strike traffic is encoded with BASE64 and then transmitted via the Cookie header in HTTP(S) requests.
This metadata is encrypted with a public RSA key, and can be decrypted if the private key is known.
Here is an example of a malicious beacon with a specific metadata encoding.
Analyzing the beacon with my tool 1768.py yields the following information:
First: a public key (field 0x0007) is used, for which we know the private key: thus we will be able to decrypt the metadata.
Second: the encrypted metadata has a specific encoding (field 0x000c). This beacon was configured with a profile that specifies that the encrypted metadata must be encoded with BASE64 URL-safe (this is a variant of BASE64, that uses characters – and _ in stead of + and /). Then it is prefixed with string __cfduid= and transmitted via the Cookie header.
An error will result when this data is processed by tool cs-decrypt-metadata.py without providing the transformation instructions:
The following transformation instructions must be provided to properly decode and decrypt the metadata: 7:Metadata,13,2:__cfduid=,6:Cookie
This is done with option -t:
cs-decrypt-metadata_V0_0_2.zip (https)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:
Receiving the data (print)Removing 1522 bytes from the end of the received dataRemoving 84 bytes from the beginning of the remaining dataRemoving 3931 bytes from the beginning of the remaining dataDecoding this remaining data with a BASE64 decoder for URLsXOR-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):
Encoding the encrypted metadata with a BASE64 encoder for URLsprepending value __cfduid= to this base64-encoded dataIncluding 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:
XOR-ing the encrypted data with a 4-byte key random key, that is prepended to the XORed dataEncoding the resulting data with a BASE64 encoderTransmitting 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:
XOR-ing the session id with a 4-byte key random key, that is prepended to the XORed dataEncoding the resulting data with a BASE64 encoder for URLsIncluding 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)