Operating a SOC Analyst Home Lab
… “Find Evil — Know Normal.” (SANS DFIR slogan)
The cybersecurity industry is vast and entails many specialized topics. No one person can learn or know everything and the breadth of concepts to learn can seem overwhelming. Admittedly, I spent a considerable amount of time looking at the different types of cybersecurity career paths out there.
Anyway, after much thought, I decided my long term goal will be to become a cloud security engineer.
Ok, so I need to learn some cloud stuff and some security stuff. That’s a lot of stuff! However, every journey starts with a first step and one piece of consistent feedback I’ve heard from cybersecurity professionals was this: start a home lab. Well, that sounded straightforward but what type of home lab should I setup?
There are more ways to setup a cybersecurity home lab than there are Pokemon. And since I can only remember the first 150 Pokémon created, I went with my gut, took out my metaphorical Poké Ball, and said to myself, “SOC Analyst Home Lab, I choose you!”
Specifically, I chose to follow the SOC Analyst home lab instructions from Eric Capuano’s blog series which can be found here. (A fantastic video walkthrough of the entire home lab is also on Gerald Auger’s YouTube channel, here: https://youtu.be/oOzihldLz7U )
Eric’s blog series was easy to follow and it taught many hands-on practical cybersecurity skills used in the field, including:
- Simulating the role of both a cybersecurity attacker and defender
- Setting up a virtualized environment in VMware Workstation
- Deploying Windows and Linux VMs
- Windows Registry and System Configurations
- Command Prompt, PowerShell, and Linux CLIs
- Using SSH to to access VMs
- Setting up a C2 (command and control) server using Sliver and dropping a C2 payload on a victim machine (i.e. the Windows VM)
- Analyzing telemetry and EDR (endpoint detection response) using Sysmon and LimaCharlie to detect (and defend) against Sliver.
- Some best practices for SOC Analysts
Below, I will summarize my steps with the SOC Analyst home lab. Much of it mirrors Eric’s blog series but I figure it would be best to provide documentation to show that I did the work…
Let’s Setup Our Defenses Against The Dark Arts
I setup a virtualized environment of a Windows Server VM and a Linux (Ubuntu) VM. Setting up the Linux VM involved editing the ens33 IPv4 configuration with the subnet and gateway IP. After disabling some functions in Windows Registry, Sysmon was installed in the Windows VM.
Next, LimaCharlie EDR was installed on the Windows VM. I then setup LimaCharlie to install a sensor on an endpoint (the Windows VM).
Then, I configured LimaCharlie to ship the Sysmon event logs with its EDR telemetry.
This lab also taught the importance of taking snapshot of VMs, which I also did. Coincidentally, my computer actually did crash right afterwards which was OK because I had the snapshot and could easily revert back to a good machine state!
Let’s (Responsibly & Safely) Use The Dark Arts On Our Defenses
I used SSH to access the Ubuntu VM to turn it into an attacker C2 server by installing and downloading Sliver. Sliver is an open source post-exploitation C2 framework which is an alternative (or used in tandem with) to other C2 frameworks such as Cobalt Strike and Merlin.
Next, I generated a C2 session payload within the Sliver shell. Notice that the payload is an executable named READY_SOURCE. Sliver will randomly assign names for payloads. Out of curiosity, I created several other payloads (not shown) and realized some of random names would make excellent metal rock band names, but I digress…
I then downloaded the C2 payload from the Ubuntu VM (the attack machine) to the Windows VM by starting up a temporary server using a cool Python technique I learned from Eric’s instructions.
Then, I initiated the command and control session to do some reconnaissance on the victim host (the Windows VM):
I then identified the implant’s working directory.
And examined network connections occurring on the remote system…
Let’s Now Detect & Defend Against Sliver with LimaCharlie
I used LimaCharlie’s Sensors to analyze EDR telemetry by going to Processes. While using the Search tool would have been faster, I decided to scroll through the Processes to become more familiar with them. If a process has a green checkmark to the left of it, that meant it was signed. Processes without a green checkmark are not signed. After enough scrolling, I found my unsigned Sliver C2 implant (READY_SOURCE) and it was active on the network. I then viewed the network connection find the destination IP this process was communicating with.
Here, I learned how important it is for a SOC analyst to be familiar with the normal processes that are on a given system. (The blog series author, Eric Capuano, is a SANS instructor and I’m grateful he took the time to highlight this concept and provide a link to SANS’ “Hunt Evil” poster. Eric also mentioned how signed processes that can appear innocent can still be used to launch malware, including LOLBINS).
The next step was to check out the File System in LimaCharlie and search the location where Sliver C2 implant was running from. Once located, the hash of the implant executable was inspected with VirusTotal which can be accessed in LimaCharlie’s UI.
When I saw the VirusTotal output (screenshot above), I was shocked. There is a very good, and very educational, reason for it that Eric explains in his blog series in such a concise way, I will quote it verbatim, below:
- Pro Tip: While it says “Scan with VirusTotal,” what it’s actually doing is querying VirusTotal for the hash of the EXE. If the file is a common/well-known malware sample, you will know it right away. However, “Item not found” on VT does not mean that this file is innocent, just that it’s never been seen before by VirusTotal. This makes sense because we just generated this payload ourselves, so of course it’s not likely to be seen by VirusTotal before. This is an important lesson for any analyst to learn — if you already suspect a file to be possible malware, but VirusTotal has never seen it before, trust your gut. This actually makes a file even more suspicious because nearly everything has been seen by VirusTotal, so your sample may have been custom-crafted/targeted which ups the ante a bit. In a mature SOC, this would likely affect the TLP of the IOC and/or case itself.
What is quoted above was one of the most impactful lessons I learned while conducting this SOC Analyst home lab. It raised my level of awareness, never assume anything just because a software tool’s output says everything is OK, and to “trust my gut” more.
I then viewed the EDR telemetry and events logs using LimaCharlie’s Timeline feature. I was able to filter and find when the implant occurred.
Let’s Use Even More Dark Arts on Our Defenses…
Next, I decided to simulate attempted credential stealing by dumping the remote process from memory to save it on the Sliver C2 server (the Ubuntu VM). The specific technique I used was LSASS credential dumping since it can be used to store both a current user’s and domain admin’s OS credentials. When implemented successfully, LSASS can be used to laterally attack an entire network.
But there was no need to worry in the case of this home lab because invoking LSASS credential dumping was only used to generate telemetry data :) I didn’t actually simulate the actual stealing of OS credentials.
Sure enough, I was able to detect the LSASS attempt through telemetry data in LimaCharlie. Even better, LimaCharlie provided info about the LSASS event. This event info allowed me to created a detection and response (D&R) rule that would alert me whenever the LSASS activity occurred.
lsass.exe is a known in LimaCharlie as a “sensitive process”. Here, the Event Type Filters feature was used to filter for “SENSITIVE_PROCESS_ACCESS” events.
Next, I tested the rule against the event to verify that the detection worked against the event and saved it as a new rule called “LSASS Accessed.”
Then, I was able to detect the threat (LSASS executable) using my own detection rule (signature) created in the previous step. Nice!
More Defense Against The Dark Arts…
Setting up alerts in LimaCharlie for cyber threats like LSASS executables was fun but blocking threats was even more fun.
(At this point in the home lab blog series, Eric mentioned the importance of a SOC analyst skillset called “baselining”. Baselining is the approach used when creating alert-only detection rules. In a nutshell, analysts will have their detection rules run for days or weeks, optimizing them to reduce, or get rid of, false positives but be able to detect high threat activity. At the end of the baselining process, the SOC analyst will then implement the blocking version of that rule.)
Instead of blocking an LSASS executable threat with LimaCharlie, I blocked a simulated ransomware attack created with Sliver. Specifically, I blocked an attack that attempted to delete Volume Shadow Copies.
Next, I went to LimaCharlie to see if it detected the attempt to delete Volume Shadow Copies. It indeed detected it as an event. Metadata was contained within the detection itself due to LimaCharlies Sigma rules. Sigma rules in LimaCharlie contain references to better understand the “why” behind detection rules.
The threat event (the delete Volume Shadow Copies) was then viewed in LimaCharlie’s Timeline feature to see what generated the event. This step was important because it allowed the creation of a Detection & Response (D&R) rule from the event so I could block it.
Defend Against The Dark Arts by Blocking Them…
To test to see if the D&R rule above works, I ran the vssadmin delete shadows /all command again in Sliver. Running this command triggered the D&R rule and blocked the attempt: the shell was unable to return anything from whoami because the parent process was terminated.
The process above worked well for cyber defense since, in the real world, the parent process is usually a ransomware payload or some other nefarious threat actor tool.
Final Thoughts & Inspiration
I learned that tinkering with home labs is essential to developing practical InfoSec skills. I am grateful that Eric Capuano took the time to create an awesome SOC Analyst home lab blog series that I could follow. Along the way, there were some struggles I encountered due to this being my first home lab but those struggles proved to be valuable learning experiences. The direct and indirect learning that occurred during those challenging moments was more than I could have initially imagined.
My goal going forward to is to work on one unique cybersecurity home lab project every week. I will do my best to post about them regularly.
In proper symmetric fashion, since I started this post with a quote that inspired me, I will end it with a quote that I hope will inspire you (the reader) along your learning journey… just make sure to be safe, responsible, and respectful of others along the way.
“Attack is the secret of defense; defense is the planning of an attack.”
-Sun Tzu
