What should you do if you catch encryption ransomware mid-operation?

Hibernate the computer

If the ransomware is encrypting the files, the key it is using for encryption is somewhere in memory. It would be preferable to get a memory dump, but you are unlikely to have the appropriate hardware for that readily available. Dumping just the right process should also work, but finding out which one may not be trivial (eg. the malicious code may be running inside explorer.exe), and we need to dump it now.

Hibernating the computer is a cheap way to get a memory image¹ Then it could be mounted read-only on a clean computer for

a) Assessment of the damage inflicted by the ransomware

b) Recovery of unencrypted file

c) Forensic extraction of the in-memory key from the malicious process, other advanced recovery of the files, etc.

Note that by read-only I mean that no write is performed at all, for maximum recovery chances. Connecting normally to another Windows system won't provide that.

For (c) you would probably need professional support. It may be provided free of charge by your antivirus vendor.

Even if you don't manage to recover all your files or you are told it is impossible or too expensive, keep the disk with the encrypted files. What it's impossible today may be cheaper or even trivial in a few months.

I recommend that you simply perform the new install on a different disk (you were going to reinstall anyway, the computer was infected, remember?), and keep the infected one -properly labelled- in a drawer.

--

As for the second question, where you really want to pay the ransom I'm quite sure the ransomware author could give you back your files even if not all of them were encrypted. But if really needed, you could boot from the hibernated disk after cloning it, and let it finish encrypting your (now backed-up) files…

¹ NB: if you didn't have an hibernation file, this may overwrite plaintext versions of now-encrypted files that could have been recovered (not relevant for most recent ransomware, though).

² Assuming they are not infected…


What I would do:

  1. Suspend the process. Don't kill it, just pause it.
  2. Look in the process tree if there are any parents that might need suspending as well.
  3. Pull the network cable and/or turn off WiFi (and if you're paranoid, Bluetooth too).
  4. Check open files by those processes to see which one it is currently encrypting. If it's a particularly important one, you might want to copy the file in its current state (while the process is suspended) and then let it move on to the next file, so it won't get corrupted. If the next file also turns out to be important, well, either figure out the pattern and copy a file one step ahead or just start copying all your files already.
  5. Google how to make a memory dump of a process on that particular OS, then make that memory dump of the relevant processes. Heck, I might dump all virtual memory from the machine.
  6. Close other programs.
  7. Sync the disk(s) so there is no write cache anymore.
  8. Pull the power. If a laptop: remove battery, then remove power (if plugged in).

You are now in a pretty good position: power is off so noting more can happen, and you have whatever encryption key it was using plus the original program. The trouble is to find that encryption key and the encryption method, but it has to be somewhere in its process memory: just a matter of time. Call your hacker buddies to reverse engineer the program, or perhaps even an antivirus company: they probably have lots of customers with the same ransomware and would be very curious to obtain a memory dump to extract the key.

Hooking up the hard drive to another computer will recover any files that were not encrypted yet, without much risk. Just don't execute any Word macros or open .exe files from the drive or something.

Summary

Pause the ransomware process so we can make a copy of it and its memory to find the encryption key later. Then turn the system off and follow common sense from there. Beware of important corrupted files (halfway encrypted files), so check the one it was currently working on after pausing it.


In response to comments

This comment has a few upvotes now:

The "encryption key" would not help in many cases, on startup the ransomware connects to the command and control server and requests a new encryption pair(public and private) to be created. The server creates the pair, stores the private, and sends the public to the infected machine. Then the infected machine uses the public key to encrypt the files, and the only way to reverse it is to use the private key, that is never transferred to the victims machine until a payment is completed. – Anton Banchev

This is a concern I thought of while writing the post, but have not addressed yet.

Nobody ever encrypts data with asymmetric encryption (also known as public key encryption). It's just too slow, so asymmetric crypto is only used in hybrid encryption schemes. Even benchmarks like the one built into openssl report megabytes per second for AES and operations per second for RSA. Not comparable at all. The only hit I've been able to find is this Stack Overflow answer with a source that did not even disclose their methods: asymmetric encryption is 1000 times slower than symmetric encryption.

Thus, the encryption used for each file is almost certainly symmetric encryption (like AES), which means we can also decrypt it with that same key as it is being encrypted with.

Update: it seems at least one of the many ransomware variants uses public key encryption only. Apparently it is just fast enough to be usable, or they would obviously not be using it. I guess you better hope you don't have this variant? End of update.

I don't know of any ransomware that does this, but the only way this could still be an issue is when each file has a unique encryption key. In that case only the current file could be recovered from memory. This would cause a key management issue for them though: each of those keys would either have to be transmitted, or stored in a database which is encrypted with a (symmetric) master key. In the latter case you could probably recover the master key from memory as well, in the former case you got a problem. But this is all just speculation anyway, I don't know any ransomware that does this.


Ransom-ware (or any encryption software for that matter) will not encrypt the file in-place, because the encrypted filesize will not match the unencrypted filesize bit-for-bit (unless it's just an xor shuffle, in which case it's not really encryption). More importantly, a spontaneous abortion of the encryption process (due to a shutdown, running out of battery, etc) would create a corrupt file which cannot be ransomed. Instead, these programs always create a new encrypted file from the old, then delete the old. In fact, most ransom-ware programs have checks to restart half-encrypted large files due to a shutdown/restart.

So if you find out your mid-encryption, you turn your computer off - as soon as possible - and mount the hard drive on an unaffected machine for backup.

Regarding whether or not I pay the ransom - I have no idea. Depends on the size of the ransom and the nature of what's on my hard drive at the time. Since I make roughly $2.50 an hour, and my hard drive mainly contains publicly available scientific data, the answer is most likely no.

EDIT:

Hibernation, as recommended by the other poster, is hypothetically superior to turning the computer off in many ways. However, practically, hibernation may not work. Any process can tell the system that it is busy and cannot be stopped right now -- even a YouTube video of a cat playing a piano can do this. This is true for OSX, Windows, and Linux (depending on how you hibernate for Linux). The only solution in these instances where the process refuses to suspend is to kill the process - which means no memory dump. So personally, i'd rather stop that encryption as soon as possible by yanking out the power chord, because if there's one thing I can guarantee, its that that the ransomware will be putting its key back into memory the next time the system boots, because I didn't let it finish the job.