Ransomware Protection - File Screening

Availability for the Always-On Enterprise

Re: Ransomware Protection - File Screening

Veeam Logoby ryan1212 » Mon May 22, 2017 4:44 am 1 person likes this post

Something really simple that can be done-- disable SMB file sharing on your repositories and/or block the port in windows firewall. It is not needed for Veeam to write or restore data, and should block most ransomware. For the few times you might need to move backup files from one repo to another, just white list the IP temporarily, and then block it again.
Posts: 16
Liked: 6 times
Joined: Tue Feb 26, 2013 3:48 pm
Full Name: Ryan

Re: Ransomware Protection - File Screening

Veeam Logoby cbc-tgschultz » Mon May 22, 2017 4:49 pm

Even if WCry does the rename step before the encryption step, that is unlikely to be true for all ransomware variants, and some might not do any renaming at all or continue to process other files even though the rename failed. Make sure you at least enable the email alerting in FSRM so you'll be able to take action as soon as the first attempt fails and hopefully you can prevent it from doing too much damage regardless.

FSRM allows a more aggressive option too. You can have it launch an arbitrary program with arguments when triggered, and you can use this to launch a powershell script that actively defends the server by shutting off share access for the offending user account. Here's an example script:
Code: Select all
#Automatically blocks a user from all shares
#used by File Screens to help prevent Ransomware attacks
# to undo:
# get-smbshare | unblock-smbshareaccess -AccountName <DOMAIN\user> -confirm:$false
get-smbshare | block-smbshareaccess -AccountName "$($Args[0])" -confirm:$false
get-smbsession -clientusername "$($Args[0])" | close-smbsession -confirm:$false

Pass it the argument "[Source Io Owner]" from FSRM.

Another option that doesn't involve FSRM or have a dependence on file extensions is to use a canary. What you do is create an office document with a name that makes it obvious to your users that they shouldn't touch it and that will appear at the top or early in the file listing (keep in mind that ransomware usually traverses directories depth-first). Enable object auditing on the server for success events. Give the canary an SACL to monitor for success events on create/modification/delete/takeownership/changepermissions. Create a scheduled task triggered by "Security" log event ID 4663 with "Microsoft-Windows-Security-Auditing" source, and an action that launches a powershell script with the arguments "$(SubjectDomainName)\$(SubjectUserName)" and "$(FileName)". The powershell script should check that the user is not a computer object (account name ends in "$") because the server will log itself as modifying the file before the user account does, and you may also wish to have it check the filename if you have other SACLs set up for other purposes. Have that script run the share blocking script above with a valid user, and it would also be a good idea to have it send an alert email using "Send-MailMessage".

Note that the share blocking will fail on administrative shares (C$,IPC$,etc).

There are a lot of ways to combat ransomware, and none of them are perfect, so I recommend implementing a whole bunch of them in layers.
Posts: 49
Liked: 10 times
Joined: Fri May 13, 2016 1:48 pm
Full Name: Tanner Schultz


Return to Veeam Backup & Replication

Who is online

Users browsing this forum: allanh, Google [Bot], ronnmartin61, vo243 and 100 guests