Ransomware Decryption: So long, and thanks for all the CrypMIC

In this post, we will discuss how one can recover from a CrypMIC ransomware infection with a small amount of preparation work and some lazy programming. Please note that this will not help you if you have been infected and you didn’t manage to capture the post-infection network traffic from the malware. Brute-forcing the AES-256 key for CrypMIC is well beyond the scope of this discussion.

Allow me to introduce the CryptXXX copycat.

So, there I was, with a bad case of post-vacation-itis, examining the network traffic emitted by a bunch of CrypMIC samples.

For those that have not done this, a little backstory is in order.

The CrypMIC ransomware is modified code based on the earlier CryptXXX ransomware. In particular, a few of the weaknesses of CryptXXX were:

1. It used RC4 for encryption, so that malware researchers were able to release decryption tools. This allowed the victims to recover from the attack without having to pay the ransom.
2. It used a custom network protocol on 443/tcp, attempting to look like HTTPS to the uninitiated, but actually being nothing like you would expect.

In this latter way, CrypMIC is still weak. One could make the argument that CryptXXX and CrypMIC are honorable (in the ‘among-thieves’ sense) malware, because they leave lots of breadcrumbs for the technically proficient to recover from, and only truly victimize the helpless.

Let’s examine these breadcrumbs.

There are four packets that the malware sends off to its C&C server, and it gets four responses. The first one is some kind of mystery packet. The second and third result in responses containing the ransom note text. The fourth packet is also a mystery; and does not get sent until some time later, after the encryption has happened.

Let’s call them “Hello”, “Text Ransom”, “HTML Ransom”, and “Confirmation”, in that order. So, I was gazing at a bunch of these “Hello” packets and responses, and I noticed something curious. The response packet was the “Hello command”, and 48 bytes of seemingly random crap.

Groggily, the number 48 wandered through my mind, in search of something to connect with.

I read a few blog posts about CrypMIC, such as “Side-by-side comparisons of the CrypMIC and CryptXXX Ransomware Infections”. They all mentioned that one of the major changes between CryptXXX and CrypMIC was the switch from RSA keypairs to AES-256 for the encryption.

The phrase “AES-256” wandered through my mind in search of something to connect with.

Fifteen seconds later, I realized that 32 plus 16 is 48; 32 bytes being the length of the AES-256 key and 16 bytes being the length of the initialization vector. I thought, “This can’t be this easy, can it?”

So, I sat down in the mud and wrote up a couple of quick snort signatures to capture the traffic I needed:

Now, I had 48 bytes to work with. Below is what the packet payload looks like, in hex:

The “0x32000000” is the “Hello” command, or more likely the “Key Request” command. Now, what about the rest of that stuff? We’ll take a guess that it’s (KEY,IV) and run with it. (I got lucky here, it could have been the other way, or obfuscated somehow. It wasn’t. Maybe in the next release.)

We grabbed a couple files off the now-encrypted machine, and computed the MD5 and SHA1 hashes for the originals, so I’d know what success looked like.

Time to do a little python.

Success.

In Conclusion

Hopefully you’ll find this tool to be a helpful in an emergency — in case you discover that your backups have failed and your patch policy didn’t prevent the infection in the first place, but you did happen to get lucky and manage to capture the key exchange. Also, pulling some junk out of a network capture and decrypting an end-user’s system makes you look like a wizard.