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)" -confirm:$false
get-smbsession -clientusername "$($Args)" | 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.