Didier Stevens

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

This new version brings an update to the statistics in file 1768.json.

1768_v0_0_8.zip (https)
MD5: C410C38FC2B5F0B2C3104D7FC1D35C58
SHA256: 9374650575E0F15331CE05ACFD2BFA4CD6EBEB1497207B9B6D4B1F7A0214457D

This new version of base64dump brings 2 new features:

• support for ASCII85 encoding: a85
• selecting of the largest result: -s L

base64dump_V0_0_17.zip (https)
MD5: B535A0B9E73D068380078FC5006756E8
SHA256: DDC67BEBC5C3407213673C0228E84796E6816294A029997542BA7DD9AF659C4E

This version has some Python3/Linux/MacOS fixes.

re-search_V0_0_18.zip (https)
MD5: 1BCA3B59B719FAFD6016D2F9F32F1A05
SHA256: 9E4807D3CE0EC320028AC760D3915F4FC0CBF6EC6E20FC9B2C91C54E74E6F548

This new version of AnalyzePESig, my tool to analyze the digital signature of PE files, brings some major updates:

• Support for UNICODE filenames
• Reintroduction of the capability to verify the signature of non-PE files, like .MSI files

And several bug fixes.

AnalyzePESig_V0_0_0_8.zip (https)
MD5: C14A2C8AA91D34F534B4F76E7014E3A9
SHA256: BCCF90BF6E4C26C33BF16DA20CF220DAE8D748B942224659DC720B35BB8EFE86