What You Can (and Can’t) Do Against Ransomware

It happens very quickly: one moment your files are there, and the next they’re not. All you did was download some “useful” software, or run an email attachment that you got from a colleague. The next thing you know, all your files have had their extensions changed to something nonsensical, and their contents have been replaced with what appears to be random noise. Naturally, you had a backup, but the exact same thing happened to that, too. A warning soon arrives, either in a pop-up message or plastered all over your desktop: If you ever want to see your files again, you will have to pay a hefty ransom.

This type of malware is called ransomware, and it’s a type of cryptoviral extortion. Getting put in this situation is generally not a pleasant experience.

Figure 1: Cryptolocker ransom notice

If you had known in advance that this was going to happen, there were several things you could have done. If you are running a Windows machine, you could have enabled the Windows Shadow Copy service a few months ago. Your system would have created backups of good versions of your files, and possibly the ransomware wouldn’t have bothered to seek out and destroy these backups (though you shouldn’t be too optimistic; most ransomware authors have wised up to that trick by now). You could have also signed up for an online file storage service that keeps pulling updates from your file system (as long as the storage is not mounted and accessible from the same file system, as that would defeat the purpose). You could have been more judicious with the files you open or the websites you visit…

There are many different preventative measures that could have been taken, and we will touch on some of them here. But when dealing with ransomware, you should think about the worst-case scenario – you have no failsafe, no working backup, and you’re stuck with a hard drive full of encrypted files.

So, what can you do? There is one thing that should be said up front: in theory, your worst-case scenario is that your files are lost. In theory, there is no getting around well-executed, strong encryption. In theory, getting your files back is equivalent to breaking some 2048-bit key encryption scheme, where the most efficient approach is only marginally better than trying every possible key until the heat death of the universe.

It so happens, though, that there is a lot hiding behind the words, ‘in theory.’

Attack Vector 1: Seize the Key, Break the System

Ransomware extortion relies on one simple fact: The bad guys have the key needed to decrypt your files, and you don’t. An encryption scheme is only as secure as the key – if you can obtain the key, it’s effectively game over for the extortionist.

You might think that this would inspire malware authors to be extra careful to secure the key, but there is a surprisingly large number of ways to pull off an encryption stunt and leave your key open for recovery. At the very least, you have the “malware author does not know how to Crypto” scenario, as outlined in Check Point’s 2014 publication, Hacking the Hacker: How (and Why) We Defeated DirCrypt. That malware strain reused the same stream cipher key to encrypt every file (this is a bad idea – just ask the Soviet Union); and, on top of that, literally left the encryption key lying next to every single encrypted file.

Figure 2: DirCrypt appends its encryption key to the victim files

But suppose that the malware author does have elementary knowledge of how to Crypto. Suppose that when executed, the malware immediately generates a random AES-256 key, uses it to encrypt your files, sends it to the C&C server and then deletes it. First of all, traces of the key might be left in the host system. Second, even if the malware makes sure to erase all such traces, literally every machine in the route between your machine and the C&C server has seen the key in transit. That’s not very secure; one of them could easily have a communication log from which you could recover the key. Even if the communication is itself encrypted, that encryption could also be subject to a break, especially if a dedicated effort is made to reverse-engineer the malware executable.

These pitfalls are the main reason that for a long time, the canonical way to hold a victim’s files hostage has been to use what’s called asymmetric encryption. In this model, a secret key is generated on the malware’s C&C server, and a corresponding public key is then generated and sent to your infected system. The public key is used to encrypt your files, and only the secret key can then decrypt them (yes – it is not possible to use the public key to decrypt).

Even when the malware correctly applies this model, there are sometimes extraordinary circumstances where the secret key can be recovered. In August 2014, the GameOverZeus botnet, which distributed the infamous CryptoLocker malware, was brought down by collaboration between several law enforcement agencies, universities and security firms. They subsequently gained control of the actual C&C servers used for CryptoLocker – including the repository of secret keys. As a result, anyone infected with CryptoLocker could simply go to a website and get their files decrypted for free.

Attack Vector 2: No Communication, No Extortion

This attack vector also aims at the vulnerable key exchange phase. Unlike the first vector, it is a preventative measure, and involves no cryptanalysis, not even of the banal “find the key, now use the key” type. Instead, it aims to prevent the ransomware from communicating with its C&C server.

