Tag Archives: CryptoLocker

You May Pay Even If You Do Everything Right (CryptoLocker)

Written by William Roush on January 13, 2014 at 7:14 pm

Many people in the IT field are depending on various products to protect them from CryptoLocker and similar malware, but how realistic is that really?

Seth Hall over at tunnl.in wrote an article detailing how many parts of your system must fail in order for CryptoLocker to infect your network. The major problem I have with the article is that this level of trust in your systems to protect you is exactly how a lot of companies got bit by the CryptoLocker ransomware, and the concept that "if you have these bases covered, you’re ok".

You’ll need an email server willing to send you infected executable attachments.

This assumes that CryptoLocker is going to come in a form that your email server will catch. One of the easiest ways to prevent your email server from blocking a piece of malware attached to an email is to password protect it. Which CryptoLocker has been known to do [1] [2] [3]. This leaves a handful of options in detecting the email: Either have a signature for the encrypted zip file, which if unique passwords are being used per email that wouldn’t work, or attempt to unencrypt all zips by searching the body of the email for the password (which I don’t think any mail filtering services do this).

And that is all dependent on the idea that you’re being infected by an already detected derivative of CrytpoLocker.

Your perimeter security solution will have to totally fail to spot the incoming threat.

Here Seth is talking about Firewall based anti-malware scanning. Again this falls into all of the same problems as relying on your email server to protect you.

Your desktop security solution will have to totally fail.

This is one of the major ones everyone relies on, your desktop antivirus catching malware, and by far this is what bit almost everyone infected by CryptoLocker. In my previous post about CryptoLocker I talk about how it wasn’t till 2013-11-11 that antiviruses were preventing CryptoLocker. With PowerLocker on the horizon these assumptions are dangerous.

Your user education program will have to be proven completely ineffective.

Now this is one of the major important parts of security, and by far one of the largest things that irk me in IT. I’ll go into this more in a more business-oriented post, but it comes down to this: what happens when I allow someone into the building that doesn’t have an access card? Human Resources would have my head and I could very well lose my job (and rightfully so!). Why is it that IT’s policies get such lackluster enforcement at most places?

In general, IT policies and training is always fairly weak. Users often forget (in my opinion: because there is no risk to not committing it to memory), and training initiatives are rarely taken seriously. People who "don’t get computers" are often put into positions were they’ll be on one for 8 hours a day (I’m not talking IT level proficiency, I’m talking "don’t open that attachment").

I feel this is mostly due to the infancy of IT in the workplace at many places, and will change as damages continue to climb.

Your perimeter security solution will have to totally fail, a second time.

It really depends on how you have your perimeter security set up. Some companies are blocking large swaths of the internet in an attempt to reduce the noise you get from various countries which they do not do business with and only receive attempts to break into their systems. This is pretty much the only circumstance your perimeter security will stop this problem.

Your intrusion prevention system […] will have to somehow miss the virus loudly and constantly calling out to Russia or China or wherever the bad guys are.

This is by far a dangerous assumption. CryptoLocker only communicates to a command and control server for a public key to encrypt your files with. I’d be thoroughly impressed by a system that’ll catch a few kilobytes of encrypted data being requested from a foreign server and not constantly trigger false alerts from normal use of the internet.

Your backup solution will have to totally fail.

This is by far in my opinion the only realistic "this is 100% your responsibility with a nearly 100% chance of success" on this list. Backups that have multiple copies, stored cold and off-site have nearly no chance of being damaged, lost or tampered with. Tested backups have nearly no chance of failing. Malware can’t touch what it can’t physically access, and this will always be your ace in the hole.

In Conclusion

And don’t take this post wrong! The list that Seth gives is a great list of security infrastructure, procedures and policies that should be in place. However I think it reads as if you won’t get infected as long as you follow his list, and that is not entirely accurate.

Cryptolocker – The Dreaded Trojan Horse Malware That’ll Put Your Company At Risk

Written by William Roush on November 13, 2013 at 8:47 pm


CryptoLocker is the latest nightmare malware that people in the network security community have been dreading for awhile. It follows very basic encryption principals that make it impossible to crack and get your files back, the software is simple and has been constantly evolving making it impossible for antivirus programs to keep up.

So far companies have been put out of business due to their IT staff not being prepared for an attack like this. Do not be the next company to get added to the list of casualties.

How CrypoLocker Works

CryptoLocker so far has only been seen coming in over e-mail, usually attached in a ZIP file. System administrators have reported CryptoLocker spreading through spoofed e-mail accounts to mailing lists, meaning that whoever is helping spread this malware seems to be hand-picking easy targets that’ll likely open attachments, not just blasting e-mails indiscriminately. Additionally there have been reports of infections through Java, and infections through the Zeus botnet.

