A Possible RBackup Hack that can Save You from Ransomware. Maybe.
By now everyone should have heard about Cryptolocker and other “ransomeware” that can infect computers, encrypting files and then demanding a ransom in BitCoins to decrypt them. The news is full of articles about how corporate, personal, hospital and even police networks have been infected and held for ransom.
This potential hack will use Microsoft’s DevCon utility to disable and enable local backup drives at will, hopefully protecting them from ransomware.
So far nobody has come up with a reliable way to decrypt them, so most pay the ransom, but there is another alternative – restore from backups – and not just any backups, because ransomware can also encrypt many kinds of backups.
Ransomeware encrypts files through mapped drive systems. It first infects one drive, encrypting files on that drive, and then it propagates through mapped drives encrypting files on them. Eventually all the drives that are mapped to the infected computer can be compromised.
This includes backup drives that are plugged into the network through USB ports, which many use as their primary on-site backup. Any files on USB drives, network drives, and even cloud services like Google Drive and Dropbox that can be accessed as locally mapped resources can be compromised.
Files backed up offsite with RBackup are safe from ransomware that infects the computer being backed up. This applies only to backups sent offsite to RBS Servers. Backups done with RBackup’s Local options are often on locally mapped drives, so those local backups are susceptible.
However, there may be a way to protect these local files, too, which I will get to in a minute.
In computers infected with ransomware, the RBackup application files themselves are often encrypted, which makes them useless. You won’t be able to run RBackup on the compromised computer to do a restore. You can, however, use RBackup’s Web Restore and Disk Restore utilities after downloading them from your Web Manager.
RBackup sends backups offsite through a proprietary protocol that protects the remote backup repository from infection by nasties that might exist on the computers being backed up, thereby isolating and protecting the RBS Server and its backup data from viruses that might be on those computers.
OK here’s a common scenario. A computer backs up every night, including weekends. The file retention protocol is set to keep 30 days of backups, and Keep Latest Version is ON. Backups are sent offsite to the RBS Server.
Thursday night’s backup went as planned, but on Friday after the close of business (and before Friday night’s backup) Cryptolocker infects the computer. This might (and might not) prevent RBackup from running Friday night’s backup.
If it does, then Friday night’s backup will not run, and all your backups up to and including Thursday night are good. If it doesn’t, then you have good backups through Thursday night, and bad backups Friday, Saturday and Sunday.
You discover the infection on Monday morning. You can pay the ransom, or you can clean the ransomware and recover your backups up through Thursday night using RBackup’s “Only Most Recent Version” function to synthesize a full backup from all previous backup sessions.
You’ll lose whatever you backed up (or didn’t back up) after the infection, but hopefully that’s only one day’s business that can be re-entered.
Protecting local backups with RBackup
Caveat: I do not know if this procedure works IRL. Try it for yourself. Results may vary. I tried it on Windows 7 and was able to enable and disable a USB drive from the command line.
My assumption is that USB drives cannot be infected by ransomware if they are not mounted (attached, mapped). If that’s an untrue assumption, then forget everything I’m about to tell you.
In this procedure we’ll leave a USB drive disabled until we’re ready to use it. We’ll enable it just before the backup, then we’ll do the backup, and then we will disable the drive again. The drive should stay disabled and dismounted, impervious to ransomware, until we’re ready to use it.
This would be particularly useful for backups of Full Drive Images which are stored locally. Full Drive Images are used for very quick disaster recovery. They are standard .VHD files stored in the local environment for immediate mounting.
The problem with keeping these VHD files locally is that the drives they are stored on are usually permanently mounted, and therefore susceptible to being encrypted by ransomware. We are trying to set up a procedure where the USB drive stays disabled until we need it. We’ll then enable it just before the backup, and then disable it just after.
The idea is to use RBackup’s Pre- and Post- batch files to enable and disable a local USB drive. I found many utilities that claim to be able to enable and disable Windows drivers and features from the command line, but of all I tested only Microsoft’s DevCon.exe available in the Windows Driver Kit (WDK 10) worked reliably.
To download the WDK 10, see this link:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff544707%28v=vs.85%29.aspx
DevCon.exe is a tool in this kit. You can extract it and run it independently. I have found several articles describing various ways to use DevCon to do this. This is the method I used. Experiment with it yourself and post your results and recommendations in the Comments here.
I wanted to disable my drive G:, which is a Passport USB drive.
The first thing I did was to locate the device instance ID of the USB drive. To do that, I ran the following command to locate the instance ID of my Passport USB drive:
devcon find * | find “Passport”
Devcon returned the instance ID as:
USBSTOR\DISK&VEN_WD&PROD_MY_PASSPORT_0830&REV_1056\575837314532344A32323234&0
Now I can use this ID as input to Devcon to disable the USB drive like this (note: this text might have wrapped around. Enter it as one single line.)
devcon disable “@USBSTOR\DISK&VEN_WD&PROD_MY_PASSPORT_0830&REV_1056\575837314532344A32323234&0”
Note that in the above command I’ve added @ to the front of the instance ID and surrounded the entire ID in quotes.
In my tests, this command disables the USB drive, and it disappears from the list of hard drives:
Drive G is now no longer mapped, and it has been disabled. Will this protect it from ransomware by making it unavailable to the operating system? Maybe. I’m not willing to test it that far. That’s for braver souls.
I found that I was able to enable and disable this drive at will using “enable” and “disable” commands with Devcon. After I disabled it, I could enable it immediately with:
devcon enable “@USBSTOR\DISK&VEN_WD&PROD_MY_PASSPORT_0830&REV_1056\575837314532344A32323234&0”
Rob’s Big Idea
So, my idea is to write the “devcon disable” command into the autoexec.exe file so it disables the backup USB drive immediately on bootup.
Then place a “devcon enable” command in the Pre- batch file, and a “devcon disable” command in the Post- batch file. This should theoretically keep the local backup USB drive offline and safe until it is needed for a backup.
Of course while it’s mounted (during local backups) it is susceptible.
Since this is all just an idea with very little testing, I can’t recommend it. I did not test to see if the Instance ID changes between reboots. If it does, you’ll have to use another Devcon command that doesn’t rely on Instance ID. Devcon can enable/disable a device and search for it all in one command, so perhaps something like the following command might work better:
devcon enable “*Passport*”
I think this procedure has potential to help protect local backups from damage from ransomware. Play with it yourself and report results here so we can discuss it.
PS: Just after I posted this article I tried the following command and found that it enabled the USB drive, so we’re safe as long as the people writing ransomware don’t include this trick:
devcon enable *
This command enabled all the disabled devices on my computer, including my Passport USB drive.