When fighting ransomware, automatic traffic analysis with a quick finger on the “shut down” trigger goes a long way. If your firewall can detect the ransomware’s communication with its C&C server and prevent the malware from sending a symmetric key or receiving a public key, the malware will likely be stuck waiting for the connection to go through.

Without a successful key transfer, the extortionists don’t have a leg to stand on. In the case of symmetric encryption, if the malware can’t send the key to the extortionists, they don’t have the key with which to decrypt your files—which is the whole point of their operation. In the case of asymmetric (public-key) encryption, if the C&C server can’t pass the public key to the ransomware, encryption will not take place because the ransomware has no key to with which to perform the encryption.

The blunt effectiveness of this method has not eluded ransomware authors, and they have been making serious efforts to circumvent it. Encrypting all communication is one method (though, as is always the case with encryption, the details are subtle and the pitfalls are many). Another way, recently seen in the ransomware landscape, is to perform all encryption offline, and only communicate with the server once the encryption is done.

An Aside: The Diffie-Hellman Ransomware Gambit

The “encrypt first, ask questions later” approach is not limited to simply encrypting all the files and then trying to send the key to the C&C server. One emerging trend is to use the Diffie-Hellman Key Exchange protocol to obtain a session key for encryption. While the specific details vary among different ransomware implementations, Diffie-Hellman Key Exchange makes it possible for a ransomware infection to reach a state where the extortion is possible without contacting its C&C server.

The protocol relies on public-key encryption that allows two parties which have no secret in common to agree on a common secret. If both Alice and Bob have each other’s public keys, they can agree on a common session key. Computing the key requires access to either Alice’s private key or Bob’s private key; computing the session key with access to neither, based on Alice’s and Bob’s public keys alone, is considered a hard problem.

Suppose that the C&C server has its own public and private keys. Suppose further that once the malware manages to infect a victim and executes, for each file it:

1. Generates private and public session keys for that file.
2. Performs DHKE using the C&C server’s public key and the private key that it just generated.
3. Encrypts the file with the resulting session key.
4. Deletes the private session key and appends the public session key to the encrypted file.

To decrypt the file, you need to recover the session key. Doing this requires access to either the private session key generated by the malware, or to the C&C server’s private key. But, barring a forensic stroke of good fortune, the private session key is now lost forever. The only hope to recover the file lies with the C&C server’s private key – which the extortionist has, but you don’t. And it never had to leave the safety of the C&C server.

Figure 3: Schematic overview of Diffie-Hellman Key Exchange.

Something very similar to the attack outlined above has been implemented in a relatively new family of Ransomware called CTB-locker. The only difference is that CTB-locker attempts to send the malware’s public key to the C&C server right after the encryption is through, instead of letting the key sit in the infected machine. More information about this new wave of sophisticated ransomware is available here, here and here.

Attack Vector 3: Detect and Defeat Weak Encryption

If it is impossible, or too late, to recover the key or to disrupt the ransomware’s communication, the only recourse left is to attempt to break the encryption.

As mentioned earlier, this is not feasible for strong encryption. Thankfully, though, not all malware puts as much effort into the encryption strength. A successful ransomware campaign can affect tens of thousands of machines (GameOver Zeus had hundreds of thousands of machines under its sway). How many of those machines’ owners will see the menacing looming 72 hour deadline to pay the ransom and think, “I’m going to try breaking the encryption”? Malware authors may well decide that it’s not worth going the extra mile to make sure the encryption is really robust.

To successfully decrypt a file, you first need to understand the encryption used. There are generally two ways to do this. One is to obtain the encryption algorithm directly by reverse-engineering the malware executable. But this requires time, effort, a particular skill-set, and access to the original malware executable – any of which may not be available.

Another way is to directly analyze the encrypted file; the statistical properties of the file can provide useful clues as to the kind of encryption used. Some interesting indicators to look at are:

1. The File’s Byte Entropy. Byte entropy is, roughly speaking, a measure of how “random” the byte distribution in the file appears. The possible values range between 0 (the entire file is just one repeated byte) and 8 (all possible bytes appear with equal probability). Strong encryption will produce files with byte entropy close to 8; significantly lower byte entropy indicates weaker encryption that may be easier to break. For example, monoalphabetic substitution ciphers (such as simple XOR encryption) do not affect byte entropy.
2. The File Length. One of the questions we should be asking is whether we are dealing with a stream cipher (which encrypts one byte at a time) or a block cipher (which encrypts bytes in ‘blocks’ of a certain size.) A good indicator to look at is the largest power of 2 that divides your encrypted file sizes. This indicator becomes more and more accurate the more encrypted files you look at.
3. The maximum number of times a block repeats. In cases where you suspect a file was encrypted by a block cipher, it might be useful to check whether a ciphertext block repeats more than once. If it does, you are likely looking at a file that has been encrypted in ECB (Electronic Code Book) mode – that is, each block was encrypted separately.