Once you’re infected, CryptoLocker calls back home for a RSA 2048-bit public encryption key, this key can only be used for encryption, it will not work for decryption of your files. It will then encrypt all files it finds both on your machine, and on any attached network drives (this includes cloud storage like Google Drive and Dropbox) that end in the following extensions (this list may be incomplete):

*.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, *.eps, *.ai, *.indd, *.cdr, .jpg, .jpe, img_*.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, *.pdf, *.tif

Then it’ll wait for you to pay for the decryption key for 72 hours, after the 72 hours your encryption key is deleted and your ability to recover the encrypted files are gone forever. Some more recent versions allow you to upload an encrypted file which they’ll crack for more money (> $3,000) after the 72 hours expires.

How Do I get My Files Back?

The answer is one of two methods: pay the ransom, or recover from backups. So far if our current understanding of how CryptoLocker works is correct, it’ll be pretty much impossible to “crack” your files (people have been handing around a crack for MBL ransomware, this will NOT crack CryptoLocker, the encryption algorithms are completely different). CryptoLocker is a strong reminder that offline backups are extremely important. Online backups can be useless, being as CryptoLocker will gladly encrypt those if they’re attached to the system that has been infected. If you’re backing up to a removable hard drive, keep them unplugged when not actively backing up, additionally I’d recommend rotating at least two drives in and out, so if you get infected while you have the one drive plugged in while you’re actively backing up, you can always recover from the other.

Paying the ransom has appeared to work fine, however recovery of your encrypted files has been reported to be around 5GB/hr, so large file servers can take days to be recovered, in cases where a solid backup would bring a business back online in minutes. Additionally the original infected machine keeps a list of all encrypted files in the registry, you must not clean/remove this machine being as it must be used to decrypt the files on your hard drive. However even if you follow all the previous requirements and pay the ransom, some command and control servers have been taken offline, and their encryption keys have been lost.

Shouldn’t My Antivirus Prevent It?

As of definitions released on 2013-11-11, most antiviruses seem to be able to catch both the older variants and the newer variant compiled on 2013-10-21 13:23:51. This however is no guarantee that new variants of the malware will be produced that will not be stopped, it’s been running wild for over two months at this point, lots of people depended on their slow antivirus vendors to protect against malware such as this and paid the price.

Can’t We Stop It From Calling Home?

Technically yes: however your machine needs to be removed from the internet. The creator of CryptoLocker has so far thought of everything, and is jumping to new command and control servers at regular intervals. It appears that CryptoLocker derives a domain from the system clock, and will generate where the next server’s domain name will be (example: www.gevcgvgufvpiqozpnzpj.com), and the servers that these domains resolve to appear to be random, set up until they’re caught and taken down.

Prevention Methods

In order of the line of defense: the first would be your mail server (the main entry point of CryptoLocker). First you should never be accepting executable files, that includes scanning ZIP files for executables, some administrators have even gone as far as to automatically quarantining all ZIP files. Additionally removing Java will help if the above report of a Java infection from a jnlp file is to be believed. Additionally either look into a mail filtering solution or make sure your antivirus definitions are up to date on your mail server.

Of course the next layer is your end users, educating users to never open unknown attachments is always very important. This is always hit and miss depending on your company’s attitude towards IT (and how strict your company has been with enforcing use policies). This is of course the most effective long-term solution, but may be unrealistic.

Group Policy Objects to enforce to hopefully block CryptoLocker.

Group Policy Objects to enforce to hopefully block CryptoLocker.


See an updated list of SRPs here.

The final layer that you’ll have control over is catching CryptoLocker before it can do it’s damage. So far the only effective method has been to disallow applications from running from the user’s AppData folder. While this is an acceptable short-term solution, I would not be surprised to see variants of CryptoLocker finding random locations to execute from and picking one, making it impossible to stop it via this method.

Of course with antivirus definitions catching up over the past couple days, we may see the malware creator take his winnings and go home, so keep those definitions up to date and buckle down and hope for no more variations that’ll slip past.

Also, for those that are really brave, there are 3rd party applications like CryptoPrevent, I haven’t heard anything good or bad about these tools, so investigate at your own risk.

Protecting Yourself In The Event Of An Infection

As you might have guessed, the above methods don’t seem that certain to prevent an infection, and it’s an unfortunate reality of this virus (at least for the time being), so the best we can do is have a strong recovery plan in place. Always stick with the basic 3-2-1 backup rule:

  • 3 copies
  • 2 different types of media
  • 1 offsite/offline

Make sure you have a solid server backup solution (VSS snapshots on Windows have shown to work well as one of these copies), confirm it’s running, run some restoration tests to make sure your backups are in good condition and you can restore promptly in the event of an emergency. If restoring your file server from your cloud backup provider is going to take two weeks now is a good time to consider another backup solution that’ll cut that recovery time in the event of CrypoLocker. Make sure that either all users are storing their files off of their machines (folder redirection, offline files, etc.) or make sure you have a solid client backup solution on-site (I recommend CrashPlan PROe).