Search the Community

Warning: Sliver is currently in alpha, you've been warned 🙂 Implant framework Sliver is a general purpose cross-platform implant framework that supports C2 over Mutual-TLS, HTTP(S), and DNS. Implants are dynamically compiled with unique X.509 certificates signed by a per-instance certificate authority generated when you first run the binary. The server, client, and implant all support MacOS, Windows, and Linux (and possibly every Golang compiler target but we've not tested them all). Features Dynamic code generation Compile-time obfuscation Local and remote process injection Anti-anti-anti-forensics Secure C2 over mTLS, HTTP(S), and DNS Windows process migration Windows user token manipulation Multiplayer-mode Procedurally generated C2 over HTTP (work in progress) Let's Encrypt integration In-memory .NET assembly execution DNS Canary Blue Team Detection Getting Started [Hidden Content] Source Code The source code repo contains the following directories: assets/ - Static assets that are embedded into the server binary, generated by go-assets.sh client/ - Client code, the majority of this code is also used by the server protobuf/ - Protobuf code server/ - Server-side code sliver/ - Implant code, rendered by the server at runtime util/ - Utility functions that may be shared by the server and client

The Faction C2 Framework Faction is a C2 framework for security professionals, providing an easy way to extend and interact with agents. It focuses on providing an easy, stable, and approachable platform for C2 communications through well documented REST and Socket.IO APIs. Instead of one large monolithic application, Faction is designed loosely around a micro services architecture. Functionality is split into separate services that communicate through message queues. This approach provides several advantages, most important of which is allowing users to quickly be able to learn how the system operates. You can watch a demo of Faction: Presentation at Troopers 19 Faction consists of four main services: Console: The Faction console is a javascript application that interacts with the Faction API. It can be accessed with any modern browser and serves as the operational entry point to the system. API: The API is the how users, agents, and anything else interacts with Faction. Core: The Core service handles all user and agent messaging, including processing user commands and handling encrypting/decrypting agent messages. Build Servers: Build Servers handle building payloads and modules. They are language specific, allowing Faction to be easily extended to support new languages. Currently Faction supports .NET payloads and modules. Concepts and Terminology Payload: A file or command that is run on a target machine to establish an agent Agent: An instance of an Agent Type that is registered and communicating with Faction. Agent Type: A kind of agent, for example Marauder Modules: Libraries that provide a Faction Agent with additional functionality in the form of commands or transport options. Transport: The combination of a Transport Server and Transport Module Transport Server: A server that sits between a payload/agent and the Faction API. It manipulates API messages so that they can be routed over different transmission methods or obfuscated (or both) Transport Module: A module that allows an agent to talk to a specific kind of Transport Server Download && More info [Hidden Content]

FudgeC2 - A collaborative C2 framework for purple-teaming written in Python3, Powershell and .NET FudgeC2 is a campaign orientated Powershell C2 framework built on Python3/Flask - Designed for team collaboration, client interaction, campaign timelining, and usage visibility. Note: FudgeC2 is currently in alpha stage, and should be used with caution in non-test environments. Beta will be released later this year, at BlackHat Arsenal. Users Users within Fudge are divided into 2 groups, admins and standard users. Admins have all of the usual functionality, such as user and campaign creation, and are required to create a new campaigns. Within campaign a users permissions can be configured to once of the following: None/Read/Read+Write. Without read permissions, a user will not be able to see the existence of a campaign, nor will they be able to read implant responses, or registered commands. User with read permission will only be able to view the commands and their output, and the campaigns logging page. This role would typically be assigned to a junior tester, or an observer. Users with write permissions will be able to create implant templates, and execute commands on all active implants. Note: in further development this will become more granular, allow write permissions on specific implants. User Creation An admin can create a new user from within the Global Settings options. They will also have the option to configure a user with admin privileges. Campaigns What is a campaign? A campaign is a method of organising a engagement against a client, which allows access control to be applied on a per user basis Each campaign contains a unique name, implants, and logs while a user can be a member of multiple campaigns. Implants Implants are broken down into 3 areas Implant Templates Stagers Active Implants Implant Templates An implant template is the what we will create to generate our stagers. The implant template wil contain the default configuration for an implant. Once the stager has been triggered and an active implant is running on the host this can be changed. The list of required configurations are: URL Initial callback delay Port Beacon delay Protocol: HTTP (default) HTTPS DNS Binary Once a template has been created the stager options will be displayed in the Campaign Stagers page. Stagers The stagers are small scripts/macros etc which are responsible for downloaded and executing the full implant. Once an implant has been generated the stagers page will provide a number of basic techniques which can be used to compromise the target. The stagers which are currently available are: IEX method Windows Words macro Active Implants Active implants are the result of successful stager executions. When a stager connects back to the Fudge C2 server a new active implant is generated, and delivered to the target host. Each stager execution & check-in creates a new active implant entry. Example As part of a campaign an user creates an implant template called "Moozle Implant" which is delivery to a HR department in via word macro. This then results in five successful execution of the macro stager; as a result the user will see five active implants. These will be listed on the campaigns main implant page, with a six character unique blob. The unique implants will be listed something similar to below: Moozle Implant_123459 Moozle Implant_729151 Moozle Implant_182943 Moozle Implant_613516 Moozle Implant_810021 Each of these implants can be individually interacted with, or using the "ALL" keyword to register a command against all active implants. Implant communication Implants will communicate back to the C2 server using whatever protocols the implant template was configured to use. If an implant is setup to use both HTTP and HTTPS, 2 listeners will be required to ensure that full commincation with the implant occurs. Listeners are configured globally within Fudge from the Listeners page. Setting up and modifying the state of listeners requires admin rights, as changes to stagers may impact other on-going campaigns using the same Fudge server. Currently the listeners page displays active listeners, but will allow admins to: Create listeners for HTTP/S, DNS, or binary channels on customisable ports Start created listeners Stop active listeners Assign common names to listeners Implant configuration further info. URL: An implant will be configured to call back to a given URL, or IP address. Beacon time: [Default: 15 minutes] This is the time in between the implant calling back to the C2 server. Once an implant has been deployed it is possible to dynamically set this. Protocols: The implant will be able to use of of the following protocols: HTTP DNS Binary protocol A user can enable and disable protocols depending on the environment they believe they are working in. More info & Download [hide][Hidden Content]]

