Wyatt Roersma Blog

Update:This will not help you with versions of CryptoWall 2.0 and up they have since patched this issue. 

A couple of weeks ago I got a call from a client that one of their employees had clicked on an attachment named “electronic_fund_transfer.zip” in a spam email. Naturally, the employee opened the PDF from within the zip file and then clicked “Run” to launch the executable inside.

In a typical organization, the main concern in such a situation would be what data was exfiltrated from the environment, not the data that was lost due to not having proper backups. You could just wipe the system and restore any lost data from backup, and spend your time figuring out what the malware accomplished while on the system. Well, this client didn’t have working backups in place and the user had also mounted file server shares to his laptop. So, not only did his data get encrypted, some of the data on the file server did as well, with no backups for months of either system.

When the client first contacted me they called it “CryptoDefense” which we can indeed decrypt without issue because there is plenty of data out there on how to do that. Naturally, once we arrived on site, we quickly found out that this was the much more advanced CryptoWall malware that doesn’t store the private key needed to decrypt the files on the local system.

At that point I was between a rock and a hard place because we had initially told them it was possible to recover the encrypted data. However, the majority of resources on the Internet indicate that it’s not possible to recover data at all when CryptoWall is installed as opposed to CryptoDefense. Most file recovery methods suggest using VSS copies to recover the data or backups, otherwise you’re simply out of luck. In these cases, I do not consider paying the data terrorists as an option.

So, as part of our basic Triage process, we obtained memory and disk images. These helped a lot in understanding how this malware works and achieving the ultimate goal of recovering the data.

To work with the malware for this blog post I created a virtual machine, fresh to launch this malware on, to run a few scans and tests.

My first goal was to determine how this malware was encrypting the data and in which method it was deleting the original files. I searched the strings file created from the volatility strings plugin. I used IDA pro on the “vofse.exe” file that does the encryption part (it’s the second file that is downloaded after sicac.exe). The ransomware was simply using the DeleteFile Function to remove the files after making a copying from the original file.

This screenshot is where the ransomware finds the file and creates a copy of it.

Here is a screenshot with the DeleteFile function highlighted.

So, I made a disk image before installing the malware and another after letting the malware run to “encrypt” the files.

First, to get a list of the files it “encrypted” I printed out the list it makes in the registry. To find the registry key that the malware created, look in “HKCU\Software\<unique ID>\ CRYPLIST\” as it contains a list of the encrypted files.

root@BT:~/volatility-master# python vol.py -f win7.vmem –profile=Win7SP1x64 printkey -K “Software\1C1AA48085BD197637A78463CBBE8BC2\CRYPTLIST”

Legend: (S) = Stable   (V) = Volatile

—————————-

Registry: \??\C:\Users\malware\ntuser.dat

Key name: CRYPTLIST (S)

Last updated: 2014-06-09 12:45:57 UTC+0000

Subkeys:

Snip…

Values:

REG_DWORD     C:\Users\malware\Documents\00698_snowmountains_1920x1200.jpg : (S) 2054688515

2054688515

Snip…

REG_DWORD     C:\Users\malware\Documents\400 – Linux Software RAID Rebuild.doc : (S) 2054688515

REG_DWORD     C:\Users\malware\Documents\Cisco_2014_ASR.pdf : (S) 2054688515

REG_DWORD     C:\Users\malware\Documents\GrrCON-Challenge.docx : (S) 2054688515

REG_DWORD     C:\Users\malware\Documents\Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery.docx : (S) 2054688515

REG_DWORD     C:\Users\malware\Documents\Sophos_ZeroAccess_Botnet.pdf : (S) 2054688515

REG_DWORD     C:\Users\malware\Documents\YARA User’s Manual 1.6.pdf : (S) 2054688515

REG_DWORD     C:\Users\malware\Downloads\00698_snowmountains_1920x1200.jpg : (S) 2054688515

Snip…

 

