Ransomware: Identification and Response

By now, ransomware is an unfortunate fact of life.  Anyone who’s been working in IT for some time has very likely brushed up against it at some point during their career–and while it’s a stunning encounter in the outset, it’s the response to that encounter that makes all the difference.

Before we go any further, I want to make this very clear: if your data is important to you, it is very wise not to attempt recovery/response on your own.  Bring your machine to a professional instead!  If you have nothing to lose, however, below are some guidelines to follow to attempt recovery in the aftermath of an attack.

It’s useful to comprehend the steps most ransomware specimens take to attacking/encrypting data on a machine to help facilitate a response to their attacks. This is absolutely not meant to be a comprehensive article on the subject (far more detailed analyses have been written by experts such as Lawrence Abrams at his excellent BleepingComputer.com), but here are a few common points that apply to most every ransomware in the wild today:

  • Most of them limit the types of files they encrypt to those which are most likely to contain critical user data–stuff like photos/pictures, documents, videos, databases, etc.
  • System/program/non-user data directories (X:\Windows, Program Files, Program Data, %APPDATA%, etc.) are explicitly excluded from encryption to prevent system stability issues post-infection and improve efficiency
  • Encryption normally begins silently in the early morning hours while the user is less likely to be in front of the machine.

The above items are done in the interest of efficiency to ensure the ransomware is able to complete its encryption job without the user noticing.  Typically, after the completion of the encryption, the ransomware will then remove itself from the system–leaving only a ransom note with payment instructions, as that’s all the attackers care about at this point after all.

Although most of them apply the same strategy (and many are, in fact, even blood-related), the first step to properly responding to a ransomware attack is to take a sample and attempt a positive ID of the malware.  This can be accomplished by using services such as ID Ransomware (by MalwareHunterTeam/Demonslay335), which is a free online resource that attempts to identify a ransomware infection based on either a ransom note or sample encrypted file.  However, it’s very important that you do not obtain the file while running on the infected OS.  Doing so provides the ransomware precious additional time to complete its destruction of the existing data if it has not already completed.  If you must collect the file in the host infected OS, only do so after you obtain a forensic image of the data.

Once an ID has (hopefully) been completed, the next step is to respond and attempt recovery (if necessary/desired)–assuming no backups are present and that does not exist as a (much simpler) option.  This involves several steps, but it roughly goes something like this:

  1. Obtain a forensic image of all affected storage devices/machines and store it safely away from the machine.
  2. Boot to a portable environment and manually inspect the parameters of the system, including:
    1. Boot processes, services, tasks, and other items frequently leveraged by malware as loading points
    2. The locations of any files which are infected, malware, or related to the ransomware infection
    3. The System Volume Information repository contents and the Volume Shadow Copy parameters/settings (to ensure that Shadow Copies and System Restore are turned on and that sufficient space is configured to allow for the storage of Shadow Copies)
    4. The health of any affected storage devices
  3. If necessary, suspend/disable any components which are related to the malware/ransomware infection next.
  4. Once this is completed, reboot into the host OS (Safe Mode if possible) and, if a decrypter has been identified for your particular ransomware infection, obtain it and attempt decryption of the data.
  5. If a decrypter has not been identified, the only remaining solution is usually to attempt to dig into the Volume Shadow Copy Storage in hopes of previous versions of the affected data still being present.
    • Ransomware specimens often attempt to purge shadow copies of files post-encryption to prevent recovery of the files using shadow copy storage.  However, the methods used to do this are often heavy and time-consuming (typically it’s a vssadmin command that’s used to accomplish this).  Many times the process will not have completely finished by the time the user notices the damage.  That’s why sometimes digging into the VSS storage can be a successful solution to recovering data following a ransomware attack.
    • There are multiple tools available which can accomplish Shadow Copy file restoration, but the best is probably ShadowExplorer.
  6. If shadow copies do not exist, the last-ditch effort to retrieve some remaining data is typically to perform a file carving operation on the entire hard drive.  Tools such as PhotoRec can be used to accomplish this.  File Carving identifies files based on their headers and not based on filesystem information/structural data (MFT/FAT/etc).  As a result, it can sometimes turn up lost files even following a ransomware attack.
    • Most ransomware specimens wipe both free space and the sectors on the disk affiliated with previous/clean versions of encrypted files once encryption is complete, so this process is usually fruitless.  But, as a last resort, it’s worth a shot.

