Didier Stevens

Friday 31 December 2021

Update: base64dump.py Version 0.0.20

Filed under: My Software,Update — Didier Stevens @ 0:00

This new version brings a new encoding: zxcn

zxcn stands for “zero x comma no-leading zero”, and is very similar to zxc encoding (zero x comma).

Example of zxc: 0x90,0x0A,0x4D,0x5A

Remark the leading zero for value 0x0A (values smaller than 0x10).

With zxcn encoding, there is no leading zero for values smaller than 0x10.

Thus the example for zxcn becomes: 0x90,0xA,0x4D,0x5A

base64dump_V0_0_20.zip (https)
MD5: 10E130F7B989EDDBF03092B8AA0585E1
SHA256: BD7ADF465CA89B10D0591A6D73E6E97DA3EF313EA7C28C90DD59F0A5CBBEB9CD

Thursday 30 December 2021

Update: pecheck Version 0.7.14

Filed under: My Software,Update — Didier Stevens @ 0:00

This new version of pecheck adds support for dumping files (-D) while using option -l P.

pecheck-v0_7_14.zip (https)
MD5: 3B5CED47987F0395CC4BC795A938EA4A
SHA256: 547941BD830C22586CE0C509DE8406424C2EB02D0C5FEAA555C43C77FCCDE33D

Wednesday 29 December 2021

VBA: __SRP_ Streams

Filed under: Forensics,maldoc — Didier Stevens @ 0:00

Office documents with a VBA project that contains streams whose name starts with __SRP_, have had their VBA macros executed at least once.

As Dr. Bontchev describes in the documentation for his pcodedmp tool:

When the p-code has been executed at least once, a further tokenized form of it is stored elsewhere in the document (in streams, the names of which begin with __SRP_, followed by a number).

Thus in my maldoc trainings, I always explain that the presence of __SRP_ streams is an indication that the VBA code has been executed prior to the saving of the document, and vice-versa, that the absence means that the code was not executed (prior to saving).

I recently discovered that these __SRP_ streams are also created when the VBA project is compiled (without running the macros), by selecting menu option “Debug / Compile Project” in the VBA IDE.

Tuesday 28 December 2021

Update: cs-analyze-processdump.py Version 0.0.3

Filed under: My Software,Update — Didier Stevens @ 0:00

This new version brings some options to guide the XOR-key detection algorithm.

The beacon’s AES and HMAC key are contained in writable process memory: my tool cs-extract-key.py can detect these keys. But the beacon can be configured to encode these keys while it is sleeping. This feature is called a sleep mask, and uses a 13-byte long XOR key. The complete writable memory section that contains the beacon process data, like encryption keys, is encoded with this 13-byte long XOR key.

Since writable process memory sections contain a lot of consecutive NULL bytes (0x00), the 13-byte long XOR-key will be present in the encoded process memory (XORing 0x00 with a key gives the key).

My tool will try to detect this XOR-key, but searching for 13-byte long random byte sequences that appear often. It does this by considering all possible 13-byte long sequences as a potential key, and counting how many times each potential key appears. Then it throws away all keys that don’t appear often (less than 100 times) and all keys that do not appear random (for example, keys with more than 3 0x00 bytes).

The most prevalent of these remaining keys, is considered as the most likely XOR key.

The new options that have been added to version 0.0.3, allow to guide this key finding algorithm.

Option –keysize is the XOR key size: the default value is 13.

Option –numberofkeystotry specifies how many keys that are considered to be potential XOR keys. The default value is 10: this means that the 10 most prevalent keys are selected and displayed.

Option –keystotry specifies which keys to try, out of the 10 keys selected. By default, only the first key (most prevalent key) is tried: value 0. But you can provide several keys, as a comma separated list of indices.

A potential XOR-key is selected as a decoding key, if the decoded memory section contains string b’sha256\x00′.

Finally, option -r can be used to let the tool analyze a raw set of data (e.g., the provided file is not parsed as a minidump file, but just taken as raw data).

cs-analyze-processdump_V0_0_3.zip (https)
MD5: 46C232F594CF67272A915985AFDFE839
SHA256: 84EBC79B9CC5764E7D8C85DCBADEE49F09ABF6F19962A0D9C505703F82675B23

Wednesday 22 December 2021

Update: cs-extract-key.py Version 0.0.4

Filed under: My Software,Update — Didier Stevens @ 0:00

I added option –donotfullsearch in this new version of my tool to extract encryption keys from process memory dumps of beacons.

When this option is used, cs-extract-key.py will not fall back to a full search when string sha256\x00 is not found.

cs-extract-key_V0_0_4.zip (https)
MD5: 451D73C0963C91E11AE043AD82A96FCD
SHA256: 5D21C796CA2F7D115D291E2C4DAE713EF87601B663FCF7EFF06D91B447A52528

Tuesday 21 December 2021

Update: 1768.py Version 0.0.11

Filed under: My Software,Update — Didier Stevens @ 0:00

1768.py, my tool to analyze Cobalt Strike beacons, has an update: updated statistics and support for your own, private 1768.json file: 1768b.json. When 1768b.json exists, it is used by 1768.py in stead of 1768.json.

1768_v0_0_11.zip (https)
MD5: 5029A9831D32F57D174BE9DDC8CA31B3
SHA256: F6939ACB105FE848F084A7E916AE9E2CC0BC173B92D7BBBA95637CC355657E09

Monday 20 December 2021

Update: cs-parse-traffic.py Version 0.0.4

Filed under: My Software,Update — Didier Stevens @ 0:00

This update for cs-parse-traffic.py, my tool to parse/decrypt Cobalt Strike network traffic, includes bug fixes and new definitions.

cs-parse-traffic_V0_0_4.zip (https)
MD5: 890C5290B7C1E0F5803F0289FA876DDB
SHA256: 43FD18DDCDB5732C9EB1F2B377E3B1DF6A2D36F62442CE2068C32EBC3FC07813

Sunday 19 December 2021

Update: cs-decrypt-metadata.py Version 0.0.4

Filed under: My Software,Update — Didier Stevens @ 9:43

This is a bugfix version.

cs-decrypt-metadata_V0_0_4.zip (https)
MD5: 50C8AEFA1A1A507012BE72C71C449818
SHA256: CAFCCE9A8897C257AE39259D3F444E0F40473BF0D9590DC1A035316EBDDBBC84

Update: base64dump.py Version 0.0.19

Filed under: My Software,Update — Didier Stevens @ 9:40

This is a bugfix version.

base64dump_V0_0_19.zip (https)
MD5: 0D250DCB3FCE5D41A6FCB3AAD3937019
SHA256: FECA04873B87A15F0713938717611E86ED360F51AF28FCD03CEEFC4688BD7D67

Saturday 11 December 2021

MiTM Cobalt Strike Network Traffic

Filed under: Encryption,Hacking,Malware,My Software — Didier Stevens @ 10:14

I made a small PoC. cs-mitm. py is a mitmproxy script that intercepts Cobalt Strike traffic, decrypts it and injects its own commands. In this video, a malicious beacon is terminated by sending it an exit command. I selected a malicious beacon that uses one of the leaked private keys.

The script does not support data transforms, but that can be easily added, for example with code found in cs-parse-traffic.py.

Next Page »

Blog at WordPress.com.