Malware is becoming an increasingly more common threat in our digital world, no longer are virus writers exploiting vulnerabilities in operating system code but they have instead discovered a much easier attack vector. Simply convincing users to run their malicious software through social engineering.The thing that makes CryptoLocker dangerous is that once it has encrypted your files, there really aren’t many options for you. The best (and arguably only) defence is a solid backup and recovery solution (a cool head helps too!). Malware remove tools won’t be able to decrypt the files without the secret key, and depending on the variant the control servers might have been taken down, so there might not even be anyone to pay. This article outlines what you as a system administrator need to do to prepare for and react to a CryptoLocker infection.
Right now one of the most common pieces of malware going around is called CryptoLocker. This malware encrypts documents and throws the decryption key away into the internet, leaving a ransom note: Pay up if you want your files back. Ransomware isn’t new, and even CryptoLocker has been around since 2013, netting an estimated $USD41.9 million1) (in the 3 months between Sept to Dec2013!) to the authors. The original variant had its command and control servers taken down in Operation Tovar2), but this hasn’t changed the facts, it made some people very rich. It shouldn’t be a surprise that new variants and copycats have come out.
1. Pre-EmptThey say prevention is better than cure, here is a list of things that you should be asking yourself:
- Have you reminded your users to scrutinise every email. Most CryptoLocker infections are from emails convincing users that they have received a speeding fine or a package tracking notice that required them to download and run an executable. Being asked to run executables from the internet should always be a cause to be wary. If you smell deceit, hit delete!
- Are you using a robust backup product? When was the last time you tested restoring from backups? Do you keep backups off site? Don’t get caught out. Good, reliable backups are CRITICAL. How long is your backup retention? What if you only notice files encrypted weeks later…
- Do you have a transparent proxy that filters web traffic? Palo-Alto, Sopho UTM, McAfee, Checkpoint etc.
- How about on your workstations? Is the antivirus up to date?
- Have you applied an auditing policy on your file server? This won’t stop CryptoLocker from running, but will making finding the infection much easier. Simply enable file system auditing, and apply an auditing rule on your file shares to capture, file creation/deletion. This way you can find out from the logs which user logged into which machine deleted documents and created encrypted versions.
- Do you trust your antivirus? There are hash based file blocks you can configure using Group Policy to add further protection. This will from a Windows policy level stop CryptoLocker from running if it is a variant that matches the policy.
2. Identify SourceOnce you are infected your first step should be to identify which workstation is infected. Otherwise you can restore your files all you like, they will just get re-encrypted.
Did you setup an audit policy? If you did all you need to do is open the security event viewer and do a find for the filename of an encrypted file. This will show you the user that deleted the file. They will be the one infected. Without an audit policy things get harder. Is there a computer with many open files on the file server? High network bandwidth usage? Remember that CryptoLocker will only encrypt file shares that are mapped to a folder. Is there a user with a home directory that’s encrypted?
3. Clean the InfectionCryptoLocker is not a worm, the encrypted files won’t infect anyone else, and unless you run the executable on another machine the infection will not spread. Still it’s best to isolate the workstation as soon as possible by unplugging the network cable. Use your usual malware removal tools such as Malwarebytes to clean the system of CryptoLocker.
4. Identify Damage DoneNow its time to determine the extent of the damage. Scan the user’s mapped drives for .encrypted files. Here is a simple powershell two-liner to do it. Change the value of $path to the location you want to scan. The script will output a text file called encryptedList.txt which will contain all the files that have been encrypted.
As part of operation Tovar a number of decryption keys were siezed. If you are lucky the key that you need will be avaliable at nomoreransom.org. Otherwise you need to recover from backups. The easiest way to do this is to recover the entire directories that were encrypted with overwrite disabled. CryptoLocker changes the file extension of the documents. Thus it is safe to say that if the exact filename exists in the backups but not on the file server then the file needs to be recovered. By disabling overwriting, any files that were not encrypted will not be touched. You can check if you recovered everything using the following PowerShell. It will output two text files restoreSuccess.txt which contains all the file successfully recovered, and restoreFail.txt which contains all the files that were not contained recovered.
6. CleanOnce you are satisfied that you have restored everything, you will want to delete the encrypted files, and the DECRYPT_INSTRUCTIONS.html files that got created. Here is another simple powershell script.
7. Post-MortemNow that you have survived CryptoLocker, its time to ask the important questions.
- How did the infection occur? Did it originate from an email? How did it get past our defences? Was the virus vendor aware of this variant?
- Were you appropriately prepared? Did you know how to use your backup product or were you second guessing every option?
- How do we stop future infections? Better web filters? Better antivirus? Do users need further education?