Protect your local file backup from Ransomware

1 August 2016

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:

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)

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.

Tags: IT Pro | Security

Pages in this section

Categories

ASP.Net | Community | Development | IIS | IT Pro | Security | SQL (Server) | Tools | Web | Work on the road | Windows