Using File Screen to block Ransomware like WannaCry on server shares – Part 2

In Part 1 we used the script New-FSRMServer.ps1 to set up a File Screen server from scratch, this part will describe how to update the settings.

The source files for the scripts can be found on GitHub:


Update the variables you want to change in the Update-FSRMServer.ps1 script (see Part 1 for an explanation of the Variables):

#Function Declarations
# Extensions that will block user access to the share
$ransompattern = @("*.wnry", "*.wcry", "*.wncry", "*.wncryt")
# Disk drives that will be excluded from File Screen
$diskexeptions= "C","T"
# General FSRM Settings
$SMTPServer = ""
$SMTPFrom = ""
$AdminEmail = ""
# Event settings for the "Ransomware template
$EventCommand = 'C:\Windows\System32\cmd.exe'
$EventCommandParam = '/c "C:\RansomwareBlockSmb\StartRansomwareBlockSmb.cmd"'
$EventCommandWorkDir = "C:\Windows\System32\"
$EventLogEntry = "[Source Io Owner];[Source File Path];[Violated File Group]"
$SMTPTo = "[Admin Email];[Source Io Owner Email]" 
$emailSubject = "Security Announcement from the IT-Department"
$emailBody = @"
Your account have been locked out. The reason is that you or someone in your name have tried to change a file extension to an extension identified as ransomware.
1. Shut down your computer immediately
2. Have your logon name and computer name ready.
3. Contact Helpdesk immediately and inform them that you have received this message.
File: [Source File Path]
Server: [Server]
Username: [Source Io Owner]
/Your IT-Department

Depending on what changes been made you can choose to comment out one or more of the last lines of the script:


Updating the servers

To update your servers just run the script:

servers = "server1","server2"
Invoke-Command –ComputerName $servers –FilePath .\Update-FSRMServer.ps1

Thats it!

More tips

If you want to automatically update the File Screen with known extension for malware there seems to be a Canadian consulting company called that supplies a list of extensions that can be downloaded via the script ( I have added the code for this in the script but it needs to be uncommented (and the original row needs to be commented out):

#set-FsrmFileGroup -name "Ransomware_Extensions" -IncludePattern @((Invoke-WebRequest -Uri "" -UseBasicParsing).content | convertfrom-json | % {$_.filters}) 
Set-FsrmFileGroup -Name "Ransomware_Extensions" –IncludePattern $ransompattern -ErrorAction Stop |Out-Null

Warning! I am not affiliated with this company in any way and I do not know their process for adding an extension to the list! This means if a safe extension gets added to the list you could potentially block all your users from your file servers! Therefor I do not recommend using this list with the event command enabled. If you want to leverage this function I would recommend tweaking the script so you have 2 levels.:

  1. High risk malware, create one File Screen template using the original scripts with the event command enabled for blocking users from SMBShare access. Update the extension list manually!
  2. Automated extensions, make a copy of the scripts and modify them so a new File Screen template is created but utilizing the Experiant list to update file extensions. Also make sure the event command is removed. The Update-FSRMServer.ps1 can then be scheduled to run every day with a scheduled task.

They have a script ( describing how to add a skip list to the extensions list, with a little PowerShell knowledge this could easily be added to my solution. (Or if anyone see the use for this and ask me nicely I can add it to my scripts Winking smile, if so please create an issue on GitHub). Using a skip list you can make sure that your core business applications do not get added to the ransomware extension list by mistake!

Have fun and keep safe!

Disclaimer: This solution is provided as is without any guarantees or warranty. This is something I have done in my spare time and share "as is". You will have to test this in a lab and verify that everything works before you deploy it in production. Use at your own risk.


About the author

Mattias Benninge

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments