Part 4 | SOC Analyst Home Labs

Part 4: Blocking Attacks

In the previous part of this lab we looked at how we can create a rule to alert us as a response to a threat. In this section of the lab we will go a bit further and create a rule to block an attack for us as soon as it's detected.

When it comes to writing blocking rules, it's important to first baseline the environment for false positives otherwise we could cause some real problems in the environment we are working with. Baselining is in itself one of the skillsets we must master as SOC analysts. In general it includes creating an alert-only detection rule, letting it run for a few days or weeks, tuning it to eliminate all false-positive detections of the rule, and then deploying the blocking version of the rule.

In the following section, we will create a blocking rule that would be effective against a ransomware attack by looking for a predictable action that ransomware tends to take which is the deletion of volume shadow copies. More information on deletion of Shadow Copies can be found here.

Here is a simple example of a basic command that would accomplish deleting the Shadow Copies. 

 vssadmin delete shadows /all


Even though this command might never be run in a healthy system, we still have to take into account and back-up software and other applications that might use this as part of their process. Therefore, baselining it is very important in a production environment.

We will work around this command for now as it is rarely a false positive and more often than not it signals a high threat activity.

Detecting a threat
First we will boot-up the Ubuntu Server and Windows VMs, we will go ahead with connecting to the server via SSH, and then into our C2 session just like we did in the previous parts of the lab.
If there are any issues starting the HTTP listener, reboot the Linux server and elevate privileges with the sudo su command once logged in via SSH.

  1. # Once in the C2 session, run the following commands 

     shell


    This command will start a new shell for us which we'll then use to attempt the deletion of shadow copies.
    When prompted with a warning that "This action is bad OPSEC", type "Y" and hit enter.


  2. # In the new Shell, run the following command 

     vssadmin delete shadows /all


    The output of this command is not important as there may not be Volume Shadow Copies on the VM to be deleted. Running the command alone is enough to generate the telemetry we are looking to detect and block.


  3. # Next, we will run the whoami command to verify we still have an active system Shell 

     whoami


  4. Now we will jump in LimaCharlie and check the detection tab to see if the default rules picked up our attempt to delete the Volume Shadow Copies.


  5. Once we find the event we are looking for, we can click on it and check all the references provided by LimaCharlie that can give us more information about the process.

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


  6. Next we can check the Timeline to see the raw event that generated this detection.


  7. Create a Detection & Response rule from this event.
    From this rule template we can begin crafting our response action that will take place when this activity is detected again.

    # Add the following lines to the Respond section of the rule and save it with the name vss_deletion_kill_it 

    - action: report
  name: vss_deletion_kill_it
- action: task
  command:
    - deny_tree
    - <>


    The "action: report" section creates a Detection report in the "Detections" tab.

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




Blocking an attack
First we'll go back into the Sliver C2 sessio, then we'll run the same command and observe the outcome.

  1. # Run the command to delete the Shadow Copies Volumes. 

     vssadmin delete shadows /all


  2. The command will execute but the process of running the command is what will trigger our detection rule and kill the parent process.


  3. # We can check if the parent process (which in this case is the shell), was terminated by trying to run another command. 

     whoami


If our rule worked successfully, the Shell process that we used to run the command earlier will already be terminated.

To further test the D&R rule, we can download and execute Florian's ransomware simulator.
The simulator attempts to take the following actions:

  1. Copies itself to word.exe
  2. Spawns the new word.exe to simulate a micro-enabled document execution.
  3. Deletes volume shadow copies.
  4. Creates 10,000 files.
  5. Encrypts 10,000 files.


One way we can improve the rule is by tweaking it in such way that it will use more intelligent ways of matchmaking.
The way it is built now, it will not detect the vssadmin delete shadows /all command if an extra space is added somewhere.
Instead, we can use the "contains" operator which will look for these command line arguments. 

 - 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'
In the next section of this lab we can look at tuning false positives.



Resources:

So you want to be a SOC Analyst? Part 4