Creating Robust D&R Rule to Block Ransomware

First and foremost, I would like to thank Gerald Auger from Simply Cyber for creating an incredibly informative YouTube video featuring SOC Expert Eric Capuano. It was through Auger’s video that I discovered Eric’s remarkable blog post titled “So You Want to Be a SOC Analyst?” I am truly grateful for their valuable insights and guidance, as they played a significant role in helping me build this lab. Here’s the link if you’d rather follow https://blog.ecapuano.com/p/so-you-want-to-be-a-soc-analyst-intro

In the previous blog we learned to generated our own detection rules to detect a moment threat occurs on our Windows system. What if, we could block the threat as well?

First, it’s critical that we create a proper baseline environment for false positvies or it could prove to be overwhelming. It’s a essential for any SOC analyst to master. In a real world environment what this process looks like we create a alert only rule, letting it run for days or even weeks, tuning it to eliminate false positves, and eventually deploying the complete blocking version of that rule.

In today’s lab we will be creating a rule that would be very effective at disrupting a ransomware attack by looking for a predictable action that ransomware tends to take… deletion of volume shadow copies.

Why this Rule?

Volume Shadow Copies provides a very convenient way to restore individual files or even entire file systems to a previous state which makes it a very attractive option for recovering from a ransomware attack. For this very reason it’s become very predictable the signs of a impending ransomware attack is when attackers targerthe deletion of volume shadow copies.

A basic command that could execute this ( there are other methods ) :

vssadmin delete shadows /all

This command is not one that will be run often (if ever) in stable environments but baselining is crucial because some backup software or other apps may do suspicious stuff like this on occasion.

That’s why we want to be on high alert and have this as our lab blocking rule: low false positives prevalence, high threat activity.

Let’s Detect It!

Fire up your Linux and Windows VMs we previously setup and get back into a Sliver C2 shell.

1. Get back onto an SSH session on the Linux VM, and drop into a C2 session on your victim.
   1. Retrace your steps from Part 2 if need be.
   2. If you have issues reestablishing your HTTP listener, try rebooting your Ubuntu system

In our Sliver C2 shell run the basic command we’re looking to detect and block.

shell

When prompted with “This action is bad OPSEC, are you an adult?” type Y and hit enter.

In the new system shell, run the following command:

vssadmin delete shadows /all

The output is not important because there may not be Volume Shadow Copies on our VM to be deleted, but running the command is enough to generate the telemetry needed. 

For us "no items found that satisfy the query. That's ok. 

Run the whoami command to verify we still have an active system shell

whoami

Browse on over to LimaCharlie’s detection tab to see if the default Sigma rules picked up our activity.

Click to expand the detection and examine all the metadata contained within just this detection!

One of the cool things about Sigma rules they are enriched with references to help you understand why the detection exists in the first place.

One of the reference URLs contains a YARA signature written by Florian Roth that contains a bunch more command lines we’d want to consider in a new detection rule.

View this attack on the event timeline to visualize the raw event detection.

Craft a Detection & Response (D&R) rule form this event.

From this D&R rule template, we can begin crafting our response action that will execute when this activity is observed.

Add the following Response rule to the Respond section:

- action: report
  name: vss_deletion_kill_it
- action: task
  command:
    - deny_tree
    - <<routing/parent>>

Line 1: "action report" simply fires off a detection report to the "Detections" tab.

Line 3: "action task" is what is responsible for killing the parent process responsible with "deny_tree" for the vsadmin delete shadows /all command. 

Save your rule and name it: vss_deletion_kill_it

Let’s Block It!

Let’s return to our Sliver C2 session and rerun the command and see what occurs.

vssadmin delete shadows /all

The command should execute, but the action of running the command will trigger our D&R rule. 

Now, to test if our D&R rule properly terminated the parent process, check to see if you still have an active system shell by rerunning:

whoami

If our D&R rule worked sucessfully, the system shell will fail to return anything because the parent process was terminated!

Note, you also may receive output such as “Shell Exited” — this is functionally the same thing as it hanging and providing no output.

This effective in real life ransomware incidents, the parent process is likely the ransomware payload or lateral movement tool would be stopped in its tracks.

Terminate your dead system by using Ctrl + D to stop

Make sure to keep learning!

Let’s put our new D&R rule to the test! Download the obfuscated version of Florian’s ransomware simulator on your Windows VM

Scroll down to the bottom and download “quickbuck.exe”

Note: Windows is still going to try and block the download from starting what I did was kept trying and decided to download it on brave browser instead. It still blocked it but after the third try it let me download it. There might be a simpler way to bypass it but this is what worked for me 🙂

Once downloaded what I did was run the application but windows would not let me. Very intelligent Defender is I just put more “info” and clicked “run anyway.” It prompted me to run cmd.exe on the command line. So what I did was execute our C2 payload all over again from part 2 and ran shell from part 3. From there I executed the ransomware simulator as shown on Github.

1. Copies itself to WORD.exe
2. Spawns the new WORD.exe to simulate a macro-enabled document execution (detectable with builtin Sigma rules!)
3. Deletes volume shadow copies (this is where we catch and kill it!)
4. Creates 10,000 files
5. Encrypts 10,000 files

Let’s go to LimaCharlie and check out our Detections tab and see what events it picked up.

We want to search for the event that has the “Shadow copies Deletion”.

We will want to create a more robust D&R rule for our ‘deletion of shadow copies’ response.

- op: is
    path: event/FILE_PATH
    value: C:\Windows\system32\vssadmin.exe
  - op: contains
    path: event/COMMAND_LINE
    value: 'delete'
  - op: contains
    path: event/COMMAND_LINE
    value: 'shadows'
  - op: contains
    path: event/COMMAND_LINE
    value: '/all'

Why we considered tweaking our original D&R rule is because using more intelligent ways of matching on the command line instead of matching on a literal string of vssadmin delete shadows /all. One weakness of the rule the way its written is that adding a simple space somewhere breaks our detection. For this reason it’s not as robust and can easily be circumvented , this is why we use the  contains operator to look for these command line arguments instead to have each string be detected instead to cast a wider net on the search string vssadmin delete shadows /all.

Let’s run our ransomware simulator again and see if our D&R rule blocks our attempt!

LETSSSS GOOOO!!! I hope your as pumped as I am! 😀 we just blocked our first ransomware attempt!!

Come join me in Part 5! Let’s continue learning, we shall be learning to finally tune false positives because not every alert is malicious! Cheers, everybody remember to stay legendary my fellow Hoodies!