So you want to be a SOC Analyst? Part 4

Now that we've detected attacks, let's learn to actively block an attack.

If you just landed here, be sure to check out the Intro to this series for backstory. You absolutely need to cover Part 1, Part 2, and Part 3 before you proceed here.

Blocking Attacks

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.

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

2. In your Sliver C2 shell on the victim, run the basic command we’re looking to detect and block.

   shell

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

      

3. In the new System shell, run the following command

   vssadmin delete shadows /all

   1. 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.

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

   whoami

   

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

   

6. 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.

   

   1. 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.

7. View the offending event in the Timeline to see the raw event that generated this detection.

   

   

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

   

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

   1. Add the following Response rule to the Respond section

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

   2. The “action: report” section simply fires off a Detection report to the “Detections” tab

   3. The “action: task” section is what is responsible for killing the parent process responsible with deny_tree for the vssadmin delete shadows /all command.

10. Save your rule with the following name: vss_deletion_kill_it

Let’s Block It!

Now return to your Sliver C2 session, and rerun the command and see what happens.

1. Run the command to delete volume shadows.

   vssadmin delete shadows /all

   1. The command should succeed, but the action of running the command is what will trigger our D&R rule

      

2. 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 whoami command

   whoami

   1. If our D&R rule worked successfully, the system shell will hang and fail to return anything from the whoami command, 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.

   2. 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.

3. Terminate your (now dead) system shell by pressing Ctrl + D

Keep Learning!

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:

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

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.