Protect your local file backup from Ransomware

The problem with current ransomware is that it will encrypt any files that are accessible to you the user. So if you can change the file, whether on a local disk, an attached USB drive or a network drive, the Ransomware can encrypt it.

Having a USB drive as backup and keep it unplugged is a quick solution, but that means you have to plug it in every time you want to make a backup.

Assuming that any ransomware is running under your own user-account, because you accidentally downloaded and executed it, or it uses a flaw in any software you are running, then you can do the following:

• Make sure your normal user account is not a member of the administrators group
• Don't just rely on UAC prompts, don't use an admin account for day to day work.
• Always keep your Windows OS up to date with the latest patches.
• Make sure your normal user account is not a member of the administrators group

If you follow this, the ransomware will only be able to encrypt files that you have access to.

Assuming we are using a local drive to back up all our files to.

On the backup drive, we give our main user read access but no write access at all to any files. So it's easy for you to get to a backup copy of a file if you need to, but you can not change the file and the ransomware can not encrypt it.

Set the NTFS permissions on your backup drive like this:

 NT AUTHORITY\SYSTEM:(OI)(CI)(F)
 BUILTIN\Administrators:(OI)(CI)(F)
 BUILTIN\Backup Operators:(OI)(CI)(M)
 BUILTIN\Users:(OI)(CI)(RX)

• Create a new user exclusively used for backing up files and add that account to the Backup Operators group.
• Setup the software that is responsible for the backup to run under that new account. So the software/script/task can write files to the backup drive.
• Make sure your backup process doesn't overwrite files on the backup too often. If some ransomware kicks in and encrypts files, you don't want your backup process to copy those encrypted files over to the backup drive too quickly. Having separate folders with differential backups during the day may work.
• Ideally your backup process would have an option to prevent the copying of encrypted files.
• Make sure your backup process does not copy NTFS permissions with the files, this would give you and the ransomware write-access to the files again.
• Make sure that whatever triggers your backup process can not be triggered by your normal user account.

Implementation

Here are some practical tips about some of the points above.

I'm using PowerShell scripts in a combination with Robocopy to do my backups. Every 30 min a scheduled tasks runs a PowerShell script to copy all new/edited files in the last 24 hours to my backup drive, it has it's own directory for each run, so I have multiple versions and the full mirrored files are not touched during that day. Some time in the evening a second script runs to do a Robocopy /MIR to sync my normal work data with the backup drive. This script has the potential to copy encrypted files and delete the 'good' backup file.

Make sure that whatever triggers your backup process can not be triggered by your normal user account.

I'm using standard Windows scheduled tasks, the problem here is that even though the tasks for my backup scripts are running under my backup user account, my normal user account can run these tasks on demand and trigger the backup operation. So some very smart Ransomware could look at my scheduled tasks and if it sees somethine like Backup... it could just run it. It could also look at the action for the tasks and try to run the PowerShell script directly. Which wouldn't do much harm because the standard user account can not write files on my backup drive. But still.

To lock this down, the most important thing is to not allow having the task run on demand:

$settings = New-ScheduledTaskSettingsSet -DisallowDemandStart
Set-ScheduledTask -TaskName "Admin\Backup Task 30min" -Settings $settings

Now it is no longer possible to just run the tasks using the GUI, schtasks.exe or PowerShell.

I also removed file permissions on the PowerShell scripts for normal users, they should not execute this.

Finally I added some code to the script to make sure they only run by an account who is member of Administrators or Backup Operators:

at the top of my scripts:

Function RequireActiveGroupMemberShip([switch]$admin,[switch]$backupOperators,[string]$sid1 = "",[string]$sid2 = "")
{
   $ERROR_ACCESS_DENIED = 5
   $currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent()

   if ($admin){$sid1 = "S-1-5-32-544"}
   if ($backupOperators)
   {
       if ($sid1 -eq "")
       {
           $sid1 = "S-1-5-32-551"
       }
       else
       {
           $sid2 = "S-1-5-32-551"
       }
   }

   $count = ($currentUser.UserClaims | Where-Object {($_.Value -eq "$sid1" -or $_.Value -eq $sid2) -and $_.Type -match "groupsid$"}).length

   if ($count -eq 0)
   {
       Write-Warning "Your account has not the required mandatory group membership `'$sid1 ($sid2)`', you may need to elevate first"
       Exit $ERROR_ACCESS_DENIED
   }
}

RequireActiveGroupMemberShip -admin -backupOperators

This is defence in depth, if for some reason, the NTFS permissions on the script would allow a standard user to run it, a normal user couldn't execute the backup commands. If permissions allow the user to change the file, this check could be removed, but NTFS permissions on the backup drive should still be in place to prevent any harm.