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.

“Infected” routers threaten death by DNS

Recently, I took delivery of a client’s PC which had been thoroughly scanned, but he was concerned that it might not be fully clean.  If you’ve followed my work, you already know that this is relatively common; scanners, for all their merits, can only access what they’re allowed to access, and they can only detect what they’re written to detect.  Even heuristic detection can only go so far, and with today’s polymorphic malware (a.k.a., malware which changes its form with every specimen), signature-based detection is hardly reliable for the ever-common zero-day threats.

Such was indeed the case with this client’s computer, which was indeed still infected, regardless of clean scans by Symantec, Ad-Aware, and other utilities.  Although nothing had identified them, they were almost certainly a new variant of the Trojan.Tracur family of malware.  Previous versions of the Trojan have been known to create copies of local system services, using legitimate descriptions for legitimate services and even the same names—just suffixed with the number “32”.  Normally it drops related files in the system32 directory, but this variant actually had created its sister files inside \ProgramData over 30 of them, one for nearly every single service on the system.

But that isn’t the subject of this blog post.  More interesting was the phone call I received once this client had taken their PC back home and begun using it again: he was still having problems, he told me.  Web sites were loading with weird formatting, and when using Chrome, login attempts at popular sites popped up another window prompting a second login.  The behavior sounded very similar to what some rootkits attempt to steal passwords and financial data.

This situation might not sound strange, but you have to understand: I never return infected computers.  I had performed the same rigorous inspection on his before calling him to pick it up, including a full analysis of all OS loading points, drivers, services, and the master boot record of the system drive.  I also check for policies, malicious proxies, faulty DNS caching, and infected critical system files—nearly all of this manually, using tools which I have specially developed for the task.

So I wasn’t convinced that malware was still on the PC—but I was concerned that perhaps we were missing something else.  I reviewed his logs (of which I keep detailed copies for every client) and found no signs of any danger, so I began considering other possibilities.  What else could possibly be the problem?  His router.

Router infections are nasty little things.  Technically, they aren’t infections, but rather, corrupted settings (thanks to malware) which lead to compromised PCs and information. They aren’t necessarily new; this has been a trend which actually started a couple of years ago and has become increasingly common among malware.

It’s actually pretty simple how they work: once a client computer has been infected, the malware takes advantage of the fact that no one ever changes their default router password.  Equipped with this information, it accesses the router configuration and changes the DNS servers to malicious servers of its own, which can filter and steal traffic passing through them or even redirect users to altogether different sites when they request a page.  This can be made entirely transparent to the user, as the displayed web address (the so-called FQDN) is still the same—only the resolved IP address has changed.

It isn’t uncommon for such router infections to reinfect clients even after they’re cleaned, presenting a seriously hazardous situation.  The solution involves simultaneously performing a hard reset on the router (by holding down the reset button for 15 seconds or longer) and disinfecting the PC (and all affected PCs on the network) before connecting back to the router.  Following that, the network must be reconfigured on the router, and a password needs to be set to prevent future infiltrations.

In my client’s case, there really wasn’t any proof that this was what was happening with his PC, but it was the next logical step after rechecking his PC remotely using some log-generating deep system scanning software.  So we reset the router, which seemed to resolve the internet traffic issues.  However, the problems with Chrome persisted, even without any extensions installed.  Given the options, we eventually elected to uninstall Chrome, chalking up the additional problems to a possible unknown bug in the browser itself.  Case in point: no other browsers, including Mozilla Firefox, had the same issue.  Just to be certain, I rechecked all proxies, the master boot record, and system files.  The PC was indeed 100% clean, and my client was happy.