Third time (un)lucky - improved Petya is out

So far we dedicated several articles to the interesting, low-level ransomware called Petya, hijacking the boot sector. You can read about it here:

/blog/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/ – Green Petya (version 2)
/blog/threat-analysis/2016/04/petya-ransomware/ – Red Petya (version 1)

Each of those versions was using Salsa20 algorithm to encrypt Master File Table and make disk inaccessible. However, due to the implementation bugs the intended algorithm was weakened – giving a chance to recover data.

Unfortunately, as always in such cases, it is just a matter of time when cybercriminals get their cryptography fixed. Petya’s authors got it right at the third attempt. The currently launched wave of this ransomware finally seems to have the proper Salsa20.

sample: c8623aaa00f82b941122edef3b1852e3

Behavioral analysis

Behavior of Petya didn’t changed – we can see exactly the same UI like in the previous green edition:

green_petya — Inside
Let’s take a look at differences in the code. Using BinDiff we can spot, that not many functions have changed. However, those that were giving weak points to the previous edition are modified.

Salsa20

First of all, let’s take a look the function s20_littleendian that was causing the major bug in the last release. Due to it’s invalid implementation, only 8 out of 16 characters of the key were meaningful and brutforcing the key was easier (working solution has been implemented by

On the left – you can see the implementation of the buggy function (from the previous edition). On the right – current, fixed implementation:

Explanation The old implementation was truncated – it didn’t used 32 bit values as it should – only added a sign bit expansion to the 16 bit value:

static int16_t s20_littleendian(uint8_t *b) {   return b[0> +          (b[1] << 8); }

Now, authors got the proper implementation, using 32 bits. So, the last bug in Salsa20 got finally fixed, making implementation complete.

Key

In the first (red) version of Petya authors used 32 byte long Salsa key - that was, however, generated from the 16 byte long key, using a custom function to pre-process it and extend.

In the second - green edition, they gave up this idea and applied the original 16 byte long key, without any modification.

This time, they changed mind and went back to the first solution of using 32 byte long key, yet with some improvements. Again we can see expand32 in the code (instead of expand16 known from the previous edition):

When the victim insert the key for the verification, before using it as a Salsa20 key, it is preprocessed by a new algorithm (more complex than in case of Red Petya):

process_key — Conclusion
New edition shows that the project is reaching maturity - however, as we can read on the associated onion page - it is still a beta version and we can expect that it will keep evolving. Below - fragment of Petya's RaaS website:

We are not yet sure about the distribution method, but probability is high, that also this time it is spam with a link leading to cloud storage. We strongly advise to be extra vigilant for the job applications coming this days - it proven to be a common cover for Petya/Mischa dropper. More information about it you can find in our previous articles about Petya.