So you want to be a SOC Analyst? Part 3

Emulating an adversary for crafting detections

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 before you proceed here.

Let’s Get Adversarial

Let’s jump back into our Sliver C2 session launched in Part 2 and do some shady stuff that we would want to be able to detect.

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. Run the following commands within the Sliver session on your victim host

   1. First, we need to check our privileges to make sure we can perform privileged actions on the host

      getprivs

      1. A powerful privilege to check for is SeDebugPrivilege which opens the door for many things. If you’ve got that, we’re good. If you don’t you need to relaunch your C2 implant with administrative rights as we did in Part 2.

   2. Next, let’s do something adversaries love to do for stealing credentials on a system — dump the lsass.exe process from memory. Read more about this technique here.

      procdump -n lsass.exe -s lsass.dmp

      1. This will dump the remote process from memory, and save it locally on your Sliver C2 server. We are not going to further process the lsass dump, but I’ll leave it as an exercise for the reader if you want to try your hand at it.

      2. NOTE: This will fail if you did not launch your C2 payload with admin rights on the Windows system. If it still fails for an unknown reason (RPC error, etc), don’t fret, it likely still generated the telemetry we needed. Move on and see if you can still detect the attempt.

Now Let’s Detect It

1. Now that we’ve done something adversarial, let’s switch over to LimaCharlie to find the relevant telemetry

   1. Since lsass.exe is a known sensitive process often targeted by credential dumping tools, any good EDR will generate events for this.

   2. Drill into the Timeline of your Windows VM sensor and use the “Event Type Filters” to filter for “SENSITIVE_PROCESS_ACCESS” events.

      1. There will likely be many of these, but pick any one of them as there isn’t much else on this system that will be legitimately accessing lsass.

         

   3. Now that we know what the event looks like when credential access occurred, we have what we need to craft a detection & response (D&R) rule that would alert anytime this activity occurs.

      1. Click the button in the screenshot to begin building a detection rule based on this event.

         

      2. In the “Detect” section of the new rule, remove all contents and replace them with this

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

         1. We’re specifying that this detection should only look at SENSITIVE_PROCESS_ACCESS events where the victim or target process ends with lsass.exe

            1. For posterity let me state, this rule would be very noisy and need further tuning in a production environment, but for the purpose of this learning exercise, simple is better.

      3. In the “Respond” section of the new rule, remove all contents and replace them with this

         - action: report
           name: LSASS access

         1. We’re telling LimaCharlie to simply generate a detection “report” anytime this detection occurs. For more advanced response capabilities, check out the docs. We could ultimately tell this rule to do all sorts of things, like terminate the offending process chain, etc. Let’s keep it simple for now.

      4. Now let’s test our rule against the event we built it for. Lucky for us, LimaCharlie carried over that event it provides a quick and easy way to test the D&R logic.

         1. Click “Target Event” below the D&R rule you just wrote.

            

            1. Here you will see the raw event we observed in the timeline earlier.

         2. Scroll to the bottom of the raw event and click “Test Event” to see if our detection would work against this event.

            

            1. Notice that we have a “Match” and the D&R engine tells you exactly what it matched on.

         3. Scroll back up and click “Save Rule” and give it the name “LSASS Accessed” and be sure it is enabled.

            

Let’s Be Bad Again, Now with Detections!

1. Return to your Sliver server console, back into your C2 session, and rerun our same procdump command from the beginning of this post

   1. If at some point your C2 session dies, just relaunch your malware with the steps in Part 2

2. After rerunning the procdump command, go to the “Detections” tab on the LimaCharlie main left-side menu.

   1. If you are still in the context of your sensor, click “Back to Sensors” at the top of the menu, then you will see the “Detections” option.

      

   2. You’ve just detected a threat with your own detection signature! Expand a detection to see the raw event

      

   3. Notice you can also go straight to the timeline where this event occurred by clicking “View Event Timeline” from the Detection entry.

“You know my methods, Watson.”

You now have everything you need to endlessly explore and learn to your heart’s content. This is just the tip of the iceberg and I encourage you to continue exploring what else you can do with your C2 implants observing the telemetry, crafting detection rules, learning some hard lessons about false positives, and more.

I will likely follow up with some more advanced activities in the near future, but I hope this is a solid start for anyone wanting to get some experience.

Want to go deeper now? Check out Part 4 where we craft a rule that can actually take an action when a threat is detected.