Part 3 Process Detection and Alert Creation

In this section of the lab, we will start with some more "Red-Team" to generate some more noise in LimaCharlie and then we'll proceed with creating a rule around that event.

C2 and Memory Dumping

First we'll jump back into our C2 session from the Linux VM using an SSH session like we did in part 2 of the lab.

1. # Check for privileges
   

    privs 




2. # Use the following command to dump the lsass.exe process in the memory and save it locally on the Sliver C2 server.
   
   

    procdump -n lsass.exe -s lsass.dpm 

   
   
   More information about lsass.exe and preventing credential dumping attacks can be found in this article
   
   As a side-task, we could try to further process the lsass dump with the help of this article, but it will not be covered in this part of the lab.
   
   This step will fail if we didn't execute the C2 implant from an Administrative Powershell. If it still fails after we launch the implant via the Administrative Powershell, we can move on and we'll still be able to detect the attempt.

Detecting processes in LimaCharlie

Lsass.exe is a known sensitive process commonly targeted by credential dumping tools. Any reputable EDR would generate events for this.

1. Go into Timeline of the Windows VM sensor and use the filter to search for "SENSITIVE_PROCESS_ACCESS" events.
   
   Since the only mentions of lsass.exe in the processes right now is our attempt to dump the process in memory, we can pick any one of the results and click on to get further information.



2. Now we know what the event looks like when credential access occurred. We can now create a detection & response (D&R) rule that would alert us every time this activity occurs.



3. Click the button on the top right corner as shown in the picture to start building a detection rule based on this event.



4. # In the "Detect" section of the rule we are creating, delete all contents and paste in the following lines.
   
   

   event: SENSITIVE_PROCESS_ACCESS
   op: ends with
   path: event/*/TARGET/FILE_PATH
   value: lsass.exe
   

   
   
   The lines above specify that the detection rule should only look for SENSITIVE_PROCESS_ACCESS events where the victim or target process ends with lsass.exe.
   This rule would be very "noisy" the way it is set up now and further tuning would be required for a production-type environment. For the purpose of this learning exercise, we can leave it like this for now.



5. # In the "Respond" section of the rule we are creating, delete all contents and paste in the following lines.
   
   

   - action: report
     name: LSASS access
   

   
   
   The above lines are telling LimaCharlie to generate a detection "report" anytime this detection occurs. Information on more advanced response capabilities can be found in this article.
   
   Ultimately, there are many different actions we could tell LimaCharlie to respond with, depending on each case, severity and reason for the event occurring in the first place. More information on this can be found here.

Now we can go ahead and test the detection & response rule we just created.



1. First we need to click on the "Target Event" tab.
   Here we can see the raw event we observed in the timeline earlier.



2. We need to scroll to the bottom of the raw event and we'll click on the option for "Test Event".
   If we get a "Match" on the rule we just tested it means that the detection rule is created correctly.



3. Lastly, we'll scroll back up, click on the option to "Save Rule" and name it "LSASS Accessed" and we want to make sure it's enabled.

Seeing our Detection & Response rule in action

First, we'll follow the steps from earlier and jump back into the Sliver server and back into our C2 session and run the same procdump command.

After running the procdump command, we will jump back into LimaCharlie's web interface and click on the "Detections" tab from the left-side panel.

There should be our detected event with our own detection signature.
We can click on the detected instance to see the raw event.

Lastly, if we were to further analyze that event, we can click on the option "View Event Timeline" from the Detection entry which will take us straight to the event in the timeline where we can see what other processes were run and what connections were initiated or were active around the time the event took place.

This is the end of Part 3 of this lab. So far we have everything we need to start playing around with detection & response rules. As this exercise was only scratching the surface of what is truly possible, it is strongly recommended to go deeper into the various options for rules-creation, detecting truly "dangerous" processes and familiarizing ourselves with false-positives.



Resources:

So you want to be a SOC Analyst? Part 3