Blocking Ransomware for free with Honeypots

Blocking Ransomware for free with Honeypots


A common question we get asked is “I heard from so-and-so from Company X that they got Ransomware and had to pay out. What can we do to make sure this doesn’t happen to us?”.

Well, firstly, if Company X knew what a backup was, they wouldn’t have had to pay – so , you know… that. Aside from backups, however, what can we do to stop Ransomware spreading in the first place? Well, for the small business, without a real IT budget, your options are not great. You can buy some snakeoil antivirus software that is 100% guaranteed to do absolutely nothing may not help, when you get attacked, from any number of vendors. Just expect to see a message along the lines of “malware detected. Failed to delete or quarantine” in your future, if you do.

So that aside, there’s a few things you can do.

Firstly, if you’re on Windows 10 build 1709 or above, please go and investigate Protected Folders. This is an excellent feature now in Windows and it’s worth your time. But this article isn’t a post about that. I’ll do something on that, later, once I have a better appreciation for how to mass automate it.

Secondly, you should be limiting what people can modify, to limit damage. But doing that requires patience and buy in from management. Also, not using network shares is ideal but.. same problem. Also, that costs money for Sharepoint, or whatever to be set up right.

Today we’re going to look at how to automatically kick infected users off your network, really fast, by using honey pots. The basic idea is this: when a user gets ransomware on their PC, the malware is going to start encrypting your shared folders, and that’s bad news for you.

Introducing Windows File Server Resource Manager (FSRM). Using this, we can start to build out rules that will result in users having their share access cut. There’s lots of ways to do this: such as when you see a file with a specific extension created (like “.locked” or something) but that’s “whack-a-mole” and you can’t keep up with the extensions (which could be random). You can lock out users who change too many files in a time frame but I’ve found some applications blow that rule with their odd cache file behaviour. So we’re going to use honeypots, instead.

For those of you who don’t know, honeypots are basically deliberately attractive targets that you set up in the “hope” (if that’s the right word) they will be attacked, so you know something is going on. We’re going to do this by putting a folder in the root of a share called something like “_do_not_delete” or the like.

Hint: you probably want to tell your staff not to touch this folder, too. Coz it’s going to hurt them, if they do.

Let’s install FSRM.

Fortunately, this is easy. Assuming Windows 2012 and up, open powershell and type:

Install-WindowsFeature –Name FS-Resource-Manager –IncludeManagementTools

If you’re still on Windows 2008R2, you can use:

Add-WindowsFeature FS-FileServer,FS-Resource-Manager

but it’s past time to upgrade.

Then, probably, reboot. Because Windows.

Make a Honeypot

Go to each network share and make a file called “_do_not_delete.txt”. or a folder or something – but start it with a special character. Why? So it’s alphabetically first. Doesn’t really matter what it’s called; just make sure it’s alphabetically first. This is so ransomware is more likely to attack it first (not guaranteed but hey – we’re spending $0 here).

Make a powershell file to kill people

Sounds severe, doesn’t it? It’s just two lines. I called mine RansomwareGoodnight.ps1

param([string] $DomainUser)
Block-SmbShareAccess -Name SHARENAME -account $DomainUser -force

Now make a batch file to call it:

@echo off
powershell.exe -ExecutionPolicy Bypass -File "C:\FSRMScripts\RansomwareGoodnight.ps1" -DomainUser %1

You can manually test this from cmd:

Now check the share itself and you will see test.gumby is denied.

Set FSRM Rules

Start by opening FSRM. It’s under Server Manager > Tools in 2012 up.

Now we want to make a new file group. Set it up like so:

Now go and set up a new file screen template:

Set up email alerts (you will need to set the options on FSRM to define the email server, too – right click on FSRM (local) and pick options.

Now call out command:


Now we just need to apply this. Go to File Screens and pick new. Set the directory you want it on. This should match the share name in your powershell scrip (SHARENAME) in the powershell above.


Now just go back to your share and try and rename _do_not_touch.txt to _do_not_touch.locked (or copy the file, etc.). It should be curtains for your account’s access to that share.


Ok, so that’s it. A few quick little steps and you can block people with Ransomware from infecting your network.

You can check out how to use DNS Query Logging to extend what we’ve done here, to black hole the domain this malware came from, in this blog entry:

About the Author


RodneyI'm a veteran of way too many years of IT (although I still love it) and I currently head up the techincal work over at Host One (major sponsor of this site), where I'm also a partner. Feel free to ask me anything about Cloud Computing and I'll try to be helpful, in a non-salesy kind of way.View all posts by Rodney →

  1. RodneyRodney11-16-2017

    Going to update this post soon with a few modifications. I’ve modified the powershell to now track the last DNS queries made by the infected PC on the network, so we can work out the location the malware came from and firewall it.

  2. amam08-18-2018

    This is too good. I haven’t seen this use of FSRM before. The DNS query idea is great too.

    Do you have any other mitigation strategies?

    • RodneyRodney08-20-2018

      There’s also an article on script block logging, to find out what malware did and get notifications when script or C# based malware runs and on constrained language mode / applocker for powershell.

      I plan to put a few more up, when I get time.

Leave a Reply

Time limit is exhausted. Please reload CAPTCHA.