The previous post, and the one before that, told the story about how one of my clients was hit with the Locky ransomware, the decision to pay the ransom, and the experience of buying Bitcoin in order to do so. This post picks up after getting notification that the Bitcoins were available in the online wallet we’d set up.

Paying the Ransom

After waiting six days to receive the Bitcoins, we finally received an email that they were credited to our Bitcoin wallet.

 

The ransom demand page on the dark web included an address where we were supposed to send the Bitcoins. We copied the Bitcoin address given to us, and submitted a payment request from our wallet.

About 15 seconds after confirming the send request, and refreshing the ransom page, the status changed to show that the payment was pending confirmation.

It took about 40 minutes for the Bitcoin transaction to be confirmed. The ransom page reloaded on its own, and at the top was a very simple download link.

The link led directly to a downloadable file, only about 117KB in size, called LockyDecoder_7379F3C161FF0F48.exe.

Decrypting Our Files

Presumably, the decryption program is meant to be run on the originally-infected PC so that it can find all the same files that the encryption code had discovered. There was no way we were going to let this program, from known cyber criminals, run anywhere near our network. In any case, the PC that had originally been infected had long since been wiped clean and given a fresh OS install. However, we still needed to fix the files on the shared drive.

For safety, our decision was to run the decryption program inside a VM, which was hosted on a machine that had no network connections at all. The VM was not given access to the host drives or file system. We had a Windows 7 laptop handy, so we spun up a fresh “Windows XP Mode” virtual machine. When we finished, we destroyed the XP VM and all its files.

We had to be a little careful. We couldn’t just plop all of the .locky files into a folder, decrypt them, then move them back. Because the names had been changed to big random numbers, we could end up with multiple files named “expense report.xls” or similar. Such a collision would probably result in any files that got decrypted later in the process simply overwriting and trashing ones that had already been decrypted.

The other problem with that approach would be figuring out where the decrypted files needed to be put back on the shared drive. No one was enthusiastic about having to open 1,000+ files and trying to guess what folder they came from.

Our approach was to copy the full directory tree from the infected part of the shared drive including the encrypted .locky files but excluding everything else. We ended up with a directory on a thumb drive that just had nested folders and .locky files. Then we copied the whole tree into our VM along with the decryption program.

Running the decryption program by double-clicking the icon brought up a console window that started scrolling with text. There was no other UI and no opportunity to tell the program what files to decrypt. It did manage to find, and fix, all of the .locky files. When it was done, the window closed and each file with its original name was in its proper folder.

Finally, we ran several malware scans from different vendors on the files and hand inspected  several. It’s conceivable that something nasty got left behind and eluded the scanners, but it didn’t look that way. After convincing ourselves that the files were OK, a simple script copied each file back to its corresponding location on the shared drive.

One Final Taunt

After we paid the ransom, in addition to the download link, the criminals were twisted enough to include one last message. The message scolded us for not having backups along with the helpful definition of “backup” from Wikipedia.