Backing Up and the impact of Cryptolocker

Malware logo Crystal 128.
Malware logo Crystal 128. (Photo credit: Wikipedia)

I’ve recently seen a lot of discussion about a piece of malware called “Cryptolocker” – which searches all the drives and network locations it can see (as your user) and encrypts them, before holding the file to ransom, preventing you accessing them without paying the writers for an unlock key”

Clearly, the defence against this is good backups – the malware can’t hold your files to ransom if you’ve got other copies which it hasn’t encrypted.  As always, good backups turn a catastrophic file disaster (be it a failure of the media, or a physical problem like fire, flood, theft etc) into a nuisance which just takes time (and often money to replace the failed/destroyed disks) to resolve.

Cryptolocker adds a new dimension which we as users of backups should be aware of – as some simple styles of backup, may be vulnerable to cryptolocker themselves (e.g. if you backup your files to an external disc between Cryptolocker getting onto your system, and it making that ransom demand) if your backup solution only keeps one version of the file being stored – this could prevent you using those backups to recover your system as the backup itself has been encrypted…

Any backup strategy that doesn’t keep history of file versions is clearly vulnerable, as the backup software will see the encrypted version as a new version and overwrite the old without giving you a way to rollback to a clean version.

Until now, I’ve been keeping second copies of files that shouldn’t change (e.g. holiday photos) under a basic “copy somewhere else” strategy, which has been sufficient for now (the somewhere else consisting of a combination of an external hard drive connected to my home server, and secondary copies stored in the cloud on Amazon AWS) – however this strategy is now flawed for the reasons noted above – new versions (even for my AWS solution) only overwrite, there’s no history storage – a backup is no good if Cryptolocker changes the file, and then the backup software overwrites your good file with the encrypted version.

This is my current understanding of the situation with regard to vulnerability:

Strategy Vulnerable
Simple copy to a second hard drive Yes – if the drive is connected during the attack
Simple automatic copying Yes – automatic copy will overwrite good versions with encrypted files
Version history backup, accessed as your normal user Yes – Cryptolocker can search network locations and encrypt what it finds – which could include your backup histories
Version history backup, secure from your normal user No – ideally there’ll be an “air gap” between the historical backup media and the running system

I’m going to be revisiting my backup plan, in light of this capability of the malware, and the risks of using a straight single version backup being too high. Hopefully I’ll be writing about a new solution and strategy very soon!

I want it to be (relatively) quickly available but safe, and automated to run – I don’t want to be swapping disks at home and manually disconnecting and reconnecting USB drives – right now I’m thinking the solution will be a version controlled cloud store – so only the backup software can directly access it via a web API, with stored credentials – yes the latest file version stored may be encrypted if it was automatically copied, but the older versions should be safe, and good to restore from.

Of course, this will be in addition to my existing backups and up to date anti-Malware software- an external drive is much quicker to restore from in other situations (e.g. a hard drive failing) than the cloud storage would be, and stopping Cryptolocker getting in is better than cleaning up after it – the cloud storage is the last line of defence – for when the local backups aren’t accessable or have themselves been destroyed, either through theft, or disasters like fire or flood, or a problem like cryptolocker, or whatever destructive malware follows it’s lead.