This is a bugfix version of cs-decrypt-metadata.py, my tool to decrypt Cobalt Strike metadata.
cs-decrypt-metadata_V0_0_3.zip (https)MD5: BC42AF00F35FE8460E8AA23F2B54A84A
SHA256: 13C62A515D49CF8DEF4A866B069AFC47885B13CAB3703AA529C214B88FF576D3
This is a bugfix version of cs-decrypt-metadata.py, my tool to decrypt Cobalt Strike metadata.
cs-decrypt-metadata_V0_0_3.zip (https)This is a bug fix version.
base64dump_V0_0_18.zip (https)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:

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:

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):

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:

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:

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)This new version brings an update to the statistics in file 1768.json.
1768_v0_0_8.zip (https)This new version of base64dump brings 2 new features:

This version has some Python3/Linux/MacOS fixes.
re-search_V0_0_18.zip (https)This new version of AnalyzePESig, my tool to analyze the digital signature of PE files, brings some major updates:
And several bug fixes.

This is a bug fix version.
pdf-parser_V0_7_5.zip (https)