FudgeC2 v0.5.7 releases – A collaborative C2 framework for purple-teaming
FudgeC2 is a campaign orientated Powershell C2 framework built on Python3/Flask – Designed for team collaboration, client interaction, campaign timelining, and usage visibility.
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 campaign.
Within a campaign, a user’s 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.
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.
What is the campaign?
A campaign is a method of organizing an 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 are broken down into 3 areas
- Implant Templates
- Active Implants
An implant template is what we will create to generate our stagers. The implant template will 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:
- Initial callback delay
- Beacon delay
- HTTP (default)
Once a template has been created the stager options will be displayed in the Campaign Stagers page.
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 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.
As part of a campaign, a user creates an implant template called “Moozle Implant” which is delivered to an 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:
Each of these implants can be individually interacted with, or using the “ALL” keyword to register a command against all active implants.
Implants will communicate back to the C2 server using whatever protocols the implant template was configured to use. If an implant is a setup to use both HTTP and HTTPS, 2 listeners will be required to ensure that full communication 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 customizable 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:
- Binary protocol
A user can enable and disable protocols depending on the environment they believe they are working in.
- SMTP support for notification and user account creation – further email notifications will be released in 0.5.8
- RESTful API implementation created for the following functionality:
- Campaign creation
- SMTP/Email configuration
- Implant interaction
- UI changes to the campaign pages
- Implants now display optional configurations, such as operating hours.
- The implants default user agent now match Edge 44, and not Powershell/5.1
- Dockerfile has been updated to pull from Kali Linux
- User profile now contains more information
- Early OpenAPIv3 documentation (+ yaml) can be found at https://docs.moozle.wtf (Work in Progress)
Numerous bug fixes.
Copyright (C) 2019 Ziconius