My CrytoLocker cleanup story

Posted on by

Summary

There is a particularly worrying piece of malware doing the rounds called ‘CryptoLocker’ – it’s in the ‘Ransomware’ category and sets the standard for what we should expect going forward with malware.
CryptoLocker infects your machine, encrypts yours files and then demands a $300 ransom, hence ‘Ransomware’
The really nasty thing is not only does it infect and render your local files useless, it also reaches out to any network shares the infected user has and encrypts those files too, turning documents into nothing more than a messy goop!.

This post focuses on symptoms of infection in a client/server scenario, finding the infected workstation through its behaviour with network shares and cleaning up the resultant mess. We considered the workstation disposable and restored a clean system image to it, we didn’t spend anytime trying to remove it – there are plenty of resources on the web that covers removal.

Detection

In this instance detection came in the form of users reporting that they couldn’t open files and were getting errors in Word, Excel and PDF’s. We saw nothing from the Anti-Virus tools installed at all… it slipped straight in under the on-access scanner.

Personally I listen to a podcast called Security now and only a week before they did a deep dive into this malware so I was already primed on what symptoms were likely.

When people started saying “we have problems accessing documents, files are scrambled or won’t open at all” this sounded similar enough for alarm bells to start ringing so we swung into action on the assumption this is what it could be, it turned out we were right.

Errors users saw when opening files on network shares

The file you are trying to open, <file name>, is in a different format than specified by the file extension. Verify that the file is not corrupt and is from a trusted source before opening the file. Do you want to open the file now?

clip_image002

If you open the file, you see what just looks like garbage –

clip_image002[5]

Infected client screen

We only found the infected machine after it had ploughed through at least half of the files in the main file share the business used and indeed knew who it was before they reported it. See the section “Finding the infected client” for how we tracked it down before this message appeared on the infected workstation:

P1010896CryptoLocker

Your important files produced on this computer: photos, videos, document, etc.

If you see this text, but do not see the “CryptoLocker” window, then your antivirus deleted “CryptoLocker from the computer.

If you need your files, you have to recover “CryptoLocker from the antivirus quarantine, or find a copy of “CryptoLocker” in the internet and start it again.

Preventing the spread & damage

The malware itself thankfully doesn’t spread between machines connected to the same network file shares, therefore the cross-infection risk is small.

Once we suspected what was going on we made all the server shared folders read only. This stopped any further damage. From the time stamps on the top level folders we could see that it got about half way through the main shared drive.

Actions:

  • First read “Finding the infected client”, then:
    • Mark your server side folders/network shares read only (if you haven’t grabbed the output of the net session command you will lose the best chance you have of spotting the infected machine at work and we only had one other method of detection).
    • Stop all VSS snapshots in the scheduled tasks of the server/s in question, taking snapshots of encrypted files isn’t going to help anyone.
    • Check you last offline backup – tape, DPM, Cloud, etc… if VSS fails you may need this!

Finding the infected client

Line of evidence part 1

