As an incident responder, we all know that ransomware cases can be overly damning to a victim and an organization, so reacting to them as quick as possible is crucial. Since protections in place, such as AntiVirus are constantly in a rat race, that is usually one step behind, it puts everyone at a disadvantage. One thing you can say about ransomware is that it isn't hard to spot a successful infection. Forensically speaking, it is overly noisy and riddles the host with artifacts of its execution.
Knowing that there are numerous artifacts and infection actions you can bank on, things such as file overwrites, an infection order, known extensions targeted and potentially persistence, what would happen if you reacted on those events specifically and not the malware itself. If we reacted on these events instead of looking for a stage1 or stage2 drop, the majority of ransomware infections could be delayed, buying back some time for the victim and incident responder to react and hopefully stop the infection.
Take for example the standard scenario where the user receives a malicious email and then unknowingly acts on the attachment, allowing the ransomware to start the initial stages of infections. Once all the pieces are in play and the ransomware starts the encryption process, it will usually target files of a known type, files such as office docs, audio files, video files, images and in some cases script file extensions. Besides targeting files of a specific type, it will also start the encryption process by beginning the process down the root of C:\ or beginning by encrypting the files within the running user's profile. Once the local drive has been encrypted, the malware can then move on to targeting mapped drives and begin encrypting the mounted share's content.
So knowing these elements of the attack, we wondered if we could setup a canary file or a canary directory and then automatically respond when one of these files are written to, aka overwritten by encryption. Of course, we want to respond in the safest manner possible, so we would need to be careful about creating these canaries. Knowing that multiple tools and programs comb through your files regularly, you want to ensure your permissions are right.
- Notify a responsible party via email
- This is likely the lowest level of reaction we thought was appropriate. It does nothing for protection, just simply alerts someone.
- Disconnect all mapped drives
- This action will at least protect any mapped shares or devices, containing the infection to the single endpoint.
- Slow down the malware and attempt to kill the process
- Later in the post we will illustrate some interesting techniques that can be performed to slow ransomware down. Some of these techniques are fairly aggressive and could cause problems if triggered by a false positive.
Below is a short Powershell example that could be used as a base to monitor for canary file changes. The script creates a single canary file, enables monitoring the file for LastWrite changes and responds when the file is written to by sending an email and unmounting any mapped drives.
This is a passive measure aimed at detection and containment. This is a very non-invasive way for companies to confine outbreaks of ransomware within a particular endpoint and prevent network resources from being affected. One of the big down sides of this example is that we aren't actually disrupting the course of the malware and we still have a mess to deal with on the local endpoint.
Below is a C# example that works in conjunction with Object Auditing and Audit Rules. When Object Auditing is enabled to audit Write Data, we can monitor for those security events and then react. Most applications installed or resident on the system will potentially read or access these file canaries, so you want to ignore those read events and only focus on the writing of the file. When you create your canary files you want to enable Create Files/Write Data, Create Folders/Append Data NTFS permissions. Object Auditing can be enabled in your Local Security policy or via GPO or via .Net but given most likely use a Global Policy it may not be worthy of including in your script. See Example 3 for some code examples for the Audit Rules.
In this example, the script will monitor the event logs for Security-Auditing events that contain the filename or directory name you picked. Since it will only trigger when data is written to the canary file, this example script will then kill the process that wrote to the canary. Depending on your needs you can combine actions, so you could also unmount any mapped shares and send an email, or whatever action you feel appropriate.
Below is a Powershell example that sets up your Audit Rules but for a canary directory and all the files within that folder. In this example, the canary directory is called '$', more on why we named it '$' later.
The first few examples create file canaries in our honeypot folder to give us the time to find, alert on, remove mappings and or kill the malicious process. But depending on where you place your canary folder or files and what you name them, the malware might be able to encrypt hundreds files before it hits your canary files. Most ransomware uses relatively simple cryptographic methods that computationally take almost no time at all and present us with a hefty challenge on reacting quickly. We needed a way to keep the malware busy doing something harmless, before it got to our actually files.
So why did Example 3 use '$' as the canary directory? Say you create a mountpoint called '$$'.
Powershell example to create a '$$' mount point to C:
So what happens when you browse to that directory? You'll quickly notice you hit a recursive loop.
How does this actually help? If the ransomware iterates from the top of the volume, this seemingly infinite loop of folders infinitely increases the "distance" to get the files we want to protect.
Let's take a look at the difference in ProcMon.
Here is an example of Teslacrypt enumerating through a Windows VM without a sinkhole:
So what does it look like when Teslacrypt hits our mount point.
In order to crack that nut, you could create multiple sinkholes, for example putting an additional sinkhole in a user profile.
If the ransomware hits the Users\username\Documents\$GoDirectlyToJail "folder", it will get sent back to the top of the volume where it will be sinkholed by the C:\$$ "folder".
The example below uses the file canaries and the sinkholes concepts together. The script creates plain text canary files using the extension list, creates the sinkhole mount point. This script will force the ransomware into a loop, so it perpetually encrypts the same canary files over and over again.
On Windows x86 systems, it is trivial to review the open handles and find the process that has opened the canary file. Using something like file handles makes it a hair easier than solely relying on Object Auditing and Event Log monitoring. Below contains a Python script that will look at the open handles and kill the pid associated with the open handle to the canary directory. It should be noted that this by itself would trigger on any open handle, so read or access changes would trigger this, so you may want to only use this as an option when you have been alerted to an event via file monitoring or Event Log escalations.
Using the handles solution is great for Windows x86 systems but given those aren't in use as much anymore. This method falls flat on modern PCs, due to Microsoft's Driver signing policy, starting with 64-bit versions of Windows Vista and later. For this reason, utilities that display open file handles like Handle, Process Hacker, OpenedFilesView load their own signed driver that is used to extract information from Windows Kernel and if you prefer you can utilize the output of these tools. There are a handful of MS SysInternals Handles.exe scripts that read in handles.exe's output.
Lastly, here is yet another show stopper action that can be taken after a ransomware trigger. Unfortunately, this one is much more damning than the others and not really mean to be a potential solution, just something fun to experiment with.
The batch script below creates a fork bomb which consumes all resources bringing your system to a halt, thus halting the ransomware.
The %~dp0%~n0%~x0 is fancy batchfu for the complete file path of the batch script that is running. Every time this runs it creates another instance of itself and then runs another instance and pipes that output into yet another. This consumes all available memory leaving nothing for the malware or any other process to use. While this was able to stop Teslacrypt and others after approximately encrypting 5 canary files but like we mentioned this might not be the most practical idea because it does introduce a vector for Denial of Service.
|Screenshot of Fork Bomb Result|