We are excited to announce the release of a new detection package “Sliver”, which identifies and raises alerts related to the Sliver C2 framework. This new package joins our industrial-strength C2 Collection and uses a variety of techniques to detect Sliver, above and beyond our HTTP-C2 package’s existing Sliver coverage. In this blog we provide some basics about Sliver and how it works and then dive deep into the techniques we use to detect this popular and powerful tool.
Sliver is an Open Source post-compromise C2 framework, written in Go. The term “post-compromise” is used in the sense that a previous “loader” malware has already compromised the victim host. The loader is then used to install the C2 implant.
Sliver is rising in popularity and is thought to be taking significant market share off other well known C2 frameworks like Cobalt Strike and Brute Ratel [1] [2] [3]. From an Attacker’s perspective, here is a visual of how the Sliver server console can look like on startup.
Sliver is used by red teams and threat actors alike. It is free, flexible and easy to use, so it’s easy to understand why it’s a popular choice for C2. The documentation is high quality and the code base is under active development. The framework also provides valuable intelligence functionality, for example alerting the attacker when implants are discovered by defenders, as described by these two examples:
Within the UI, the operator can use the “watchtower” command to periodically check VirusTotal and IBM X-force to see whether any of the hashes of the implants have been submitted - this would indicate that the implant has been detected. An operator simply enters their API key and then uses the monitor start command from the Server console. Ironically, this functionality may also have the unintended effect of tracking attacker groups via common IP addresses or API keys.
The implant includes the ability to sprinkle “DNS canary tokens”. These are simply unique domains that exist only in the strings of the implant binary. The intention is that the attacker can externally monitor for any access to these domains, as any such access would mean that the implant has been discovered and is likely being analyzed as part of an IR process. This intelligence then informs the attacker’s strategy and timings.
In terms of the attacker’s mission, Sliver is used 1) to exfiltrate data and 2) as a base to conduct information gathering and lateral movement within the victim network. Sliver has been associated with several APT groups, notably in the publication “Further TTPs associated with SVR cyber actors”, by the NCSC group within GCHQ. Quote below:
In addition Sliver has been implicated with several Nation state and Financially motivated groups: [5] [6]Following the publication of the joint WellMess Advisory SVR cyber operators used the Sliver framework. Sliver is an “…open source, cross-platform adversary simulation/red team platform…” written in Golang that supports command and control mechanisms over a variety of protocols including Mutual-TLS (T1573.002), HTTP/S (T1071.001) and DNS (T1071.004). The use of the Sliver framework was likely an attempt to ensure access to a number of the existing WellMess and WellMail victims was maintained following the exposure of those capabilities. As observed with the SolarWinds incidents, SVR operators often used separate command and control infrastructure for each victim of Sliver. SVR actors have used methods other than malware to maintain persistence on high value targets, including the use of stolen credentials.
We describe our detection strategy via a high level view of two key framework components:
C2 server
The C2 server can be hosted on Linux (the most common), MacOS or Windows. It runs listeners that accept communications from implants installed on victim hosts. Listeners can be thought of simply as protocols, the choices being HTTP/HTTPS/MTLS/Wireguard/DNS.
Separate to the listeners there is a functionally called “Multiplayer-mode” which allows for multiple operators to control the implants from the same server. While this isn’t C2 traffic in the classic sense, there are ways to detect this component (for example using JARM, and default certificate strings), however this traffic will generally not be seen from within a victim organization’s environment and so is not the subject of this blog.
The C2 implant is a single binary, compiled on the C2 Server and intended to be run on the MacOS/Windows/Linux victim host. The crucial compilation parameters are 1) The location of the C2 server, and 2) The listener protocol to use when communicating with it. The attacker bakes these components into the implant during compilation, and then the framework uses compilation obfuscation techniques to improve endpoint evasion.
Our detections focus on the four primary listener types. Here we briefly describe the detection strategies:
When implants are compiled for the HTTP/HTTPS listener, the victim host will first attempt to reach the C2 server’s HTTPS listener, and if this is not reachable it will try HTTP. We found several elements in the GET/POST and HTTP headers that enabled high-quality detections without inducing any False Positives (as confirmed by stress-testing in our Polaris environments).
Additionally, for sites employing break-and-inspect, these same cleartext HTTP detections work even if the victim host successfully reaches an encrypted HTTPS C2 listener.
As an example of what interacting with an implant looks like to the attacker, the following screenshot shows a listener being started, an implant checking in, the implant being attached to, a command being run, and then output received.
It’s noteworthy that Sliver also has quite extensive server-side logging, both of the implant communications as well as the actions of “operators” and the commands executed. The screenshot below shows a sample of the logs generated by this activity described.
We profiled the C2 traffic and were able to detect the encrypted traffic based on elements of the encryption initiation, together with flow artifacts. We keep the specifics of these detections unpublished in order to avoid aiding attackers with evading them.
Mutual TLS provides an extra level of communication security, and is recommended by the Sliver authors over one-way TLS for this reason. Using similar methods to HTTPS we are able to detect this traffic with high confidence.
Wireguard is a popular VPN tunnel protocol, and this listener type is also one of the recommended listeners due to the added layer of security it provides. We formed a detection strategy using a stateful model based on traffic characteristics observed by Zeek. These characteristics involve protocol violations and volume/duration attributes.
Note that our application-id package (part of Corelight’s Entity Collection) and our VPN Insights package (part of Corelight’s Encrypted Traffic Collection) will also flag this traffic as wireguard in conn.log and vpn.log respectively. Other non-Sliver Wireguard traffic will also be flagged in this way - indeed, a fruitful hunting strategy could be implemented with logs alone along the lines of “alert when wireguard traffic originates from hosts that are not expected to use wireguard VPN”. On the topic of Wireguard: organizations can often be surprised by the amount of previously unknown wireguard VPN traffic! Our discussion here underscores the value of the visibility that our application-id and VPN Insights packages provide.
While developing this package, we had a couple of promising indications that we were focusing on the right detection elements, and that this package would be valuable, which we believe illuminating to recount here:
During development, we read that the research team at VMware released an excellent blog describing an attack scenario using Sliver. While we have our own lab infrastructure and PCAP files to develop against, “the more PCAPs, the merrier,” so we reached out to the VMware research team, and they kindly provided their captures. We were pleased to see that our package detected the C2 traffic out of the box. This was excellent validation, as the VMware infrastructure was set up entirely independently of our own lab.
With the development package running on a customer site (via Polaris), the package produced a Sliver “notice”. Upon querying the customer, they confirmed that the notice did indeed reflect a host from which the corporate Red Team was operating Sliver. This was a perfect scenario, as 1) our package worked out of the box, and 2) the actor was not in fact malicious. To further validate, we pivoted on the connection UID across the standard Zeek logs, finding that the victim host appeared to be MacOS - not nearly as common a victim OS as Windows. As noted earlier, the implant can be compiled to MacOS/Windows/Linux, and through the Zeek logs we had strong indicators that the host was a Mac. Curious, we then asked the customer for some “ground truth,” and they confirmed that the victim host was indeed MacOS, nicely highlighting the value of Corelight’s evidence-based data for hunting and IR.
As described above, we can detect four of the key listeners that Sliver offers, and three of them involve encrypted protocols. This is yet another sign that a Network Detection strategy remains highly valuable in an encrypted world.
Further to the point made above, one could argue that NDR is not only valuable but necessary. As shown in the real world Red Team detection above, the Sliver implant had apparently successfully evaded all EDR controls that were in place. This said, when telemetry from NDR and EDR are paired together, each can greatly improve the context of the other.
Sliver is a powerful and widely used C2 post-exploitation framework which employs a variety of techniques for communication and obfuscation. Corelight’s powerful new detection package (a new addition to our industrial-strength C2 Collection) recognizes and alerts on all 4 of the primary listener types, including those using encryption and VPNs to obscure their activity. Not only have our detections been validated by traffic in the wild, but they’ve even detected a live Red Team at one of our customer’s sites, immediately proving the value of the detection, and more broadly Corelight’s approach of using the right analytic tool for the job.
Make sure you enable the new “Sliver” package and let us know what you think! We’re already working on some interesting new detections to share with you soon.
[2] https://thehackernews.com/2023/01/threat-actors-turn-to-sliver-as-open.html
[3] https://www.cybereason.com/blog/sliver-c2-leveraged-by-many-threat-actors
[5] https://www.team-cymru.com/post/sliver-case-study-assessing-common-offensive-security-tools
[6] https://www.darkreading.com/vulnerabilities-threats/-sliver-cobalt-strike-alternative-malicious-c2