C3 Custom Command and Control C3 (Custom Command and Control) is a tool that allows Red Teams to rapidly develop and utilise esoteric command and control channels (C2). It’s a framework that extends other red team tooling, such as the commercial Cobalt Strike (CS) product via ExternalC2, which is supported at release. It allows the Red Team to concern themselves only with the C2 they want to implement; relying on the robustness of C3 and the CS tooling to take care of the rest. This efficiency and reliability enable Red Teams to operate safely in critical client environments (by assuring a professional level of stability and security); whilst allowing for safe experimentation and rapid deployment of customised Tactics, Techniques and Procedures (TTPs). Thus, empowering Red Teams to emulate and simulate an adaptive real-world attacker. Attackers must establish command and control (C2) to gain influence within their target environments in order to pursue their goals and objectives. It is therefore arguably one of the most important parts of the cyber kill chain because without it any payloads that are successfully delivered operate blindly, cannot provide network level pivoting and near real-time interaction. It is no surprise then that organisations have been imposing more controls against what types of communications are allowed from systems and a priority has been placed on defensive teams to be able to effectively detect C2. This is emphasised by two out of the twelve columns of Mitre ATT&CK being related to this area, ‘Command and Control’ and ‘Exfiltration’. The first proof of concept of C3 was presented at BlueHat v18 by William Knowles and Dave Hartley. Since then it has been refactored and some aspects reimagined into what it is today by a team of developers heavily influenced by members of the MWR Red Team. Video : BlueHat v18 || Overt Command & Control: The Art of Blending In Practical Usage C3 is designed to be an easy and intuitive interface that allows users to form complex paths during adversarial simulations. This section provides an in-depth guide of how to use C3, from compilation through to code execution. See blog post for a detailed tutorial. [hide][Hidden Content]] For contribution guide (how to develop a Channel tutorials), see this page [hide][Hidden Content]] Download [hide][Hidden Content]]

Covenant is a .NET command and control framework that aims to highlight the attack surface of .NET, make the use of offensive .NET tradecraft easier, and serve as a collaborative command and control platform for red teamers. Covenant is an ASP.NET Core, cross-platform application that includes a web-based interface that allows for multi-user collaboration. Quick-Start Guide Please see the [Hidden Content] guide to get started with Covenant! The [Hidden Content] documents most of Covenant's core features and how to use them. Features Covenant has several key features that make it useful and differentiate it from other command and control frameworks: Intuitive Interface - Covenant provides an intuitive web application to easily run a collaborative red team operation. Multi-Platform - Covenant targets .NET Core, which is multi-platform. This allows Covenant to run natively on Linux, MacOS, and Windows platforms. Additionally, Covenant has docker support, allowing it to run within a container on any system that has docker installed. Multi-User - Covenant supports multi-user collaboration. The ability to collaborate has become crucial for effective red team operations. Many users can interact with the same Covenant server and operate independently or collaboratively. API Driven - Covenant is driven by an API that enables multi-user collaboration and is easily extendible. Additionally, Covenant includes a Swagger UI that makes development and debugging easier and more convenient. Listener Profiles - Covenant supports listener “profiles” that control how the network communication between Grunt implants and Covenant listeners look on the wire. Encrypted Key Exchange - Covenant implements an encrypted key exchange between Grunt implants and Covenant listeners that is largely based on a similar exchange in the Empire project, in addition to optional SSL encryption. This achieves the cryptographic property of forward secrecy between Grunt implants. Dynamic Compilation - Covenant uses the Roslyn API for dynamic C# compilation. Every time a new Grunt is generated or a new task is assigned, the relevant code is recompiled and obfuscated with ConfuserEx, avoiding totally static payloads. Covenant reuses much of the compilation code from the SharpGen project, which I described in much more detail in a previous post. Inline C# Execution - Covenant borrows code and ideas from both the SharpGen and SharpShell projects to allow operators to execute C# one-liners on Grunt implants. This allows for similar functionality to that described in the SharpShell post, but allows the one-liners to be executed on remote implants. Tracking Indicators - Covenant tracks “indicators” throughout an operation, and summarizes them in the Indicators menu. This allows an operator to conduct actions that are tracked throughout an operation and easily summarize those actions to the blue team during or at the end of an assessment for deconfliction and educational purposes. This feature is still in it’s infancy and still has room for improvement. Developed in C# - Personally, I enjoy developing in C#, which may not be a surprise for anyone that has read my latest blogs or tools. Not everyone might agree that development in C# is ideal, but hopefully everyone agrees that it is nice to have all components of the framework written in the same language. I’ve found it very convenient to write the server, client, and implant all in the same language. This may not be a true “feature”, but hopefully it allows others to contribute to the project fairly easily. More Info & Download [hide][Hidden Content]]

