sparkyzcodez / fsrm-anti-ransomware Goto Github PK

Trying to install on a Win Server 2012 R2 box, python 3.8 with my limited technical skills. When I run EverythingSearchForRansomware.py in Powershell, I get a File Not Found Error, could not find module 'Everything64.dll' error. The dll file is in the same folder as all of the other files, any suggestion on how to have it load the dll? Permissions problem maybe? I see they made some changes in Python 3.8 regarding ctype dll loading?

Just thinking out loud. If the honey pots are passive and they allow unlimited creation of "bad" files then it could lead to a full disk. In effect, it could lead to a DoS. Let's consider combining disk usage quotas with honey pot file screening since we already have FSRM running happily.

I know this is more of a PowerShell bug, but thought I should bring it to your attention in case it could be fixed somehow. Some of my honeypot directory names begin with a period to also hide them from Macs in our mixed Windows/Mac environment.
Line 494 of FSRM-Anti-ransomware.ps1:
ForEach-Object -Process {Get-ChildItem -Path $_.Path -Force -ErrorAction SilentlyContinue -Directory -Filter $HoneyPotDirectoryNamePattern} |
When setting $HoneyPotDirectoryNamePattern to ??Directory, it does not match ones that begin with a period.
Example in straight PS:

PS C:\share2> Get-ChildItem -Path c:\share2 -Force -ErrorAction SilentlyContinue -Directory -Filter ??Directory??

    Directory: C:\share2

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       12/13/2019   2:51 PM                $$Directory 3
d-----       12/13/2019   2:58 PM                @@Directory 6
d-----       12/13/2019   2:51 PM                _!Directory 4
d-----       12/13/2019   2:53 PM                __Directory 5

Changing the filter to include any length beginning character with an asterisk will then show the missing directories

PS C:\share2> Get-ChildItem -Path c:\share2 -Force -ErrorAction SilentlyContinue -Directory -Filter *Directory??

    Directory: C:\share2

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       12/13/2019   2:51 PM                $$Directory 3
d-----       12/13/2019   2:17 PM                .!Directory 1
d-----       12/13/2019   2:19 PM                .@Directory 7
d-----       12/13/2019   2:19 PM                ._Directory 2
d-----       12/13/2019   2:58 PM                @@Directory 6
d-----       12/13/2019   2:51 PM                _!Directory 4
d-----       12/13/2019   2:53 PM                __Directory 5

My workaround right now is to use *VerySpecificDirectoryName as $HoneyPotDirectoryNamePattern

Great program, thank you! After running EverythingSearchForRansomware.py, I have a list of files that are ok even though they have one of the filtered endings, how do I take that list and whitelist those files? I can add the file names to the most recent json file under exceptions, but it appears to only accept the file name, not the full path. For example, this is a legit file:
C:\Program Files\Python38\Lib\test\clinic.test

Can I add an exception for that specific file at that path so that it's not filtered, or do I have to just whitelist "clinic.test" regardless of which directory it's in? I have about 400 matches. Or does the program just ignore existing files once they are already there, and won't allow any new *.test files to be created?

Basically, do I need to do something with the results of EverythingSearchForRansomware if there are legit files found under filters-fsrmMatched?

The filespec *.NEMTY<*>_ snuck in to some of my older JSON files. At first I was afraid the AntiransomwareFiltersMerge.py app glitched, but no. This is a definition that probably leaked through Experiant's filespec definitions and was subsequently removed.

The problem for us is that our JSON is lossless. If someone else stops publishing a file spec it will still be in our list.

Here's what I did to allow the scripts and FSRM to keep working without interruption. I put a filter validation routine into the FSRM-Anti-ransomware.ps1 script. Every filter filespec is now validated by the OS using the Test-Path PowerShell command. If the OS file system specs change then the criteria used by Test-Path changes dynamically as well. I'll extend this functionality to the exceptions in the near future too, but for now it's on you to make sure your exceptions are legal.

Right now the script excludes any failed file specs and simply passes the successfully validated filespecs on to FSRM. The script also pokes a warning with an EventID of 1007 into the OS event logs. The warning lists all the invalid file specs too so you won't have to guess which ones are broken.

I also made a simple stand-alone PowerShell script that will validate the filters in your JSON. You'll find it in the ancillary folder in this project.

We still need to tweak our JSON data files otherwise the broken NEMTY definition stays forever.
Three options:

1. Delete the definition and never look back. I think this is a good choice this time. Those angle brackets look like a mistake and it also looks like Experiant updated the filespec with the correct version.

2. Use AntiransomwareFiltersMerge.py with the -r switch to reload the extended data from the Experiant source. This nukes all your custom entries from the old JSON file so be careful with this one. If you want to start you data over from the beginning then do this one.

3. Replace any questionable characters with a ? wildcard. This is the most conservative option. You don't loose the definition and it still matches actual files pretty well. I'm not using this option in this case, but there is another broken filter that has a new line in it. I'll sub a question mark for that until I know more facts.

Hello,

I am checking out this project after realizing the Experiant script is out-of-date and that yours is much more full-featured.

However, I think that a proper Quick-Start / Documentation would be awesome and make this script easier to use. I am sure you are busy. It just seems like a lot of duplicated effort for everyone new who wants to use the script to have to parse the code themselves.

Anyway, I am only posting this here because I could not find your email and GitHub has disabled messages. If you would be willing to supply notes and check my work, I would be willing to write a readme/ quick start.

Let me know your thoughts. Thanks very much for the useful tool!

I'm really not sure what to make of this one but it warrants further poking around the edges to try and duplicate.

User NT AUTHORITY\SYSTEM attempted to save D:\asdf asdf\Updates\ServicePack\asdf\asdf\CrystalWebViewer\ErrorPages\ErrorPages.Master to D:\ on the asdfasdfqwer server.

When testing the the outputted DenyPermissionsEventParsing.PS1 script from $DenyPermissionsTriggeredScript, I noticed that it doesn't kill an active file copy session. It seems the ACL on the file share is cached and only re-read when a new session is opened.

Occasionally when testing a file copy of a group of 100 1mb-files to a Honeypot directory, it would allow me to copy all the files before my access was denied.

Adding this to the DenyPermissionsEventParsing.PS1 script successfully kills the file transfers more quickly and reliably.
Get-SmbSession -ClientUserName $username | Close-SmbSession -Confirm:$false -force

Referencing the development notes... disabling the user's account in Active Directory could take longer to propagate between DCs, especially in a larger AD environment.