Contributing custom armory tools in Sliver C2

In our previous article on writing Sliver extensions, we discussed the anatomy of how extensions, as well as (albeit briefly) aliases, are built and executed in Sliver. To recap:

• Aliases are standalone .NET binaries loaded as part of a sacrificial process
• Extensions are compiled .dlls reflectively loaded into the existing implant process

Whilst we managed to successfully build, compile and execute our extension that could dump the contents of the Windows clipboard, that extension was only available to us, and sharing it meant publishing it on our own GitHub repository (opens in a new tab). To make our tools more accessible to the community, we can instead request to publish them to Sliver’s own armory repository. This short article, as requested by a friend, will discuss how to do exactly that.

Note that Sliver supports private armories (opens in a new tab), where you can ship entire armory repositories of your own. This article simply covers how you can potentially add an existing tool to Sliver’s default armory list.

Armory 101

Given you are reading this article with the goal of publishing your own tools to Sliver’s armory, you have most likely already come across its armory (opens in a new tab) capability. For those who haven’t, Sliver’s armory is a vast repository of tools that can aid in various stages of a red team assessment, and we have previously covered it in one of our videos here (opens in a new tab). Want to dump the system’s memory for credential harvesting? Try Mimikatz (opens in a new tab). Want to forge custom tickets using an acquired krbtgt key for domain takeover? Try Rubeus (opens in a new tab). The armory has it all.

To get a listing of Sliver’s current repertoire of tools, you can use the armory command. For example:

sliver > armory

Reading armory index ... done!

 Packages                                                                                                                             
 Armory    Command Name                    Version   Type        Help                                                                 
========= =============================== ========= =========== ======================================================================================================
 Default   bof-servicemove                 v0.0.1    Extension   Lateral movement technique by abusing Windows Perception Simulation Service to achieve DLL hijacking
 Default   c2tc-addmachineaccount          v0.0.11   Extension   AddMachineAccount [Computername] [Password <Optional>]               
 Default   c2tc-askcreds                   v0.0.11   Extension   Collect passwords using CredUIPromptForWindowsCredentialsName        
...
 Default   mimikatz                        v0.0.1    Extension   A little tool to play with Windows security                          
 Default   mlokit                          v0.0.1    Alias       MLOps Attack Toolkit                                                 
 Default   nanodump                        v0.1.1    Extension   Dump LSASS or inspect its PID with NanoDump                          
 Default   nanorobeus                      v0.0.2    Extension   Beacon Object File for managing Kerberos tickets                     
 Default   nps                             v0.0.2    Alias       PowerShell rebuilt in C# for Red Teaming purposes
...

When executed, Sliver retrieves its default armory index, providing a listing of each tool’s:

• Armory (Default, by default; tools here are compiled and signed by Sliver’s development team)
• Version
• Type (whether an extension or alias)
• Other pertinent information

Any tool can then be installed using the install argument, followed by the relevant package name:

sliver > armory install rubeus

[*] Installing alias 'Rubeus' (v0.0.25) ... done!

Simple. Once within a session, the tool can be accessed by its name and used as necessary:

sliver (HACKERFORCE) > rubeus klist

