Part 4 - Blocking Ransomware

Blocking ransomware by detecting and stopping harmful commands in LimaCharlie. This guide shows how to prevent attackers from deleting backups.

Blocking Attacks in LimaCharlie

Introduction

In Part 3, we explored crafting detection rules to identify threats in real time. However, detecting threats is only half the battle—blocking them before they cause harm is the next crucial step.

Blocking attacks requires careful baselining to avoid false positives. A best practice is to first run a detection rule in alert-only mode, monitor it for a period, eliminate false positives, and then deploy a blocking version.

Here we will create a rule that effectively disrupts a ransomware attack by detecting and blocking the deletion of Volume Shadow Copies.

---

Why This Rule?

Volume Shadow Copies allow restoration of files or entire file systems, making them a crucial recovery tool against ransomware. Attackers use this to remove backups before encrypting files.

A common command used for this action:

vssadmin delete shadows /all

This command is rarely executed in a healthy environment, making it a low false-positive, high-value detection candidate.

---

Detecting Volume Shadow Copy Deletion

Step 1: Execute the Malicious Command

1. Open an SSH session to the Linux VM and start a Sliver C2 shell on the victim.

2. Run:

   shell

3. Confirm when prompted: “This action is bad OPSEC, are you an adult?” → Type Y and press Enter.

   
4. Execute the following:

   vssadmin delete shadows /all
   
   

- The output doesn't matter; whether or not Volume Shadow Copies exist on the VM, running the command is enough to generate the required telemetry.

1. Run:

whoami

This confirms if the session is still active.

Step 2: Check for Detection

1. Open LimaCharlie’s Detection Tab.

2. Look for any Sigma rule detections.

   
3. Expand the detection to review its metadata. Sigma rules include references that help explain why the detection was triggered.

   
4. View the raw event in the Timeline.

   

---

Crafting the Detection & Response (D&R) Rule

Using the detected event, we will create a rule to detect and terminate the parent process responsible for executing the deletion command.

Response Action

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

• The action: report section generates a detection report in the "Detections" tab.

• The action: task section uses deny_tree to terminate the parent process that executed the vssadmin delete shadows /all command.

Save this rule as vss_deletion_kill_it.

---

Testing the Blocking Rule

1. Return to the Sliver C2 session.

2. Run the deletion command again:

   vssadmin delete shadows /all

1. Run:

whoami

If the rule worked, the shell will hang or exit, confirming the process was terminated.

To manually exit the shell, press Ctrl + D. Notice :

Your rule stopped the process that was running your command.

When you ran vssadmin delete shadows /all, LimaCharlie detected it and killed the process that started your shell. Since your shell depended on that process, it also got closed.

So when you tried whoami, the shell was already dead, which is why you saw "Shell exited."

---

Next Steps: Strengthening the Rule