From the server we launched a command prompt and typed ‘net session’. We repeated it three times looking for consistently high sessions count from a user/workstation relative to others. Immediately we spotted a suspect, but by itself this wasn’t conclusive (You can do the same thing from Computer Manager > Shares – note the server in question was Windows Server 2003, this isn’t so easy from the GUI in Server 2012.

In our case, we noted one users which had over 40 open sessions to the share in read/write. In a busy environment that might not be unusual but the giveaway is the types of files open – Word, Excel & PDF’s for the most part (visible under Computer Manager > Shares)

We used a second line of investigation to provide another list of suspects and to see if there was any overlap.

Line of evidence part 2

Using the Omnispear tool mentioned in the next section below we mapped a drive to the user home folder as a domain administrator and let it loose scanning the redirected home folders for encrypted files. The key thing we were looking for was encrypted word, excel and PDF files. For files it doesn’t understand or with DRM (read DRM, think encryption), the tool naturally believes these are impacted so you have to filter those out when the time comes.

By this time you should have already marked all your server shares as read only.

From the output CSV –

1. Convert the file to excel format

1a. Optionally create a formula to extract the file extensions from the full file path column the tool generates. You are really only interested in Office docs and pdf’s.

2. Copy out the full path column into notepad++ and replace the “\” with tabs. When you paste the column back into the Excel at the end of the last column, you will have a filterable set of columns which contain the username in a single column (assuming you mapped a drive to the user home folder, e.g. Z:\<user home folder>)

3. Throw the data into a pivot chart and look compare the “Valid file format” count vs the “May be encrypted” count.

Below is the chart we got and the same user stood out

image

 

Finding the encrypted files

Once you know you’ve been hit and have stopped the spread of infection, you need to assess the scope of the damage. Fortunately, the folks over in Omnispear have written a little app that scans files for encryption.

Some things to note when using it:

  • It doesn’t understand every file type so produces a lot of false positives
  • If you scanning user home folders, some people might have music which have DRM so will appear encrypted.
  • If you want to run two scans in parallel, make two copies of the application folder and launch it again.
  • It runs pretty quickly when you run it from the server, I wouldn’t run it from a client PC to the network share.
  • Each instance of the application produces a single CSV with the same name

Screenshot:

image

Download the scanner here: http://omnispear.com/tools/cryptolocker-scan-tool

Once you have the CSV save it as an excel file

Recovering from the infection

We opted to use volume shadow copy snapshots to recover the data. Tapes were available but were never going to be quick and the last good backup we could restore from tape was 2.5 days ago whereas the most recent unaffected VSS snapshot was <24 hours old.

On infected client machines this isn’t an option though, the malware disables VSS snapshots so you can’t use the same technique there – did we say this is a nasty piece of malware!?!

The infected users My Documents were also on the server through a redirection in group policy so we could roll back their folder to an unaffected point too.

Mounting the VSS snapshot

It is a little known thing but you can mount a VSS disk shadow copy as a drive and copy files out with your favourite file copy commands. The primary reason for doing this is when restoring large VSS snapshots you are likely to hit some errors (Error, cannot copy file: or Access Denied) which have been hiding in the file system. When the VSS client application that exposes the Previous Versions tab hits and error there is no “skip”, it just stops dead where it was. Not good when you have 100’s of gigs worth of data to restore.

1. Browse to the shared folder through the network, e.g. \\server\d$\data\
2. Right click on the folder and click on “properties”.
3. In the previous versions tab, select the snapshot that doesn’t contain the encrypted files (might require some checking to find a snapshot that is good) and click on “View”.

image

4. In the explorer window, right click anywhere in the explorer window that opens and click on properties.

image

4. In the properties window, select the entire contents of the “Location:” path, then copy and paste it. Note that what shows in the location area and what gets copied into the clipboard aren’t necessarily one and the same, we noted different behaviours on Win2K3 and Win2K3 R2 (who thought these OS’s were still out there!). Regardless, mapping a drive to the copied and pasted text works just fine.

image

5. Map the drive to the copied location ( Tools > Map network drive).

6. Copy out the contents of the VSS on top of the effected folder.

Example: xcopy “X:\09 Projects” “D:\Data\Public\09 Projects” /e /c /r /u /y /f >Xcopy20140116FileRestoreFromVSS.txt

 

Tools, references and resources

*.odt, *.ods, *.odp, *.odm, *.odc, *.odb, *.doc, *.docx, *.docm, *.wps, *.xls, *.xlsx, *.xlsm, *.xlsb, *.xlk, *.ppt, *.pptx, *.pptm, *.mdb, *.accdb, *.pst, *.dwg, *.dxf, *.dxg, *.wpd, *.rtf, *.wb2, *.mdf, *.dbf, *.psd, *.pdd, *.pdf, *.eps, *.ai, *.indd, *.cdr, *.jpg, *.jpe, *.jpg, *.dng, *.3fr, *.arw, *.srf, *.sr2, *.bay, *.crw, *.cr2, *.dcr, *.kdc, *.erf, *.mef, *.mrw, *.nef, *.nrw, *.orf, *.raf, *.raw, *.rwl, *.rw2, *.r3d, *.ptx, *.pef, *.srw, *.x3f, *.der, *.cer, *.crt, *.pem, *.pfx, *.p12, *.p7b, *.p7c

…And some tools that didn’t help

 

Conclusion

Ultimately the customer spent more with us fixing the the infection than paying the $300 to have the encryption removed by the criminals. If it were my money, would I have done the same? Yes. Every time.