This is a topic that is well covered, however given the
explosion of ransomware thanks to WannaCrypt this week I thought I’d discuss
how I’m protecting many of my file servers.
File
Server Resource Manager (FSRM) is available for Windows Server versions
beginning with 2008, but I’ll be focusing on 2012 R2. The specific
capability that we’re interested in for the purpose of detecting and preventing
ransomware is File Screening Management. In short, we create a File Group that
is dynamically updated with the latest known ransomware file name patterns, and
then create a File Screen that we use to trigger email notifications as well as
actually blocking share access for infected users. Let’s get started.
Installing & Configuring FSRM
FSRM is a feature of the File and Storage Services role, and
can be installed either through the Add Roles and Features Wizard, or via PowerShell.
Installing from the Add Roles and Features Wizard:
Installing from the Add Roles and Features Wizard:
Installing from an administrative PowerShell session:
Install-WindowsFeature FS-Resource-Manager -IncludeManagementToolsOnce installed, FSRM can be launched via its shortcut on the Start screen, or by launching its management snap-in, fsrm.msc. Once it's open, right-click on File Server Resource Manager and select Configure Options from the context menu.
Within FSRM Options, on the Email Notifications tab, configure the proper settings for your environment. This defines how we will be notified when our File Screen catches something. Ensure that your mail server is configured to accept SMTP messages from your file server, if necessary.
There are many other options that can be configured on this screen, however for my purposes I have left them at the defaults. I do recommend at least reviewing the Notification Limits tab to adjust the throttling for various alerts that FSRM will send out. Setting them all to 0 can be helpful during testing. Click OK to close the options menu.
With the basic options set, we want to create a new File Group for our ransomware file types. We're not worried about fully populating the File Group at this stage, as we'll do that in the next steps. To create a File Group using the GUI, expand File Screening Management and right-click on File Groups. Then, select Create File Group.
In the Create File Group Properties dialogue, type the name for the new file group. I've named it "Anti-Ransomware File Group". This name will have to match what we use in our scripts later. We also need to include at least one file in the list or we will not be able to save the new File Group. I've added *.crypt. Click OK to complete this step.
To create the new File Group instead via PowerShell, you can use the New-FsrmFileGroup cmdlet. Note that the FsrmFileGroup cmdlets do not exist in Server 2008 versions.
New-FsrmFileGroup -Name "Anti-Ransomware File Group" -IncludePattern *.cryptThe next step is creating a File Screen. To create a File Screen via the GUI, expand File Screening Management and right-click on File Screens. Then, select Create File Screen.
On the Create File Screen dialogue, start by browsing to the file share that you want to protect. On my production servers I have numerous shares on a volume, so instead of selecting an individual share I select the entire volume. In this example, I'm just selecting the shared folder. Choose the button to Define custom file screen properties, and click Custom Properties.
On the Settings tab of the File Screen Properties dialogue, ensure that Active Screening is selected, and check the box for Anti-Ransomware File Group in the Select file groups to block box.
Click over to the E-mail Message tab, and check the box to send email to the following administrators. Enter your administrator email addresses, separated by semicolons. If you choose to send an email message to the user you may check that box as well. Edit the subject and message body as you see fit; This is the email you will receive when the file screen catches a ransomware file type.
On the Event Log tab, check the box to send a warning to the event log. If you're aggregating event logs somewhere, you can monitor for event ID 8215 from source SRMSVC to be notified when the file screen triggers.
Click OK. This brings you back to the Create File Screen dialogue. Click Create. When prompted, select the option to save the custom file screen without creating a template (or if you're creating multiple file screens, go ahead and create a template), and click OK.
At this point, we've configured the options needed to catch and be notified when a file matching a pattern in the Anti-Ransomware File Group is attempted to be written to our file share. This would be a good time to try a test. Create a blank text file using Notepad and save it as ransomware.crypt. Ensure that the file extension is actually .crypt and not .crypt.txt (if you have file extensions hidden, for example.) Copy the ransomware.crypt file and paste it into your newly protected file share. What you should see is that the copy will fail as access is denied. If you've properly configured email, you will receive an email from this event as well. You can verify that FSRM is responsible for blocking the file by reviewing the Windows Application Event Log and checking for event ID 8215 from SRMSVC, as shown here:
At this point, we've configured the options needed to catch and be notified when a file matching a pattern in the Anti-Ransomware File Group is attempted to be written to our file share. This would be a good time to try a test. Create a blank text file using Notepad and save it as ransomware.crypt. Ensure that the file extension is actually .crypt and not .crypt.txt (if you have file extensions hidden, for example.) Copy the ransomware.crypt file and paste it into your newly protected file share. What you should see is that the copy will fail as access is denied. If you've properly configured email, you will receive an email from this event as well. You can verify that FSRM is responsible for blocking the file by reviewing the Windows Application Event Log and checking for event ID 8215 from SRMSVC, as shown here:
Updating the Anti-Ransomware File Group
With the foundation in place and our test successful, we can go ahead and populate the other file patterns that we want to look out for. We're going to use PowerShell to download a current list from fsrm.experiant.ca, and update our Anti-Ransomware File Group. In an administrative PowerShell session, run the following command:
When complete, let's take a look at our Anti-Ransomware File Group in FSRM and notice that the included files have updated. For the moment, we're in good shape. What we need now is a way to automate this script so we can retrieve updated file types from Experiant periodically. Windows built-in Task Scheduler is a quick and easy way to get this done.
First, save the above PowerShell in a script file. You can do this by simply pasting the command into a new Notepad file and saving it with a .ps1 extension. I called mine Update_FSRM_AntiRansomware.ps1, and saved it in C:\Scripts. I use the same directory for scripts across all of my servers for simplicity (it makes things more portable, too). With the script saved to a file, let's setup the scheduled task.
Within Task Scheduler select the Task Scheduler Library and then right-click to Create New Task. Give it a descriptive name, set the task to run under the SYSTEM account, and check the box to have it run with highest privileges.
With the foundation in place and our test successful, we can go ahead and populate the other file patterns that we want to look out for. We're going to use PowerShell to download a current list from fsrm.experiant.ca, and update our Anti-Ransomware File Group. In an administrative PowerShell session, run the following command:
set-FsrmFileGroup -name "Anti-Ransomware File Group" -IncludePattern @((Invoke-WebRequest -Uri "https://fsrm.experiant.ca/api/v1/combined" -UseBasicParsing).content | convertfrom-json | % {$_.filters})When complete, let's take a look at our Anti-Ransomware File Group in FSRM and notice that the included files have updated. For the moment, we're in good shape. What we need now is a way to automate this script so we can retrieve updated file types from Experiant periodically. Windows built-in Task Scheduler is a quick and easy way to get this done.
First, save the above PowerShell in a script file. You can do this by simply pasting the command into a new Notepad file and saving it with a .ps1 extension. I called mine Update_FSRM_AntiRansomware.ps1, and saved it in C:\Scripts. I use the same directory for scripts across all of my servers for simplicity (it makes things more portable, too). With the script saved to a file, let's setup the scheduled task.
Within Task Scheduler select the Task Scheduler Library and then right-click to Create New Task. Give it a descriptive name, set the task to run under the SYSTEM account, and check the box to have it run with highest privileges.
On the Triggers tab, create a new trigger and set it to begin on a schedule. In this example I've set it to run daily at 7AM so it can download the latest file types before my users start work for the day. Be sure to check the box to enable the schedule and then click OK.
On the Actions tab, create a new Action. Select Start a program from the drop-down list. In the Program/script box, type PowerShell.exe. The Add arguments box is where we will call our ps1 script from above by typing the following, then click OK.
-ExecutionPolicy ByPass -File "C:\Scripts\Update_FSRM_AntiRansomware.ps1"
The Conditions and Settings tabs can be customized if desired or left as default. When finished, click OK to save the new task.
How do you know if it's working? Since we just populated the File Group in the process of setting this up, it's unlikely that anything new is available. To test, edit the Anti-Ransomware File Group to remove the first file or two from the list and save the changes. Manually trigger the scheduled task and check the File Group again. If the files you removed are back, the update script and scheduled task are working.
Where does this get us?How do you know if it's working? Since we just populated the File Group in the process of setting this up, it's unlikely that anything new is available. To test, edit the Anti-Ransomware File Group to remove the first file or two from the list and save the changes. Manually trigger the scheduled task and check the File Group again. If the files you removed are back, the update script and scheduled task are working.
An important thing to note about what we've done so far is that we have not done anything that will prevent ransomware from encrypting our files. Why did we bother doing all of this, then? That's a great question. This crypto-blocker strategy relies on the fact that the ransomware we know about today changes the file extension of the files it encrypts, and deposits ReadMe files with instructions on how to pay up. That means that our finance teams' Excel files might change from payments.xlsx to payments.xlsx.crypt. The FSRM File Screen that we setup detects this new file extension and triggers an alert to let us know that something bad is happening. What we have at this point is a crypto-canary, not a crypto-blocker. For some, that might be enough and you can stop here. When you see the notification you can go into triage mode and prepare to restore from backups.
How do we actually prevent the encryption from spreading?
If just being notified of the infection is not sufficient and you want to empower your file servers to protect themselves, read on. We're going to leverage the ability of FSRM to run a command when a file screen triggers in order to block a ransomware infection from ransacking our file server. You'll recall on the File Screen Properties dialogue there is a Command tab which we skipped past before. Let's return to this tab and check the box to Run this command or script.
You'll notice here that I've gone ahead and entered the path for cmd.exe into the script box. By entering command arguments in the box below, we will custom tailor the behavior of our crypto-blocker. We have a couple of options.
Option 1: Stop the LanManServer service (a.k.a. The Sledgehammer Approach.)
/c net stop lanmanserver /yThis will immediately stop file and printer sharing on the server for all users. There are similar approaches documented which include disabling the affected share completely, or even powering off the server. The net result is effectively the same: All of your users lose access. A ransomware process running on a user's machine will lose access to the share and the damage is halted.
Option 2: Block the infected user's share access.
The most graceful method I've found for this uses PowerShell instead of cmd, so replace the path to cmd.exe by browsing to or pasting the path to PowerShell's executable.
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exeThen add the arguments:
-ExecutionPolicy ByPass -Command "& { Get-SmbShare -Special $false | ForEach-Object { Block-SmbShareAccess -Name $_.Name -AccountName '[Source Io Owner]' -Force } }"What this bit of PowerShell is doing is enumerating all of the non-administrative shares on the server with Get-SmbShare, and then passing those values to Block-SmbShare and grabbing the username passed as a parameter from FSRM in [Source Io Owner]. Under command security set the command to run as Local System, and click OK.
Now when the file screen is triggered, the end result is that the share permissions (for every share on the server) for the infected user are explicitly denied. Permissions for other users are unaffected.
Option 2 is my preferred approach for automated file server defense. Some may prefer the blanket approach offered by Option 1 and that's fine. However in my environment there are false positives every now and again, and I much prefer to work with one user on restoring access than I do explaining to my entire organization while they lost access to everything they were working on.
Parting Thoughts
If you're reading this and thinking "Well what about the files that were encrypted in order to trigger the file screen in the first place?", you're right on point. This whole setup relies on a file on your server being encrypted by ransomware in order to trigger any notifications or protection. That means that regardless of how fast and effective this is, at least one file is still going to end up encrypted. Bummer.
One idea to help mitigate that is to place a honeypot at the top of the alphabetical list within each of your shares. For example:
Parting Thoughts
If you're reading this and thinking "Well what about the files that were encrypted in order to trigger the file screen in the first place?", you're right on point. This whole setup relies on a file on your server being encrypted by ransomware in order to trigger any notifications or protection. That means that regardless of how fast and effective this is, at least one file is still going to end up encrypted. Bummer.
One idea to help mitigate that is to place a honeypot at the top of the alphabetical list within each of your shares. For example:
The _honeypot folder is sorted to the top alphabetically, making it the first target for many known ransomware variants. Place a normal text, Word, or Excel file or two within the folder as sacrificial lambs in the hope that they are encrypted first, triggering the file screen and saving the rest of the server's data. This certainly isn't a bad idea, but there's nothing stopping ransomware developers from deciding to encrypt things in a different order tomorrow.
We just can't escape the need for good backups. If the honeypot folder is skipped over or the infection isn't caught quickly enough, we will inevitably end up with encrypted business data. Backup strategies are a different article but it's crucial to have something in place so you can recover from a ransomware event. With properly configured FSRM file screens as part of a ransomware prevention and recovery strategy, you may just be reimaging a user's workstation and restoring a file or two from last night's backup, instead of preparing three envelopes.
No comments:
Post a Comment