Command and Control for C# Writing Author: Leiothrix VirusTotal check result Don't pass it on to Virus Total anymore. He tried for you. Install Nuget download these package using System.IO; using Telegram.Bot; using Telegram.Bot.Args; using Telegram.Bot.Types.InputFiles; using AForge.Video; using AForge.Controls; using AForge.Video.DirectShow; Add related classes in 'References' System.Drawing; System.Windows.Forms; How to used Modify your Token to the program static void Main(){ botClient = new TelegramBotClient("token"); //Your Token botClient.OnMessage += Bot_OnMessage; botClient.StartReceiving(); Thread.Sleep(int.MaxValue); } More info & Download [hide][Hidden Content]]

A DNS-over-HTTPS Command & Control Proof of Concept introduction godoh is a proof of concept Command and Control framework, written in Golang, that uses DNS-over-HTTPS as a transport medium. Currently supported providers include Google, Cloudflare but also contains the ability to use traditional DNS. installation To build godoh from source, follow the following steps: Ensure you have dep installed (go get -v -u github.com/golang/dep/cmd/dep) Clone this repository to your $GOPATH's src/ directory so that it is in sensepost/godoh Run dep ensure to resolve dependencies Run make key to generate a unique encryption key to use for communication Use the go build tools, or run make to build the binaries in the build/ directory usage $ godoh -h A DNS (over-HTTPS) C2 Version: dev By @leonjza from @sensepost Usage: godoh [command] Usage: godoh [command] Available Commands: agent Connect as an Agent to the DoH C2 c2 Starts the godoh C2 server help Help about any command receive Receive a file via DoH send Send a file via DoH test Test DNS communications Flags: -d, --domain string DNS Domain to use. (ie: example.com) -h, --help help for godoh -p, --provider string Preferred DNS provider to use. [possible: google, cloudflare, raw] (default "google") Use "godoh [command] --help" for more information about a command. Source & Download [Hidden Content] page as part of tagged releases.

SILENTTRINITY An asynchronous post-exploitation agent powered by Python, IronPython, C# and .NET's DLR Requirements Server requires Python >= 3.7 SILENTTRINITY C# implant requires .NET >= 4.5 How it works Notes .NET runtime support The implant needs .NET 4.5 or greater due to the IronPython DLLs being compiled against .NET 4.0, also there is no ZipArchive .NET library prior to 4.5 which the implant relies upon to download the initial stage containing the IronPython DLLs and the main Python code. Reading the source for the [Hidden Content] it seems like we can get around the first issue by directly generating IL code through IKVM (I still don't understand why this works). However this would require modifying the compiler to generate a completely new EXE stub (definitely feasible, just time consuming to find the proper IKVM API calls). C2 Comms Currently the implant only supports C2 over HTTP 1.1, .NET 4.5 seems to have a native WebSocket library which makes implementing a WS C2 channel more than possible. HTTP/2 client support for .NET's HttpClient API is in the works, just not yet released. The implant and server design are very much "future proof" which should make implementing these C2 Channels pretty trivial when the time comes. COM Interop [Hidden Content] Python Standard Library We technically could load/use IronPython's stdlib instead of calling .NET APIs but this would require writing some "magic" dependency resolving code. Possibly could modify [Hidden Content] to do this automagically. Inject into unmanaged process [Hidden Content] If you need some help setting up your environment. Reporting issues Reporting any issue will be appreciated, but please, feel free to use this [Hidden Content]. Source & Ref. [hide][Hidden Content]]