Thursday, December 27, 2018

Proof of Concept - Using PowerShell And .Net To Monitor For Ransomware - Part I

It's a known thing that on a Windows server you can use the File System Resource Manager and set up 'File Groups' to monitor for ransomware. It does this by looking for files with extensions/names associated with known ransomware and then taking an action to alert an admin or even cut off network access for the possibly infected machine. If you're not familiar with the concept then check it out here:

What I wanted to try to do was replicate the same type of process in Windows 10 using PowerShell. I'm a bit of newb when it comes to PowerShell but I did a little research and discovered that PowerShell has access to .Net classes, meaning it can use the .Net Framework to perform certain functions. One of the classes is called IO.FileSystemWatcher and is well suited to our purpose.

This is still a little rough on the edges but it demonstrates how you can build a DIY PowerShell tool to monitor for ransomware and automatically take action to prevent the damage being done. As-is, the script does these things: 
  • Sets up a logfile with the name of the computer running the script.
  • Reads in the filename extensions from a text file. (I just copied the RAW list from into a TXT file.)
  • Sets the folder to be monitored. Sub-folders are monitored by default.
  • For each file name extension, registers two events that watch over the filesystem. The first detects when a file with certain name or extension is created and the second detects when a file is renamed.
  • Each event has associated actions that will occur when the event happens. By default this is just writing to the logfile and/or the console but there may be other things worth doing as well.
The script....

# Recommend you log to a network share that only the account running the script can access
Function LogWrite
   Param ([string]$logstring)
   Add-content $Logfile -value $logstring

# Script expects input format to be FILENAME.EXTENSION
# Wildcards can be used - Example: *.locky is valid input
$FilenamePatterns = get-content C:\RansomwareFilePatterns.txt

# Change top folder as desired - Subdirectories will be monitored
# Choose "C:\" if you want to monitor the whole drive
$folder = "C:\temp\"

Foreach ($Filename in $FilenamePatterns)
     $filter = "$Filename"                   
     $fsw = New-Object IO.FileSystemWatcher $folder, $filter -Property @{
     IncludeSubdirectories = $true      
     NotifyFilter = [IO.NotifyFilters]'FileName, LastWrite'}

     Register-ObjectEvent $fsw Created -SourceIdentifier "$Filename Created" -Action {
     $path = $Event.SourceEventArgs.FullPath
     $name = $Event.SourceEventArgs.Name
     $changeType = $Event.SourceEventArgs.ChangeType
     $timeStamp = $Event.TimeGenerated
     Write-Host "A file with a known ransomware extension '$path' was $changeType at $timeStamp"
     Logwrite "A file with a known ransomware extension '$path' was $changeType at $timeStamp"}

     Register-ObjectEvent $fsw Renamed -SourceIdentifier "$Filename Renamed" -Action {
     $path = $Event.SourceEventArgs.FullPath
     $name = $Event.SourceEventArgs.Name
     $changeType = $Event.SourceEventArgs.ChangeType
     $timeStamp = $Event.TimeGenerated
     Write-Host "A file was $changeType to '$path' at $timeStamp"
     Logwrite "A file was $changeType to '$path' at $timeStamp"}

Output will look something like this:
  •  A file with a known ransomware extension 'C:\temp\Document.WORMCRYPT0R' was Created at 12/27/2018 08:47:30
  • A file was Renamed to 'C:\temp\Test.ironhead' at 12/27/2018 08:48:57  
At the moment the script simply writes this to the console or adds it to the log file but there are other things that we can consider doing. It would be fairly simple to send an email via SMTP to alert admins which might be useful but if you really want to try to stop the ransomware from spreading then why not disable all the network interfaces like so...

get-netadapter | disable-netadapter -confirm:$false

Yes, this will no doubt result in an immediate helpdesk call but that's better than ransomware running rampant through your network, right?

One caveat though: Even though you can acquire a good list of known ransomware filenames/extensions there will still be FALSE POSITIVES. I have seen this happen in real life as 1TXT happens to be one of the file extensions associated with a ransomware and someone trying to save filename1.txt might accidentally type filename.1txt instead and suddenly their NICs are disabled by accident which both the end user and your techs will find incredibly annoying.

So some effort has to be made to weed out problematic file extensions and that is something that I will address the next time I try to look at this and maybe look at getting the list to automatically update.

Wednesday, November 21, 2018

Using PowerShell To Examine Event Logs

This is a PowerShell script that I cobbled together to retrieve specific System and Security Event Log entries useful in threat hunting from multiple servers. As written it focuses on four key events that could potentially be indicators of compromise.

  • Security Event Log 1102 - Security Event Log was cleared
  • System Event Log 7045 - New Service creation event
  • Security Event Log 4720 - New local user created
  • Scheduled Task Operational Log 106/200 - Scheduled Task was registered or executed

You can add or delete specific Event IDs as you like. You can set the script to run as a Scheduled Task once per day and it will pull the entries from the event logs for the past 24 hours (this also is adjustable) and put them in an easily readable HTML file with a dated filename. I haven't tested this on an extremely large number of servers. If you have hundreds or even thousands of servers then the script may take a long time to run. I would suggest testing small batches first.

The script...

Just update the script with the fileshare where you saved the script and make a text file called serverlist.txt with names of the servers you want to collect the logs from and place it in the same folder as the script.

Here is some sample output from a small test that I ran on some workstations:

You can see that the 7045 event is likely nothing to worry about as it looks like a service that was created when Office was installed. The 4720 event might be something to look into however.  Who created that account and why is something you'd want to find out.


I learned about how to query the event log using PowerShell from the excellent and this script is largely based on their work:

I learned about the important Windows events to monitor for threat hunting from this article by Jessica Payne: