I published an update for my 1768.py tool, a tool to extract the configuration from Cobalt Strike beacons.

1768.py tries to extract the beacon configuration from payloads and process memory dumps. It looks for the embedded configuration, the TLV table that is XOR encoded (0x2E version 4).

Prior this version (0.0.20), process memory dumps were just handled as raw files.

This new version also looks for the "runtime configuration": this is a C/C++ array found on the heap, created by the beacon code by parsing the embedded configuration. This array contains values (integers and pointers) for each configuration item. An example can be found in this blog post.

For example, the portnumber is configuration item 2, and is stored as an integer in the third position of the array (array[2]).

The public key is configuration item 7, a binary sequence (ASN1 DER encoded). It is stored as a pointer (to the binary sequence) in the eigtht position of the array (array[7]). The binary sequence representing the public key, is also stored on the heap. Since we are dealing with pointer in C/C++, we have 32-bit and 64-bit implementations.

Since address translations need to take place, 1768.py require the python module minidump to be installed.

If it is not installed and a runtime configuration is found, a warning will be displayed:

When the module is installed, 1768.py can extract and parse the runtime configuration (if present in clear):

This is an example of a process memory dump that contains a runtime configuration, but no embedded configuration (or at least, with an encoding that 1768 recognizes).

It starts with "Runtime config" and tells you if it's 32-bit or 64-bit.

Process memory dumps can contain both an embedded and a runtime configuration, and then my tool will dump both:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com