There is also a video of this analysis.

Renato gives an extensive analysis of MSBuild and Cobalt Strike malware in diary entry "Attackers are abusing MSBuild to evade defenses and implant Cobalt Strike beacons".

I wanted to know if I could analyse these samples with my tools: this is the sample I looked at.
First I noticed a sequence of bytes (hexadecimal) that my base64dump.py tool should recognize as zxc encoding.

However, base64dump.py failed to recognize the complete sequence. First I assumed that the sequence contained some unexpected characters, but it turned out that was not the issue. With zxc encoding, base64dump.py looks for sequences of strings like 0x?? separated by commas (? represents an hexadecimal digit): my tool expects that each byte is encoded with 2 hexadecimal digits. And that is not the case in this sample:

Byte values smaller than 16 have no leading zero.

So I updated my base64dump.py tool to include another encoding: like zxc, but without leading zero. I called this encoding zxcn (n standing for no-leading-zeroes).

I use option "-e all" to try all encodings on the sample:

And with this new version, a very long sequence is detected: zxcn encoding, 1290778 characters long.

I run base64dump.py again, now only searching for zxcn encodings:

2 sequences are detected. Taking a closer look at the code in the sample, I notice that that second sequence is an XOR key that is used to decode the content of the first sequence:

That second sequence decodes to string uKIMvp, e.g., the XOR key I need to use to decode the payload.

I use my tool translate.py to do the XOR decoding like this:

This looks like a 64-bit Cobalt Strike PE file (notice magic header MZAR). Let's check with my tool pecheck.py:

It is indeed a PE file, and more precisely a 64-bit Cobalt Strike DLL. Thus my tool 1768.py is suited to extract the configuration:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com