New ransomware variant also finds & deletes backups?!

I recently came across this forum thread on Veeam’s website, which scared the crap out of me. Coincidentally, Veeam published this article the same day. If these reports are accurate, then it means most organizations have some work to do to better secure themselves against the latest emerging rasomware / crypto-variants.

It makes sense. Probably the number one reason people don’t pay the ransom is that they can restore from backup instead. So if you are designing a ransomware with that in mind, you would be wise to write in some logic to seek out and  then destroy any backup repositories, rather than just encrypting file shares.

How to better protect your backups

Ideally, of course, you would design layers of security to protect you from getting ransomware in the first place. Good perimeter security is part of that picture, and protecting & managing your endpoints well is another. But the thing about security is, you always need to have a contingency plan in place, just in case those other layers fail (and probably someday, they will).

Backup & recovery is absolutely your last line defense, and one of the most important. However, little good that does you if your backup gets deleted, or is itself encrypted. So here are two tips that I suggest for achieving better backup protection, at a minimum:

1. Isolate your backups from the rest of the network. This means in a different subnet behind your firewall, with limited or no communication to the production/data network. Since most of us are doing virtualization these days, I would further recommend keeping the physical host/hypervisor away from your virtual machines, as well; place the host server & backup repositories (whether that is another physical server or NAS) into a DMZ. Use different credentials on both the hypervisor & the backup repositories than anywhere else on the internal domain.*
2. You absolutely need an offsite copy of your backup data. This can be accomplished in many ways, with many different products. It could be at another datacenter or location (if you have that luxury) with its own backup repository and a synchronization script setup on a schedule from the main location (e.g.: backup replication is easily achieved using Veeam’s Backup & Replication product), or it could be a cloud backup service (see Azure Backup), or even a full DRaaS solution (e.g. Azure Site Recovery) with offsite replicas of your full production systems. Better still if you can afford a combination of on-prem backup, a cloud-based backup and another offsite recovery option.

If you do both of these things well (isolation + offsite/offline backup), you will be several steps ahead of the game, compared to most small businesses today. I recommend engaging your technology partner/provider as soon as possible to make these changes.

And if you yourself are a provider, then start talking to your clients about a security update project based on this information. One of the big security predictions for 2017 (based on some other recent reading around the interwebs), is that ransomware in general will continue to evolve, and include worm variants (in other words, this malware crawls around your network looking for other things to infect/damage).

To take the above design a step further, you might even setup ACL’s or another DMZ for your virtual servers/domain infrastructure, and only open the ports that are required for its hosted services (LDAP, SMB, DNS, HTTPS, etc.)–see below.  Before you try to bite off more than you can chew, however, I’d just start with the above, and keep improving from there.

*A note about failover clusters

Since clustered Hyper-V hosts have a strong dependency on Active Directory, you can’t just leave them in a workgroup (which is what I’d recommend for standalone hosts). Therefore, you would need to make sure that the cluster is able to communicate with your AD/DNS servers, on the necessary ports. However, another option would be a separate management domain. To achieve this, I would place one virtual DC on each host’s local storage (so they could be started outside of the cluster entirely), and create a new separate forest/domain root. If your internal domain were “Company.local” I might make it “CompanyHost.local” or “CompanyMgmt.local,” or whatever you like.

In the future, I may even take the time to write up a more detailed design describing an ideal setup, including isolated VM’s, and the ports that would be required for most major domain-based services. Again, for now, I’d just say isolate your host(s) & guests, with the hypervisor and backup repositories not even accessible from the rest of the LAN–that communication should not be necessary, anyway.