Sample file metrics:

From these statistics, it is apparent that the third file was encrypted by a block cipher in ECB mode. The fourth, however, was evidently encrypted by something quite simpler. Its file entropy is nearly the same as that of a normal text file. It stands to reason that the fourth file was encrypted using monoalphabetic substitution (this kind of encryption was used, for example, by the PClock ransomware.)

If you are dealing with weak encryption, the way to proceed depends on the kind of encryption used. Simple XOR encryption can be broken using exhaustive search; slightly more sophisticated, “rotating cipher” variants in the vein of the Vigenère cipher require a more clever approach, but are often breakable in a few minutes on your average laptop.

Figure 4. The “Tabula Recta” – based on modulo-26 addition, this table gives the ciphertext byte as a function of the corresponding plaintext byte and key byte for certain kinds of simple encryption. Simple encryption encountered in the wild usually uses XOR encryption rather than base-26 addition, but the principle is very similar

On the other hand, if your files were encrypted with strong encryption, you are in a bind. We have already assumed that you do not have a working backup, could not recover the encryption key, could not interrupt the ransomware’s communication and encryption process, and just now found out that the extortionist made the effort to use relatively strong encryption. There’s nothing left to do, really – no way left to recover the files.

Except, well…

“Attack Vector” 4: Pay the Ransom

First we should make it abundantly clear that paying the ransom is a crapshoot. The extortionist could simply take your ransom money and never bother releasing your files. Also, by paying, you would be financing criminal activity. For both those reasons, our recommendation is not to pay the ransom.

Still, we should be fair and say that there is another side to that argument. First, the extortionists have nothing to gain from scamming you out of your files, and in the long term, they have much to lose. If it becomes well-known that paying up won’t get you your files, the victims will have no incentive to pay, which, for the extortionists, defeats the purpose.

Second, you should consider whether the lost information is worth more than the ransom to you. If you have become convinced that there is no other way to get your information back, and it is worth at least that much to you, you will inevitably consider the option of paying up. Again, we recommend against it, but ultimately it is your decision to make.

Summary

Conventional wisdom says that being hit with ransomware is game over – once you get hit, you have lost control of the situation. There is a grain of truth to this statement. Still, there are a number of steps you could take – both preventative and after-the-fact – that would help you deal with the situation, if and when you come across it.

Preventative measures:

• Back up your important files periodically in a storage medium that is usually air-gapped.
• If you are using a Windows machine, enable automatic backups (system restore). Some (many) malware strains will specifically go after the shadow copies of your files in the backup, but it is still worth a shot.
• Use up-to-date endpoint security. Protecting yourself from the latest and most sophisticated threats is enough of a challenge; you don’t want to expose yourself to being hit with ransomware that had been studied and fingerprinted three years ago.
• If feasible, use a firewall with up-to-date malware definitions and keep traffic logs as far back as possible. For specific information about the solutions Check Point offers in this area, see the post The Current Wave of Ransomware and particularly Check Point’s ransomware prevention solution brief.
• All general best practices for avoiding malware infections apply. Before you double-click a file, think about where it came from – how much you trust the people who compiled it and the people who might have reasonably had access to it. Be especially suspicious of attachments that come with unsolicited email.

After-the-fact measures:

• If possible, obtain the sample that infected your machine and check against open-source intelligence pools such as VirusTotal whether it is a known threat. Learn what you can about the malware’s method of operation, scheme of encryption and financial model.
• Attempt to retrieve the malware’s communication from any network logs that might have survived. The encryption key could be there somewhere.
• Analyze the encrypted files to discern whether weak or strong encryption was used. If weak encryption was used, it might be possible to break it and recover the files.
• Unless you are sure you know what you’re doing, you probably want to take your infected machine to an expert to do all of the above for you. And if all else has failed, consider whether it may be worth it to pay the ransom, always taking into account that there are no guarantees.