In November 2014, I was playing around with some ideas for how to stop and protect file server against
users there was get ransomware on the pc and then the ransomware starts to encrypt
the files on the file server.
My idea was to use the in Windows server build-in function there is called File
Server Resource Manager and I was using this back in Windows 2003 where it was a
bit limited, but in the windows 2008 and 2012 it has got a lot better.
The main idea is that most ransomware are renaming the real files to indicate
that they are encrypted, like when you Word file is named somefilename.doc then
it is renamed to somefilename.doc.encrypted and then in most cases the
ransomware need to tell the user how to pay the ransom, so they often places
files like How_to_decrypt.html in the same folder as the encrypted files.
So using File Server Resource Manager(FSRM) to monitor for specific files like
this get written to the fileserver and when it happens then do some about it.
FSRM can on event send mails, write to event log and run scripts but the script
function there seems obvious to just use this and then run an quick script to
stop the ransomware, but the function is limit to run as local accounts on the
file server and I tried to use that but it was to limited in what I was
trying to do, but more on this later as I use another trick to get around this
limit and run the script as the user account I like it to use.
So what is my script doing to stop the ransomware?
By using FSRM to monitor for bad files and when they are discovered then it runs
a script there is doing these steps.
- Find out what file was written, what user was doing it and from what remote PC and what is the process ID
has the malware on the userís PC, this information is logged to
event log on the file server and used in the next script functions.
- Adding an snapshot to the drive with the share on the server to protect the
more data from get encrypted.
- Via remote commands trying to make a copy of the malware on the userís PC to another file on the userís pc, this is for later forensic analyze of the malware.
- Via remote commands trying to kill the bad process id to get it to stop.
- Tell the users pc to shut down.
- Adding deny ALL outbound traffic firewall rule to the windows firewall on the users pc.
- Adding a firewall rule to the fileserver there deny all traffic from the users pc IP address.
- Adding a firewall rule to the domain controller to deny all traffic from the users pc IP address.
- Disabling the users AD account in the domain controller, to prevent
users from accessing more resources.
- Sending an mail to the administrator saying that user X has written bad file Y to the fileserver from an PC with IP x.x.x.x
This list of actions is just to use as a proof of concept and the script that
you will see later is built to be very modular, so you can disable the things
you donít like or can easily add new functions but more on this later on.
Now you are maybe thinking, why do some many things there is overlapping like
add rules to the firewall when sending a shutdown to the client pc? The reason
is that this script it design to stop the malware from doing more damage to the
fileserver and because it is very likely that some/many of the functions will
not work every time, like the file server can talk with the client pc when in
the company LAN but when happen when the users is working from home via an VPN,
then can the file server run remote commands on the client pc or do the
firewalls prevent that.
So by doing many actions to stop it, then it is more likely that the script can
stop the malware from encrypting all the files on the server. †
The list of files used for monitoring, yes this is an limit as this is an fixed
listed and new malware will most likely use new file names, so this concept is
not better then what list of files that it has to monitor and that is an weak
point, but again I have used this on an number of systems and it has stopped the
ransomware from encrypting files on the file server.
But for you to better see how it works and what happens, then I have made this
video there is showing what happens when the user writes a monitored ransom
See the video here:
But enough for talk, letís look at how to setup the script.
First step is to download the script from
to the file server and unzip them to c:\tools\fsrmscript\
Download it and unzip it, so it looks like this... you can change the path but
then you have to change the path in the scripts also.
What each script is doing will be covered in the guide later on.
Now lets install the File Server Resource Manager and the easiest way is via the
PowerShell prompt and the two commands, like this.
Type: Import-Module ServerManager
Type: Add-Windowsfeature FS-Resource-Manager
The FSRM is now installed and next we need to config it to monitor the shares.
In the start menu, find "File Server Resource Manager" and start it.
In the top on the "File Server Resource Manager (Local)", then right click on it
and select "config options" to see this window.
On the tab "Email notifications" enter the details for your mail system and
click on "send test e-mail" to verify it is working.
Click on the tab "Notifications limit" and change all the limits to 0
click on the tab "File screen audit" and enable the "record file screening
activity in the auditing database"
Then click on the OK to close the options dialog window.
Open an DOS Prompt as Administrator and it is important that you do this as
admin, so right click on "Command prompt" and select "Run as Administrator".
Now change the folder to the install folder by typing "cd
In this folder there is an number of files there help with the setup so we don't
have to do it all by the gui.
If you like to config the global options via command line that we just have set via the gui then
you can just edit the FSRM-config-admin-options.cmd with your settings and then
run the command.
Next step is to import the list of ransomware files to monitor, instant of
typing it manually via the gui then we just import the list from file
Run the "FSRM-import-filegroup-ransomware.cmd" and it will import the
FileGroup-Ransomware.xml as "Ransomware"
Start the File Server Resource Manager MMC and then click on "File Screening
Management" -> "File Group"
Note the new "Ransomware" file group on the list, verify the list of file
names in the group that it is not matching files there already exist on your file server as this
will trigger the script.
When finish looking at the list then just close it again.
Now add the file screener there is monitoring the shared folder and it is using
the file group "Ransomware".
In the dos prompt type this command "filescrn screen add /path:c:\Shares\Data
/type:passive /add-filegroup:"Ransomware" /add-notification:e,ev-besked.txt
Change the path to fit the shared folder on your system, but the other options
is very important that they are as shown for next parts to work.
Next step is to test if the file screener is working and the simplest way to do
this is that you write on file to the monitored folder with an file name there
will match on the ransomware file group and there for trigger the file screener
So i have there for written then file "c:\Shares\data\badfile.crypto" and now
lets look at the event log messages from the file screener.
Open the event log and in the Application log look for the event from source
SRMSVC with the event id 8215
As you can see here it is writing what has happen when writing the test file to
folder and just below the text there is some XML style text with the details,
this extra text is very important as this is used by the script later on.
Now we need to "Attach task to this event" to run an script when this event log
So select the event with the source SRMSVC and the event id 8215, then click on
"Attach Task To This Event..." from the action menu.
Don't change the text, just click Next and on the next screen "when an event is
logged" just click next.
On the page "Action" just "select start an program" and click next
On the page "Start a program" add the program and argument options as listed
here, the syntax is very important
Add arguments: "C:\tools\FSRMscript\Eventactionscript.vbs" /Log:$(MYevLOG)
Then click next
On the page "Finish", verify it looks correct and then click on finish to close
the dialog box.
Next we need to change the Task details so it is returning the command line
aguments to the script as it need, so in the dos prompt run the command
"ELog-Export-Application_SRMSVC_8215.cmd" to export the Task to an XML file.
Now the task is exported to the xml file, open it in notepad and add the
text shown here with yellow highlight and it is very important that it is added
at the correct location.
Text part to add is this:
††††† <Value name="MYevLOG">Event/System/Channel</Value>
††††† <Value name="MYevID">Event/System/EventRecordID</Value>
Then when the text is added and it is at the correct location then save the file
to disk again.
Edit the ELog-ADD-Application_SRMSVC_8215.cmd to use the correct
domain\administrator for your setup and then run the command to import the
Enter the password for the user when it is importing the task again.
Open the Task Schduler and open the properties for the imported task.
Select the security options to be "Run whether user is logged on or not" and
then check the "Run with highest privileges"
Click OK to close the properties window again.
Now in the Task Schduler window, right click on the task and select run, then
wait 5 second and then refresh the window, note that the task has now run and
the exitcode is 0
Next open the event log viewer verify that there is now an eventlog messages
from the script "WSH" with the event id 4 and it is saying that it was started
without the correct command line options, this is normal for the test.
Now the main configuration is done, it is time to edit the scripts to fit your
open c:\tools\FSRMscript\mainactionscript.cmd in notepad and then find this part
around line 85, this is the command there is adding an firewall rule to the
if you like to use this, then remove the "rem" from the start of the line to
uncommnet it and then change the name of the domain controller from DC01 to be
the name of your dc.
To add firewall rules to more servers, then just copy the line for each server
and change the name of DC01 to each server name.
When finish editing the file, then just save and close it again.
Next open the c:\tools\FSRMscript\sub-script\DisableADaccount.vbs in notepad
To make sure that you donít get the important accounts locked out, then add the login
names like shown here with semicolon before and after the names.
If you have add any names to the list then just save the file and close it
Now open the c:\tools\FSRMscript\sub-script\mail2admin.vbs in notepad
In the line starting with "sendinformmail2admin", edit the details to fit your
mail settings and if you need to alert more then one then just copy the line.
When finish editing then save and close the files again.
Now it setup is finish and it is time for testing, but it is very important that
you don't test this from your servers as it will add the firewal rules and
shutdown the server, so to test this the correct way is to use an client pc and
an normal user account, now test it by writing an monitored filename to the file
share and see what happens.
After testing then look at the firewall rules on
the servers and the client pc, also look at the event log on the file server to
see if it has logged the correct details.
So this was my little guide to
use the free buildin function FSRM and some script to prevent ransomeware from
encrypting all files on your fileserver.