> For the complete documentation index, see [llms.txt](https://osamaa.gitbook.io/osama_homepage/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://osamaa.gitbook.io/osama_homepage/cybersecurity-soc-analyst-labs/home-lab-c2-detection-ransomware-defense-and-yara-automation/part-4-blocking-ransomware.md).
# 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:
```shell
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
shell
```
3. Confirm when prompted: *“This action is bad OPSEC, are you an adult?”* → Type `Y` and press Enter.\
4. Execute the following:
```shell
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.
5. Run:
```shell
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**
```yaml
response:
- action: report
name: vss_deletion_kill_it
- action: task
command:
- deny_tree
- <>
```
* 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:
```shell
vssadmin delete shadows /all
```
3. 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**
