This post will cover the Network and Endpoint detection of Sliver C2 based on injected Sliver shellcode into a OneDrive process, that should be running, through a custom stager. The network detection will cover common protocols available to Sliver for command-and-control activity, namely HTTP and DNS. The C2 framework offers additional communication protocols like MTLS and WireGuard. However, such connections are more likely to be detected and/or blocked (i.e. not allowed) in most corporate environments.
The attacker starts by creating his custom stager which:
Fetches the Sliver shellcode from an attacker-controlled server.
Gets a handle on the OneDrive process on the victim’s system.
Figure 1: Custom stager
Allocates space for the Sliver shellcode in the memory of the OneDrive process.
Creates a new thread on the OneDrive process which runs the Sliver shellcode.
Figure 2: Custom Stager
The attacker packages the delivery of the custom stager in an HTA file and delivers it to the victim.
Figure 3: Delivery mechanisms through invoice.hta file
Once the victim double clicks on the HTA file, the payload is executed injecting Sliver shellcode in memory and calls back to the C2 server, giving the attacker access to the victim's system. The attacker executes reconnaissance commands on the victim’s systems using the implant’s shell feature.
Figure 4: Callback and reconnaissance commands
The above attack steps can be applied irrespective of the protocol used to communicate with the C2 server.
Network Detection with NetWitness Packets
C2 Communication through HTTP Protocol
NetWitness Packets makes it possible to pull apart characteristics of HTTP traffic through the Service Analysis meta key. The analyst notices some interesting meta values they can use to carve the dataset.
Figure 5: HTTP traffic characteristics
Once the number of sessions has been reduced, other meta keys can be used to find any artifacts that are of interest. Interestingly, all the sessions are made from a single User-Agent(client) value with filenames containing PHP, JS, and HTML extensions. The important thing that the analyst notices here is that all the sessions result in a 202 Accepted or 204 No Content message which is displayed in the Errors(error) meta key.
Figure 6: HTTP messages returned by C2 server
By switching to Event View, the raw sessions can be analyzed to discover encrypted traffic going to the domain msftupdate.com, which in this case resolves to the IP address 172.30.5.14. Neither of these values is of particular interest as they are only valid for this lab simulation.
Figure 7: Raw session for POST request
The analyst can now use the source and destination IP address as pivot point to view all the HTTP traffic exchanged between these systems. Here, two filenames stand out, s2.exe and temp.woff.
Figure 8: Suspicious filenames
The raw sessions indicates that the first connection is made to port 8000 of the msftupdate.com domain for the filename s2.exe. Based on the response from the server, this is determined to be a windows executable file.
Figure 9: Request for s2.exe
Seconds later, another request is made to the msftupdate.com domain, now on port 8080, containing temp.woff as the filename. Another important thing that can be noticed is the size of the file that is downloaded.
Figure 10: Request for file with .woff extension
The analyst can enter the packet view to see the raw packet bytes. By enabling the Common File Patterns in this view, the magic bytes for a Windows executable header (MZ / 4D 5A) can be easily noticed in the binary data.
Figure 11: Windows executable magic bytes in returned binary data
Based on the evidence of the large binary downloaded through the WOFF extension in the URL and the encrypted HTTP traffic that follows, the traffic can be classified as highly suspicious. Further evidence can be provided by the Wiki page of the Sliver C2 framework, which states that WOFF is the default extension used to fetch the stage 2 payload.
Furthermore, the time of download of the s2.exe executable and the subsequent connection to the URL containing the WOFF extension may potentially indicate it being a stager used to download the stage 2 payload on the target system.
Figure 12: Sliver wiki
From these findings, the analyst can extract relevant characteristics from the observed traffic and application rules can be created in order to track this kind of activity in the future. The application rules are provided below:
Stager App Rule: According to the Sliver C2 wiki, the stage two payload is retrieved by specifying the WOFF string in the URI. Also, the type of file being returned is classified as a Windows Executable based on the magic bytes found in the binary data.
The activity observed in this post is made using the Sliver C2 HTTP profile, thus all communication is happening over HTTP. In the case where the C2 communication is made through encrypted protocols like HTTPS, analysis would become more difficult, although analysts can still leverage other means like JA3/JA3S fingerprinting and TLS certificates. In these cases, introducing SSL Interception technology is highly recommended.
C2 Communication through DNS Tunneling
DNS Tunneling is a technique used by threat actors to establish stealthy Command and Control channels. The technique abuses the fact that DNS communications are often left unblocked. For a more detailed view of how this technique is used, refer to the following articles:
The way an analyst can hunt for any DNS Tunneling activity in an environment is by focusing his attention on any Second Level Domain (SLD) that stands out as suspicious and correlating the events with the number of different hostnames associated with the SLD in question. Some great resources that detail this technique in detail are the following:
By using the same technique in this case, the analyst is quickly able to determine the presence of potential DNS tunneling activity happening in the network.
Figure 13: Unique hostnames associated with single SLD
As can be seen in the image above, there are many unique hostname values associated with the SLD of interest. This is a typical behavior of DNS Tunneling activities as the uniqueness in the hostnames makes sure that the DNS queries are not cached and can reach the authoritative DNS server (the C2 in this case) each time.
The analyst opens the raw sessions and realizes that the traffic consists of DNS A and TXT records, indicating that both records are used by the DNS Tunneling technique employed by Sliver C2.
Figure 14: Raw sessions for DNS traffic
This can be confirmed by looking at the source code for the DNS communication in Sliver, where TXT records are used for the polling mechanism and to transfer data from the C2 to the implant, while A records are used to transfer data from the implant to the C2.
Moreover, Sliver employs a custom Base64 alphabet with no padding to encode the data exchanged in the communication between the implant and the C2. This feature allows communication to evade common detection mechanisms based on standard base64 alphabets.
Figure 15: Sliver custom Base64 alphabet
The NetWitness Incident Response team worked with the Product Team to implement a detection capability for traffic utilizing this custom Base64 encoding scheme in the DNS_verbose_lua parser. This capability is now available in the form of the meta value Possible Sliver base64 txt record in the Indicators of Compromise (IOC) meta key.
Figure 16: Meta value for sliver base64 txt records
Since this type of traffic can be classified as highly suspicious, an application rule can also be created based on its characteristics to track this kind of activity. The application rule is based on the custom Base64 alphabet used by Sliver, matching against patterns with the minimum length of TXT data observed during analysis and the maximum length set in the Sliver source code (254).
In addition, the polling mechanism used by Sliver uses DNS TXT record containing a Base64 encoded value starting with the byte pattern 62 61 2D 6E (ba-n). This pattern was observed in several versions of the Sliver C2 framework tested on different systems.
Figure 17: Byte pattern repeated in TXT records.
The byte pattern is too short to confidently create application rules but can prove useful for building network signatures for tools like Snort in order to detect Sliver DNS Tunneling activity.
Endpoint Detection with NetWitness Endpoint
While investigating the IOC, BOC and EOC meta keys, the analyst notices an interesting meta value “unsigned creates remote thread”.
Figure 18: Interesting meta value in BOC
By pivoting into the Event View the details can be seen. A suspiciously named file (s2.exe) has created a remote thread on the OneDrive.exe process. Moreover, the suspicious file is found in the C:\ProgramData directory.
Figure 19: CreateRemoteThread event
To get a better understanding of a certain event and to be able to classify it as malicious or not, analysts need to create some more context on events happening around the same timeframe. In this case, a file named invoice.hta is launched from Explorer, indicating that a user may have double clicked on the file. This in turn makes Windows run the file with mshta.exe, the default application for running HTA files. The analyst also notices that PowerShell is subsequently run with base64 encoded arguments and a network event is observed immediately after, indicating that PowerShell was used to make an outbound connection. Further evidence suggests that the same PowerShell code then creates the executable s2.exe on the system.
The s2.exe executable is run immediately after, creating a remote thread on the OneDrive.exe process.
Figure 20: Suspicious events
Through NetWitness, the analyst can easily decode the base64 encoded PowerShell, confirming that it was used to download and run the s2.exe executable on the system.
Figure 21: Base64 decoded PowerShell contents
Following this event, the OneDrive.exe process spawns a PowerShell instance and executes reconnaissance commands on the system.
Figure 22: OneDrive creates PowerShell child process and reconnaissance commands execution
Commands executed through the shell feature of Sliver are trivial to detect through endpoint visibility, as the method is deemed not opsec-safe because it spawns a PowerShell instance to execute commands on the infected system. However, even if the feature is not used during active attacks, analysts can still determine suspicious behavior based on abnormalities observed on the system, like a process requesting handles to multiple processes in a short amount of time (common for process listing) or files being created by a process in suspicious locations.
Based on this evidence, the analyst is quickly able to classify the system as infected.
The blog outlines detection methods for the default configuration of the Sliver C2 framework. While the configuration can be easily changed as stated in the project wiki, the NetWitness Incident Response team has worked multiple cases where the default configurations for different attacker tools were found in the wild.
Furthermore, it is important to note that while the HTTP and DNS protocols were used for C2 communication in this example, Sliver C2 provided built-in encryption for its implants and payloads making it harder for analysts to understand specific threat actor operations on compromised systems. This makes it fundamentally important to also have an endpoint solution in place to keep track of the activities happening on endpoints.