To protect one's backups against ransom-ware such as 'Locky', one must be careful to not have read/write access to the backup storage location with their main user account. (The one most likely to be infected.) Therefore, a separate set of credentials should be used by Reflect that allows R/W access for backup purposes.

Trying to implement this policy with Reflect however, means backups cannot be manually run from the main user account, since, by definition, that user really should not have R/W access to the destination, but Reflect requires this. On the other hand, with a scheduled backup using the Windows task scheduler, one can run Reflect under an administrative user account that has access to the source and destination files, however, I have found Reflect has one annoying idiosyncrasy:

If the local PC credentials used to run a scheduled task are valid, but only have ReadOnly privileges on the destination, then Reflect WILL NOT try any other credentials in its "Network logon credentials for server shares" configuration list (NLCFSS) and, as a result, the backup fails. So, you have to be careful to run the task with credentials that EITHER have full R/W at both ends OR are invalid for the destination in order to force Reflect to check its NLCFSS list for an alternate set of credentials. This is a fact that Macrium does not explain in their documentation and which cost me several hours of head-pounding!

The obvious solution (IMHO) would be to have the Reflect backup definition file contain credentials to be used for accessing the destination. In this way, both manual and scheduled backups would work in all cases. This is exactly how many other backup programs I have used over the years have worked. Alternately, Reflect could always use its NLCFSS list for both manual as well as scheduled backups. (and never attempt to connect to network shares with the credentials being used to run Reflect)

I hope Macrium will consider fixing this in a future release.

Thanks for reading,
D.Coe

The obvious solution to me, is what I do.  I copy my backups to an external drive (for me once a week, but more or less often depending on your situation). The external drive is only connected to the computer when I am making the copies so there is no way for the files to get encrypted.

Of course, my backups are relatively small so the copy operation takes around 30 minutes (via USB 3).

I do not know how the encryption programs work, but I would think that they would ignore such things as permissions and get every file on the disk.  This could be done using low level file access.  In that case the account would not matter.  What would matter is whether the drive containing the backups can be detected by the malware.  An offline drive is not accessible so it is the safest option.

I agree with D.Coe. This issue was driving me nuts as well the other day, because I couldn't understand why Reflect wouldn't use the network credential I had entered in the default options.

Even though Windows doesn't like creating multiple connections to the same share using different credentials, that can easily be worked around by using e.g. the server name for one connection (\\SERVER\share\) and the IP address for the other (\\192.168.1.1\share\).

I do not know how the encryption programs work, but I would think that they would ignore such things as permissions and get every file on the disk.  This could be done using low level file access.  In that case the account would not matter.  What would matter is whether the drive containing the backups can be detected by the malware.  An offline drive is not accessible so it is the safest option.

Of course, an offline USB drive is a good protection against ransom-ware ... at least until you connect it to an infected PC.

But the rest of the quote doesn't make a lot of sense. When you backup to an external NAS, and the share on the NAS only has write permissions for a certain user account, the ransom-ware has no way to "ignore such things as permissions and get every file on the disk". It would have to connect to that share using the write-enabled user credentials. There is no "low level file access" to network shares.

It is safe to connect an offline drive to an infected PC as long as the system is not running the Windows from that drive.  So booting into a rescue media and using IT to run the restore is perfectly safe.  And if a drive is already infected with ransomware it would be obvious so why would one connect the drive to the infected system while it is booted into Windows?

Again. I do not know how malware works.  However all the Windows protections are in the registry which is on the LOCAL computer.  All the malware has to do is change the registry settings for the user and it can get to the remote NAS without having to use low level writes directly to the NAS.  In other words, use low level writes to make the current user an admin, then use that enhanced ability to access the NAS.  Malware authors are pretty smart and Windows, is, well, not so smart.  If that was not true, Malware would not be able to do all the things it can do.

All I am saying is that it is very possible that someone can figure out a way around any barrier created by the OS.  If that has not already been done for the above scenario, it might be done next month.  The ONLY safe protection for a drive is not having it connected to the computer.

I was going to post the exact same request as I am looking at this issue right now for my backups as I have one home server which gets backups from all our machines.  I am going to try a workaround of launching under with user account impersonation but this could easily be solved in Reflect itself as mentioned above.

You know, you seem to have some very definitive opinions despite admitting to not knowing "how malware works". Of course that's perfectly fine ... everyone gets to do things their own way.

However, to avoid any misconceptions that might arise by reading your post:

• Let's say your PC is infected with ransom-ware on Monday, and it starts doing its thing silently in the background. On Tuesday, before you're aware of the infection, you get out your USB drive and hook it up to the computer to do your backups. That will almost certainly be the death of all backups saved on that USB drive, since the trojan would recognize this new drive and start encrypting all its data.
  
• Of course, malware can root around in the local Windows registry as much as it likes, promoting users to Administrator and whatnot. But that doesn't mean anything to a (properly secured) NAS. A Windows Administrator doesn't automatically get any privileges on the NAS. To be able to write on network shares, they would have to use credentials that are known to the NAS and have write permissions on its shares.
  So the "barriers" the ransomware would have to overcome in order to destroy backups saved on a network share (in the way being discussed here) are not put up by the (compromised) Windows OS, but by the (presumably clean) OS of the NAS. To circumvent those barriers, the malware would have to extract the proper credentials from whereever the backup tool stores them. Not necessarily an impossible task, but substantially more diffcult than simply employing the currently logged in user account.
  

But, to get back on point: Reflect is - at the moment - making it unneccessarily hard to secure remote backups against ransom-ware (and other things, like simple user error!).That should be remedied.

OK, I did say I did not know how ransomware works.  That does NOT mean I do not know anything about it.

Here is a link specific to NAS drives.  While this is ONE case of a NAS being affected, it is not the only case.
http://www.anandtech.com/show/8337/synology-advises-users-of-synolocker-ransomware

Here is the Synology solution: https://www.synology.com/en-global/solution/ransomware

Of course the best way to prevent infection is to keep all software and drivers up to date, avoid questionable websites, do not click on email attachments that are not from trusted sources, and, of course, keep frequent backups in a safe (not online) place. 

Hi D.Coe,

Thank you for your suggestion, I have raised a feature request for the development team to evaluate. 

You may also be interested in this thread discussing ransomware and how to prevent an infection.

http://forum.macrium.com/FindPost6600.aspx

Kind Regards

Stephen

See our reviews on

In the good old days we used to just push the physical "write-protect" switch on real disk and tape drives when we wanted to ensure nothing would write to the device.
I'm effectively doing the same thing with an old HD in a caddy, I turn it on (the PC sees it start up) and run my file incremental backup routine) then I switch it off. Of course I have the advantage that nothing needs to access this drive so it doesn't have to be live all the time. 

Any news on whether this will happen and if so time frame?

I regularly see malware hitting some of our home email addresses and am planning changes to increase protection of backups on our home server.  However I don't want to do all that only to find I could have done it slightly differently if this change gets implemented.

Thanks.