Sliver C2 – Network and Endpoint Detection with NetWitness Platform

[PaoloC]

Preface 

Sliver command-and-control (C2) framework is an open-source cross-platform adversary emulation framework written in Golang. According to recent reports, Sliver has been used in intrusion campaigns by nation-state actors and cybercrime groups, possibly as an alternative to Cobalt Strike. 

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 Attack 

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. 

• (directory contains ‘.woff’ || filename contains ‘.woff’) && file.type=’windows executable’ 

C2 Traffic App Rule: The rule is based on traffic characteristics observed on the testing environment alongside the default configuration specified in the http-c2.go file in the Sliver C2 source code. 

• (client begins 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/', 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/', 'Mozilla/5.0 (Macintosh; Intel Mac OS X ' && client contains ') AppleWebKit/537.36 (KHTML, like Gecko) Chrome/' && client ends ' Safari/537.36') && ((filename = 'bootstrap.js', 'bootstrap.min.js', 'jquery.min.js', 'jquery.js', 'route.js', 'app.js', 'app.min.js', 'array.js', 'backbone.js', 'script.js', 'email.js' && directory contains '/js/', '/umd/', '/assets/', '/bundle/', '/bundles/', '/scripts/', '/script/', '/javascripts/', '/javascript/', '/jscript/') || (filename = 'login.php', 'signin.php', 'api.php', 'samples.php', 'rpc.php', 'index.php', 'admin.php', 'register.php', 'sign-up.php', 'login.html', 'signin.html', 'api.html', 'samples.html', 'rpc.html', 'index.html', 'admin.html', 'register.html', 'sign-up.html' && directory contains '/php/', '/api/', '/upload/', '/actions/', '/rest/', '/v1/', '/auth/', '/authenticate/', '/oauth/', '/oauth2/', '/oauth2callback/', '/database/', '/db/', '/namespaces/') || (filename = 'favicon.png', 'sample.png', 'example.png' && directory contains '/static/', '/www/', '/assets/', '/images/', '/icons/', '/image/', '/icon/', '/png/')) && analysis.service=’http1.1 without referer header’ && analysis.service=’http1.1 without service header’ 

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: 

• https://zeltser.com/c2-dns-tunneling/ 

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: 

• https://community.netwitness.com/t5/netwitness-community-blog/detecting-dns-tunneling-in-rsa-netwitness-dns2tcp/ba-p/521147 
• https://community.netwitness.com/t5/netwitness-community-blog/using-rsa-netwitness-to-detect-c-c-weasel/ba-p/517362 

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

• (service = 53) && (analysis.service = 'dns single request response') && (analysis.service != 'dns dynamic update') && alias.host !='version.bind' && alias.host != domain && dns.resptext regex '^[a0b2c5def6hijklmnopqr_stuvwxyzA1B3C4DEFGHIJKLM7NO9PQR8ST+UVWXYZ-]{10,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. 

Conclusion 

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. 

[PaoloC]

Preface 

Sliver command-and-control (C2) framework is an open-source cross-platform adversary emulation framework written in Golang. According to recent reports, Sliver has been used in intrusion campaigns by nation-state actors and cybercrime groups, possibly as an alternative to Cobalt Strike. 

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 Attack 

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. 

• (directory contains ‘.woff’ || filename contains ‘.woff’) && file.type=’windows executable’ 

C2 Traffic App Rule: The rule is based on traffic characteristics observed on the testing environment alongside the default configuration specified in the http-c2.go file in the Sliver C2 source code. 

• (client begins 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/', 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/', 'Mozilla/5.0 (Macintosh; Intel Mac OS X ' && client contains ') AppleWebKit/537.36 (KHTML, like Gecko) Chrome/' && client ends ' Safari/537.36') && ((filename = 'bootstrap.js', 'bootstrap.min.js', 'jquery.min.js', 'jquery.js', 'route.js', 'app.js', 'app.min.js', 'array.js', 'backbone.js', 'script.js', 'email.js' && directory contains '/js/', '/umd/', '/assets/', '/bundle/', '/bundles/', '/scripts/', '/script/', '/javascripts/', '/javascript/', '/jscript/') || (filename = 'login.php', 'signin.php', 'api.php', 'samples.php', 'rpc.php', 'index.php', 'admin.php', 'register.php', 'sign-up.php', 'login.html', 'signin.html', 'api.html', 'samples.html', 'rpc.html', 'index.html', 'admin.html', 'register.html', 'sign-up.html' && directory contains '/php/', '/api/', '/upload/', '/actions/', '/rest/', '/v1/', '/auth/', '/authenticate/', '/oauth/', '/oauth2/', '/oauth2callback/', '/database/', '/db/', '/namespaces/') || (filename = 'favicon.png', 'sample.png', 'example.png' && directory contains '/static/', '/www/', '/assets/', '/images/', '/icons/', '/image/', '/icon/', '/png/')) && analysis.service=’http1.1 without referer header’ && analysis.service=’http1.1 without service header’ 

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: 

• https://zeltser.com/c2-dns-tunneling/ 

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: 

• https://community.netwitness.com/t5/netwitness-community-blog/detecting-dns-tunneling-in-rsa-netwitness-dns2tcp/ba-p/521147 
• https://community.netwitness.com/t5/netwitness-community-blog/using-rsa-netwitness-to-detect-c-c-weasel/ba-p/517362 

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

• (service = 53) && (analysis.service = 'dns single request response') && (analysis.service != 'dns dynamic update') && alias.host !='version.bind' && alias.host != domain && dns.resptext regex '^[a0b2c5def6hijklmnopqr_stuvwxyzA1B3C4DEFGHIJKLM7NO9PQR8ST+UVWXYZ-]{10,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. 

Conclusion 

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.