If all else fails, backups are the final option.  If no backups exist, the user must consider paying the ransom in hopes of recovering their data–though authorities and experts will invariably tell you not to do this, as it encourages ransomware as a viable business venture and, therefore, the attackers win.  However, most ransomware gangs will in fact restore data following successful receipt of payment–and sometimes it is the only option.

Once recovery has (hopefully) been completed, any remaining ransom notes can be automatically removed using Demonslay335’s RansomNoteCleaner tool here.

For specific help on a ransomware infection, check out BleepingComputer’s free support forum here.  Remember, though–if your data is important to you, let an expert handle it!  Don’t attempt a DIY recovery!

CryptoLocker: UNdecryptable file ransom—How to recover

For some time now, malware authors and attackers buying licenses for use of their programs on the black market have been making a killing off of file recovery ransom schemes.  The most widespread of these was the “Windows File Recovery” style rogues that hit a couple of years ago, where a rogue recovery program named something of the sort would appear on an infected system in an attempt to convince the user that they had lost all of their data due to some catastrophic event (i.e., a hard disk failure) and that they would need to pay to have those files retrieved.  More recently, these were followed up by the still-rampant FBI Moneypak Trojans, which display a message at Windows startup explaining that the FBI has locked the PC due to its use for illegal activities and that the user will need to pay $300 via Moneypak to have it unlocked.

None of these initial attempts were very difficult to thwart unless the user or technician was completely unfamiliar with them.  The Windows Recovery rogues simply hid the files, which could easily be unhidden following their removal.  The most sinister thing they ever did was moved the user’s shortcuts to a hidden temporary folder.  The FBI Moneypak is a cinch to kill once you know of its loading points (though it does often come bundled with the ZeroAccess rootkit).  Some of the later iterations of these ransom rogues took this a step further by actually encrypting the user’s data, but even these could be beaten with special decryption tools.  Eventually, they were assigned the title of Ransomware, which technically could be used to classify any of these specimens.

In case you haven’t heard, there’s a new form of this malware, however, and it’s much, much nastier.  It’s called CryptoLocker, and it also encrypts the user’s data—but it does so using a fusion of AES and RSA encryption that is literally impossible to reverse without the possession of a private key.  That private key resides on a remote server that is only accessible once the user actually pays to have the decryption performed (and it doesn’t always work, either).  By the time the user knows they’ve been infected, all of their precious data has usually already been encrypted.  Needless to say, this is disastrous, especially for businesses.

Over the course of the past few weeks, I’ve had two different customers with this infection.  While it’s true that there is no possible way to decrypt the data, fortunately, there are still ways to recover some or even all of the data (albeit, slightly older versions of the files) if you know just one simple trick.

Windows Vista and beyond include a little-known feature called Volume Shadow Copy.  It’s closely-related to System Restore, of which many people are familiar already, but most people are not aware of the fact that Volume Shadow Copy (unlike System Restore) actually includes management of versioned snapshots of the user’s data as well.

This is a valuable tool in data recovery, of course, provided the system is bootable and the Volume Shadow Copy functionality is accessible/unbroken.  But it also happens to work with current versions of the CryptoLocker Trojan.

Here’s the process you’d need to follow:

  • Remove the CryptoLocker Trojan first or all recovered data will also be encrypted.
    • This is actually pretty easy to do; you can find a plethora of information about it across the internet.  The Trojan loads from an executable in the user’s AppData\Roaming folder (Documents and Settings\Application Data on XP) which can simply be removed to kill it.
    • However, CryptoLocker also has been bundled with Zbot very frequently, so also be sure to check for a randomly-named folder in AppData\Roaming or AppData\Local as well containing a single randomly-named executable and remove it as well.
  • Either right-click on a folder and choose Restore previous versions in Windows 7 to reveal dated snapshots of the contents of that folder, or in any version of Windows (XP SP2 and beyond), download ShadowExplorer to assist in the browsing and copying of these versioned copies.
  • Copy the data from the most recent unencrypted snapshot to a safe location.