[*] rubeus output:
   ______        _
  (_____ \      | |
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v2.3.2

Action: List Kerberos Tickets (Current User)

[*] Current LUID    : 0xb4db2

  UserName                 : osmirnova
  Domain                   : CORP-A
  LogonId                  : 0xb4db2
  UserSID                  : S-1-5-21-3829278115-1297606913-1072009015-1106
  AuthenticationPackage    : Kerberos
  LogonType                : Interactive
  LogonTime                : 22/10/2026 23:08:22
  LogonServer              : DC-1
  LogonServerDNSDomain     : CORP-A.LOCAL
  UserPrincipalName        : osmirnova@CORP-A.LOCAL

    [0] - 0x12 - aes256_cts_hmac_sha1
      Start/End/MaxRenew: 22/10/2026 23:08:21 ; 23/10/2026 09:08:21 ; 29/10/2026 22:08:21
      Server Name       : krbtgt/CORP-A.LOCAL @ CORP-A.LOCAL
      Client Name       : osmirnova @ CORP-A.LOCAL
      Flags             : name_canonicalize, pre_authent, initial, renewable, forwardable (40e10000)
...

This article is not specifically about using the armory, but it is worth covering its purpose for context. For a more thorough guide, refer to our video here (opens in a new tab).

Armory repository

One important thing to understand about Sliver’s armory is that packages are neither fetched from, nor managed through, the server. Instead, each operator oversees their own set of packages. Consequently, whenever a particular package is required, Sliver provides its own public armory database (opens in a new tab) from which all packages are fetched, already compiled, validated and ready to go.

To request that our tool be added to the default repository, we need to submit a new issue (opens in a new tab) requesting its addition. Whilst Sliver does not provide a formal set of requirements for submitting a new tool (likely because each tool is assessed manually), there are still some important considerations to bear in mind:

• The tool should be hosted on a public GitHub repository
• It should work out of the box, without requiring additional or external compilation
• A clear description of its use case should be provided, along with details of how it was tested (i.e. version of Sliver, build of Windows, etc.) and some usage examples

Whilst these are not strict requirements per se, they nonetheless represent a sensible minimum, demonstrating professionalism and making it easier for the developers to assess. For the most part, use your best judgement.

Creating a new issue

There are several ways to create a new issue. In our case, we will use GitHub CLI (opens in a new tab), a command line alternative for GitHub operations, which can be downloaded here (opens in a new tab) depending on your system. Before proceeding, be sure to log in (opens in a new tab) as the account you will be using to create the issue.

Once logged in, a new issue can be created using the issue command (opens in a new tab) with the create argument (opens in a new tab), which requires specifying:

• -t, a title for the issue
• -b, the body of the issue (or -F for a body sourced from a file)
• -R, the remote address of the repository

For the title, I used Add tool_name, where tool_name represents the name of the contributing tool. Looking at past issues (opens in a new tab), it appears many other contributors have followed the same format, and so have I. For the body, in the interest of demonstrating professionalism, I made sure to include several sections outlining, in order:

• Description (i.e. its purpose, how it works, etc.)
• Testing environment
• Usage examples

Once everything is set, the issue can be created:

$ gh issue create -t 'Add GetClipboardData' -F body.md -R https://github.com/sliverarmory/armory

Creating issue in sliverarmory/armory

https://github.com/sliverarmory/armory/issues/79

If successful, a new issue will be created and assigned a numerical identifier (e.g. 79 (opens in a new tab)) representing our request.

Validating the issue

Using the issue command’s list argument (opens in a new tab), we can confirm all submitted issues, with the most recent appearing at the top:

$ gh issue list -R https://github.com/sliverarmory/armory/

Showing 27 of 27 open issues in sliverarmory/armory

ID   TITLE                                                                 LABELS       UPDATED
#79  Add GetClipboardData                                                               about 5 minutes ago
...

To view information about the issue, we can use the issue command’s view argument (opens in a new tab), along with its assigned identifier:

$ gh issue view -R https://github.com/sliverarmory/armory 79
Add GetClipboardData sliverarmory/armory#79
Open • 0x73unflower (Ervin) opened about 7 minutes ago • 0 comments

At the time of initially composing this article, the issue remained open with no labels assigned. It was unclear how the developers were triaging submitted tools and marking them as candidates for addition, as they likely follow an internal process. That said, several hours later, one of Sliver’s main developers (moloch (opens in a new tab)) marked it as enhancement, which appears to be a common pattern for tools that have caught their interest:

$ gh issue view -R https://github.com/sliverarmory/armory 79
Add GetClipboardData sliverarmory/armory#79
Open • 0x73unflower (Ervin) opened about 1 day ago • 0 comments
Labels: enhancement

It’s unclear when the developers will merge the tool into Sliver’s armory. That said, we at least have some indication that it is on their radar, as some tools submitted via issues have gone unadded despite being months or even years old, which was something of a concern when writing this article. Whether they responded quickly out of pure coincidence, or because we took care to present the tool properly, professionalism always goes a long way.

Summary

Publishing your own utilities is a great way not only to support the community and expand Sliver’s capability set, but also to demonstrate your competency to future employers. I would encourage you to revisit our initial article on writing extensions in Sliver C2 and have a go at submitting your own utilities.