Discover more from Eric’s Substack
So you want to be a SOC Analyst? Part 4
Now that we've detected attacks, let's learn to actively block an attack.
So in Part 3 we learned that we can craft our own detection rules to identify the moment a threat unfolds on our Windows system, but wouldn’t it be great if we could block the threat rather than just generate an alert?
Now let me first say, it’s critical that anytime you are writing a blocking rule that you properly baseline the environment for false positives else you could possibly cause some real problems in your environment. Baselining is another skillset any SOC analyst must master, and it can take time and diligence to do it right. Generally what this looks like is crafting an alert-only detection rule, letting it run for days or weeks, tuning it to eliminate all false positives, and then deploying the blocking version of that rule.
Let’s skip to the fun part by crafting 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 provide a convenient way to restore individual files or even an entire file system to a previous state which makes it a very attractive option for recovering from a ransomware attack. For this reason, it’s become very predictable that one of the first signs of an impending ransomware attack is the deletion of volume shadow copies.
A basic command that would accomplish this (there are also other ways, but let’s keep it simple)
vssadmin delete shadows /all
This command is not one that will be run often (if ever) in healthy environments (but baselining is still crucial as some back ups software and other applications may do funny stuff like this on occasion).
So we now have a prime candidate for a blocking rule: low false positive 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.
Get back onto an SSH session on the Linux VM, and drop into a C2 session on your victim.
Retrace your steps from Part 2 if need be.
If you have issues reestablishing your HTTP listener, try rebooting your Ubuntu system
In your Sliver C2 shell on the victim, run the basic command we’re looking to detect and block.
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 as there may or not be Volume Shadow Copies available on the VM to be deleted, but running the command is sufficient to generate the telemetry we need.
Run the whoami command to verify we still have an active system shell
Browse over to LimaCharlie’s detection tab to see if default Sigma rules picked up on our shenanigans.
Click to expand the detection and examine all of the metadata contained within the detection itself. One of the great things about Sigma rules is 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 several more possible command lines that we’d want to consider in a very robust detection rule.
View the offending event in the Timeline to see the raw event that generated this detection.
Craft a Detection & Response (D&R) rule from this event
From this D&R rule template, we can begin crafting our response action that will take place 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>>
The “action: report” section simply fires off a Detection report to the “Detections” tab
Save your rule with the following name:
Let’s Block It!
Now return to your Sliver C2 session, and rerun the command and see what happens.
Run the command to delete volume shadows.
vssadmin delete shadows /all
The command should succeed, but the action of running the command is what 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 the
If our D&R rule worked successfully, the system shell will hang and fail to return anything from the
whoamicommand, because the parent process was terminated.
This is effective because in a real ransomware scenario, the parent process is likely the ransomware payload or lateral movement tool that would be terminated in this case.
Terminate your (now dead) system shell by pressing
Ctrl + D
Want to put your new D&R rule to the test? Download and execute Florian’s ransomware simulator and see how it holds up against your new D&R rule. This tool runs the following actions:
Copies itself to WORD.exe
Spawns the new WORD.exe to simulate a macro-enabled document execution (detectable with builtin Sigma rules!)
Deletes volume shadow copies (this is where we catch and kill it!)
Creates 10,000 files
Encrypts 10,000 files
Continue tweaking your rule to allow it to account for the other ways volume shadows can be deleted, as well as other ways to make the rule more robust.
One tweak you’d certainly want to consider is 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, I am a big fan of using the
contains operator to look for these command line arguments instead.
- 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'
Continue building upon what you’ve learned! To continue this journey, check out Part 5 - Tuning false positives.