If you need help locating all of the files which were encrypted, you can download ListCrilock from Grinler, which is a tool that lists the contents of the HKEY_CURRENT_USER\Software\CryptoLocker\Files registry key (the location CryptoLocker records the files it has encrypted).

While this is a very fortunate oversight by the authors of the malware, I wouldn’t expect it to last.  All that would need to be added is a quick routine to clear all restore points or the contents of the System Volume Information folder to prevent this recovery from taking place, and the authors know this—something which is probably in the works already as this solution has begun to spread throughout the security communities.  Ultimately, what this should do is remind everyone of the importance of regular (preferably versioned) backups offsite or to a drive which is disconnected in between backups (to prevent the files from being encrypted upon the next connection).

Thanks to Grinler for much of the information used to assemble this post, for his excellent tool, and for running a terrific website in the process.

Solution: Recover an Outlook 2007 Business Contact Manager Database from a failed PC

Computer dead?  Don’t have a good backup of your Business Contact Manager data?

This is a serious problem.  It’s not an easy thing to find a solution to, either; those that exist only seem to work for some people, and only under particular circumstances, too.  So in this post, I’ve set out to provide a solution that should work for everyone–hopefully.

Just one preliminary note: this only pertains to the 2007 version of Outlook. While it may work in other versions, I haven’t tested it there.

Okay.  So you’ve got a dead computer (maybe yours, maybe your client’s), and you have the files recovered from the drive–perhaps from a backup.  But unfortunately, as simple as it ought to be, recovering a Business Contact Manager database is far from it.  You can’t simply retrieve the files and then import them somehow.  In fact, from my recent experience, you can’t even make it work unless you follow a very specific order of operations.

Here’s how it’s done:

  1. You first need the *.mdf and *.ldf files from within the Business Contact Manager Local Application Data/%LocalAppData% directory.  Be sure to copy only those files which correspond to your current database (probably those with the most recent Modified date).  You can retrieve those from the failed drive (or backup) by navigating here:
    • On XP, they’re in %USERPROFILE%\Local Settings\Application Data\Microsoft\Business Contact Manager
    • On Vista/7, they’re in %LOCALAPPDATA%\Microsoft\Business Contact Manager
  2. Copy these files to the new PC and place them in a temporary location on the new PC (such as the user’s Windows Desktop).
  3. Install Office 2007 (if it isn’t already installed), along with the Business Contact Manager.
    • If Office is already installed and you’ve already configured Business Contact Manager, you have no choice but to completely remove everything related to Business Contact Manager.  That means everything: Business Contact Manager 2007, and all listed software related to SQL Server 2005. 
  4. Install Microsoft SQL Server 2005 Service Pack 3 (you’ll need the very latest version just in case the files are from a later version than the freshly-installed one, which is likely).
  5. Open Outlook 2007.  Start the Business Contact Manager wizard and instruct it to create a new database with the same name as the old database.  If you’re unsure what the old database was named, it’s easy to tell: simply take whatever text comes before the .mdf and .ldf (it should be identical), and that’s your database name.  It’s very important that the names match!
  6. Immediately close Outlook after the database creation is complete.
  7. Stop the MSSQL$MSSMLBIZ service.
    • You can either use the services.msc interface to do so or open a Command Prompt and type sc stop “MSSQL$MSSMLBIZ” at the prompt (then press ENTER).
  8. Copy the .mdf and .ldf files from the old PC (wherever you saved them) to the Business Contact Manager working directory on the new PC, overwriting the new files with the old ones.
    • It should be obvious where the working directory is located.  If you’re unsure, re-read the sub-points on Step 1.
  9. Set permissions on the .mdf and .ldf files to allow Full Control to Everyone.  Here’s a helpful page on the subject in case you aren’t familiar with this process.  Be sure you set the permissions correctly!
  10. Restart the MSSQL$MSSMLBIZ service.
    • Again, you can use services.msc or type sc start “MSSQL$MSSMLBIZ” at a Command Prompt.
  11. Finally, start Outlook 2007 and verify that all data has been successfully recovered.

Congratulations, you’ve done the impossible!