I then opened “GrrCON-Challenge.docx” (one of the encrypted documents) in a hex editor, copied the raw hex values, and searched through both of my disk images, before the malware, and after the malware. While the file itself was removed according to the malware it was still in the same spot on disk at offset 004c000 in both disk images.

 

Here is the file in the “malwarevm-before.001”:

Here is the “GrrCON-Challenge.docx” document at the same offset 004c000 on the “aftermalwarevm-cryptowall.001”

I also opened the encrypted version of “GrrCON-Challenge.docx” and then searched the “aftermalwarevm-cryptowall.001” to find where it was located on disk to confirm they create a new file compared to the old disk image. I will note one very interesting fact: while I have two versions of the “GrrCON-Challenge.docx” file, the malware only created one encrypted version.

Now that I have confirmed that the malware isn’t fully deleting the files, I want to test it out on some more files to see how much data I can recover.

I ran one of my favorite file recovery tools called R-Studio (Yes, I like it because it’s fast and saves me some time from the more manual solutions available). R-Studio is a very simple program. Basically, all you have to do is mount a drive and scan it, and then choose which file types you want to look for. I just used the default configuration on the “aftermalwarevm-cryptowall.001”. I selected the Microsoft Word 2007 XML Document (.docx) and noticed I had two sets of files. The ones with file names are the encrypted version by CryptoWall and the ones without names are the files that were deleted recoverable from slack space.

Based on the file size and hex values I know “70.docx” is my “GrrCON-Challenge.docx” file, so I clicked on the view process before recovering the file to ensure it’s the proper file from the hex view and not the encrypted file. I was indeed correct because the picture above lists the file header as “PK” which is the proper file header in the docx file.

Listed below is a screenshot of the encrypted file and its header so we know if we are looking at an encrypted file or not.

In my test example all encrypted files start with the header “CE FE” in hex, which will be different on each system that is hit will CryptoWall.

So I recovered all the files and ran a sha256 hash verification to ensure all my recover files matched the original files.

Recovered File Hash Check

Original File Hash Check

I only tested with a few files in the following formats, docx, doc, pdf, and jpg. As a disclaimer with all file recovery some files may not be recoverable if the slack space was overwritten. In each separate case, file recovery will depend on how many files were encrypted, and how much free space the drive had before it had to start overwriting old slack space for new files.

If anyone wants to look at the attachment that launched the attack, here it is, along with the malwr.com automated analysis, which is somewhat helpful. *Note: you have to sign up to download the file, and use at your own risk. I am not responsible for any damages you cause to yourself.

https://malwr.com/analysis/ZmU1MzE0MmU5MmExNDc5YjkxMDQ2ZmI1ZWEyYjM4Nzk/

In my client’s case I was able to recover approximately %95 of the files, however based on their actual need we only searched for the critical documents and nothing that was lost from the user’s personal files. Just because ransomware encrypts the data doesn’t mean it’s lost forever because to actual erase the files would be much more time consuming and resource intensive. It also would be impossible to actually zero out the files on a file server because the user doesn’t have the proper permissions to access the raw drive in that method (*If permissions are properly setup that is, and User quotas are in place). If anyone would like the files used in this blog post, I would be happy to share the full images. I would also be happy to accept comments and questions just send me an email to wyattroersma (at) gmail.

If anyone would like to know more about memory forensics I’d recommend pre-ordering this The Art of Memory Forensics http://www.amazon.com/The-Art-Memory-Forensics-Detecting/dp/1118825098. Also if anyone needs assistance with Cryptowall or any other piece of malware please just email me.

I’d like to Thank Andrew Case and Michael Hale Ligh for their advise and review of this blog post write  up. I’d also like to thank DoctorW0rm a reddit user who found some technical flaws which I have corrected from “CryptoLocker to CryptoDefense”

Edit:This will not help you with versions of CryptoWall 2.0 and up they have since patched this issue.