https://github.com/littleatarixe/draconus

Malware, Shellcode builder with C2, tools and compilers. Easily create your own malware, small or large.
https://github.com/littleatarixe/draconus

assembly c2 compilers ddos keylogger malware malware-development python3 ransomware rat shellcode stealer

Last synced: 27 days ago
JSON representation

Malware, Shellcode builder with C2, tools and compilers. Easily create your own malware, small or large.

Host: GitHub
URL: https://github.com/littleatarixe/draconus
Owner: LittleAtariXE
Created: 2024-12-16T04:49:42.000Z (over 1 year ago)
Default Branch: master
Last Pushed: 2025-03-20T22:44:35.000Z (about 1 year ago)
Last Synced: 2025-04-12T02:13:01.380Z (about 1 year ago)
Topics: assembly, c2, compilers, ddos, keylogger, malware, malware-development, python3, ransomware, rat, shellcode, stealer
Language: Python
Homepage:
Size: 1.38 MB
Stars: 0
Watchers: 1
Forks: 1
Open Issues: 0
Metadata Files:
- Readme: readme.md

Awesome Lists containing this project

Draconus

Logo Projektu

Every USER should have a Cyber Weapon to defend himself.

The project has a new version.

This project serves as a comprehensive toolkit designed to introduce fundamental concepts in ethical hacking and malware creation. It offers tools and functionalities for creating shellcodes, basic malware, code obfuscation, and code packing into single lines, providing an engaging way to explore malware techniques responsibly.

Features and Advantages

Shellcode Generation: Create custom shellcodes for testing and experimentation.

Simple Malware Creation: Build your own malware and choose the modules yourself.

Various Code Obfuscation Methods: Additional modules responsible for code obfuscation.

Cross Compilation: Capability to build ready-to-use EXE and DLL files from a Linux environment.

Python Cross Compilation: Capability to create ready-to-use EXE files using Nuitka and PyInstaller from a Linux environment.

Built-in C2: Ability to create various server types supporting multiple simultaneous connections.

Special Compilation Scripts: Ability to add information to compiled files using a database.

Disclaimer

This toolkit is developed solely for ethical and educational purposes to deepen understanding of malware creation and analysis. Using this tool to target other users, conduct attacks without prior consent, or apply it in unauthorized environments is strictly forbidden. The responsibility for proper use rests entirely on the user. Caution is advised! Misuse could harm your system or other users. We highly recommend using this tool within isolated virtual machines.

⚠️ Important Warning

It is highly recommended to use Draconus and any worms you create in isolated virtual machines with a dedicated network.

Some modules, such as PyVir or Panther, can infect files or destroy a system after a single execution. The same applies to modules designed for DDOS attacks.

Use this tool wisely to avoid unintentionally causing harm to yourself or others.

Draconus Tutorials

***** TUTORIALS *****

Draconus

Disclaimer

Important Warning

About Draconus

Install

Start

First Step

Hive

My First Rat

About The Project

Project Features

Changelog

Tutorials

About Draconus

Draconus is a robust program consisting of two sub-programs designed for streamlined server management and client interaction. It offers an automated approach to managing connections, messages, and file transfers without requiring user intervention, making it a powerful tool for ethical hacking and controlled testing environments.

Program Structure

Background Program: The first sub-program runs in the background, handling server operations and managing client connections automatically. This design allows for seamless, automated tasks, such as accepting connections, receiving messages, and file handling, all without needing manual input.

Control Program: The second sub-program serves as the user interface, connecting to the background program. Built with the Python Click interface, it provides the user with interactive control over various functions, enabling flexible and precise management.

Main Sections

Main Draconus Section: Responsible for creating and managing servers, handling connections, and overseeing core operations.

Hive Section: Specializes in creating and compiling ready-to-use client programs, making it easy to deploy new clients as needed.

Installation

Ensure you have Python 3.11.2 or a newer version installed on your system.

Install Docker (e.g., using the following command):
```
sudo apt install docker.io
```

To allow the program to interact with Docker, you need to set the appropriate permissions. Run:
```
sudo usermod -aG docker $USER
```
Afterward, log out and back in (or restart your system) to apply the new permissions.

Due to the recent policy changes in Python modules on Linux, make sure you have Python’s virtual environment package, venv, installed. If not, install it with:
```
sudo apt install python3.11-venv
```

Navigate to the Draconus directory:
```
cd Draconus
```

Create a virtual environment:
```
python3 -m venv ./venv
```

Activate the virtual environment:
```
source ./venv/bin/activate
```

Install the project dependencies:
```
pip install -r requirements.txt
```

The installation is complete, and your environment is ready to use.

Getting Started

Before running the program, edit the CONFIG.ini file. This file contains configuration settings with explanations. The main setting to update is IP, where you should enter the IP address of the computer or virtual machine that will run Draconus. After saving your changes, you can proceed with launching the program.

Draconus consists of two main components: Draconus and Commander. Follow these steps to launch both programs correctly:

Note: Before launching the programs, you need to activate the virtual environment. Draconus can be run without activating the virtual environment, but Commander requires an active venv. To activate the venv, navigate to the Draconus directory and execute:

source ./venv/bin/activate

Start Draconus: Run Draconus with the command:
```
python3 Draconus.py
```
Since Draconus is designed to operate in the background, you can also launch it as a background process using:
```
nohup python3 Draconus.py &
```

Start Commander: After Draconus is running, launch Commander with:
```
python3 Commander.py
```
Commander will attempt to connect to Draconus upon startup. If Draconus is not running, Commander will display an error message and will not launch until it detects an active Draconus instance.

First Steps

Once Commander has connected to Draconus, you will have access to a console menu resembling a Linux terminal. This interface allows you to manage connections, create servers, and establish direct connections with clients. The help menu is always available, and many commands can be run with the --help parameter for additional assistance.

Server Types

You can create four main types of servers:

Default: Communicates via TCP socket, with data formatted in JSON and encoded in base64. This server type is recommended for advanced communication, background file transfers, and automated tasks with clients that require no user intervention.

Raw: Uses TCP socket but sends raw bytes, allowing for simple message reading and file reception (one at a time) without metadata such as name or type. Ideal for lightweight client programs that don't require complex communication.

Down: Designed solely for receiving files, without support for messages, commands, or other functionalities.

Send: A server designed only to send files to the client. It does not support messages or commands. When a connection is established, it automatically sends the set files.

b64: TCP server. Receives and sends base64 encoded messages.

Make Servers:

Servers can be created using the following format:


    server [name] [port]

or:


    server [name] [port] -t [type]

For example:


    server my_server 4444 -t raw

If you don't specify a server type, the default type will be selected automatically.

Servers start automatically after creation and wait for incoming connections from clients. Each server can handle multiple connections simultaneously, so you are not limited to a single connection. Draconus provides access to manage all connected clients, assigning a unique global ID to each client. Servers also automatically detect when a client disconnects and clean up its connection from the program.

Exiting the Program

The program can be terminated using two commands: exit or quit.

exit - Stops the Commander program. The program closes, but Draconus continues to run in the background.
It can still accept connections, send and receive files from clients.
When you restart Commander, it will reconnect to the running Draconus, and any pending actions or messages will be displayed on the screen.

quit - Stops both Commander and Draconus. It sends a termination signal to Draconus,
shutting down both programs completely.

Additional Commands

close - Shuts down the specified server and disconnects all connected clients.
For example: close my_server.

task - Displays all tasks currently being performed by Draconus.
These include threads actively running within the program.

conn - Enters interaction mode with a connected client.
This allows you to send commands, files, and more. Each connected client is assigned a unique ID by Draconus, which is used for identification.
To initiate communication with a client, use the command conn [ID], for example: conn 3.

show - Displays a list of created servers and connected clients.
- -s - Shows a list of created servers.
- -c - Displays a list of all connected clients across all servers.

hive - Accesses a new section of the program with additional commands, menus, and options.
This is where you can create worms.

First Run

When you start Draconus, a directory named OUTPUT will appear in its main directory. This is a critical folder where Draconus stores its logs, downloaded files, created worms, and more. Do not delete this directory while the program is running. You can safely delete it only when both Draconus and Commander are stopped.

Contents of the `OUTPUT` Directory:

Logs - This folder contains log files. Every message displayed by Draconus is saved here, along with a timestamp.
Similarly, any message received from clients is also logged.

LOOT - This folder stores files downloaded from or sent by clients. It will contain subdirectories named after the IP addresses of clients, which will hold the files sent by them.
Additionally, a dump subdirectory will store files that could not be identified during download. For example, if a client sends a file without headers or metadata (e.g., name, type), it will end up here.
Think of the LOOT folder as the treasure chest for files received from clients.

Hive - This folder contains files related to worms, source code, shellcodes, and ready-to-use executables.
If you create a worm, it will be stored here.

Shortcuts - This folder provides shortcuts to various useful resources in the project, so you don't have to search for them manually.
It includes:
- A folder with icons where you can add your own icons and use them when creating worms.
- A shortcut to files where you can add custom code, for example, to payloads.

Additional directories may also appear in the OUTPUT folder, depending on the tools you use in Draconus.
Instructions for new directories will be displayed within the program. Similarly, subdirectories may contain additional files as you use the program.
For example, many shortcuts in the Shortcuts folder are only created after you access the "hive" section in Draconus.

Hive

The Hive section is where you create worms. Worms are generated by selecting a main template from the worm section. Depending on the type of worm, some allow the addition of extra modules, payloads, and even code obfuscation, while others only support adding payloads.

After selecting the appropriate modules, the process moves to filling out the so-called variables, such as IP address, connection port, and more. Many modules are configurable, and everything is clearly described with example values provided to make configuration straightforward.

Main Modules for Building Worms

worm - The main template. This is the first module that must be added.
It determines the type of worm you are creating and which additional modules can be used.
There are versions that support every type of module, but there are also smaller worms written in assembler,
allowing for the addition of simple scripts, and so on.
In general, you can create an executable file that weighs over 10 MB or a mini worm with a file size of around 3 KB.

module - A variety of modules that add different functionalities to your worms.
These can include selecting a TCP connection method, connecting via Discord webhook, network scanning, launching a shell, and more.
Each module comes with a detailed description of its purpose and functionality.

payload - Various types of payloads written in Python, PowerShell, or as executable files for testing.
Some modules and worms allow embedding a binary (executable) file within the worm itself, which can then be executed later.

shadow - Code obfuscation options. The final code undergoes various processes to make analysis more difficult.
You can use multiple obfuscation modules to make the code even harder to analyze.

starter - The final method of embedding code into the program.
For example, you can choose to place the entire code at the very end, encoded in Base64, and run it as a one-liner.

wrapper - An additional option that allows embedding the entire worm code into another program.
For example, the worm is built using Python modules, but instead of being compiled directly,
it is embedded into assembler code. The assembler code is then compiled, and it executes the Python worm code.

process - Defines the steps the worm will go through until it is fully created.
These steps include code generation, obfuscation, adding imports, compilation, and shellcode creation.
The processes vary depending on the main worm template. For example, a worm designed for shellcodes
will have different steps compared to one created in Python.

It is not recommended to modify the default processes unless you are already familiar with the program and understand what you are doing.

cscript - Special scripts used during compilation. They add information to EXE and DLL files, such as version numbers, company names, etc. You can create your own custom entries or use entries from a predefined database.

food - You could say it's food for the worm. These are special variables that contain pre-defined values. When building a worm, it may need things like text to hide shellcode, base URLs, or other resources — these are fetched from the Food section.
Food values can be assigned to variables, making it a convenient tool when you want to store a collection of paths, text, shellcode, scripts, etc.
In the shortcuts directory, you'll find references to some Food variables that you can modify — and those changes will be reflected in the worms you create.

scode - Templates used to generate shellcode.

Hive Commands

show - Displays a list with descriptions of available modules.

Usage: show [module_type], e.g., show worm.

You must specify the module type, such as worm, module, payload, etc.

add - Adds a module to your template.

Usage: add [module_type] [name], e.g., add module Binky.

The first module to be added must always be one of the main modules, such as worm.

remove - Removes a specified module from your worm.

Usage: remove [module_type] [name], e.g., remove payload MicroRat.

name - Sets the name of the worm being created.

Usage: name [worm_name], e.g., name MyFirstWorm.

A directory with the worm's name will appear in the Hive folder, where its final files will be stored.

icon - Sets an icon for the executable file.

Usage: icon [file_name], e.g., icon bee1.ico.

You can add additional icons to the folder whose shortcut is located in the Shortcuts directory.
Draconus includes several default icons that you can use.

worm - Displays the entire configuration of the worm being created.

Usage: worm.

It shows added modules, descriptions, required variables to fill in, and more. This is the main command for overseeing the building process.

var - Sets variables for the worm being created.

Usage: var [name] '[value]', e.g., var ip_addr "192.168.1.1".

Variables depend on the type of worm being created and the modules added. Some modules require additional variables.
You can modify all variables listed in the required variables and set variables sections.

rebuild - Clears all modules and resets the entire worm.

Usage: rebuild.

This allows you to start a new project from scratch.

comp - Displays a list of available compilers.

Usage: comp.

Not all worms can use all compilers. This command lets you view the name and description of each compiler so you can choose the appropriate one for your worm.
Worms have default compilers set, such as PyInstaller for Python worms, but you can switch to others, like Nuitka.

install - Installs the required compilers.

Usage: install or install -i [master_compiler_name].

Draconus is installed without compilers by default. You need to install compilers as you use the program.
You don't have to install all compilers, especially if you don't plan to create files for certain systems.
However, some functionalities, such as building shellcode, are not possible without specific compilers.

Note: Installing additional compilers involves downloading special Docker images, which can take up extra disk space.
For example, the compiler for creating Windows EXE files from Python takes approximately 3.5 GB.

dlc - Installs additional modules.

Usage: dlc -s or dlc -i [dlc_name], e.g., dlc -i "DLC_1".

Draconus allows adding extra modules over time without requiring you to download or install a new version of the program.
To install a DLC, place the package in the IN folder that appears in Draconus's main directory.

sheme - Displays a list of processes and steps available for worms.

Usage: sheme.

This is primarily for informational purposes to help you understand the worm-building process if you want to customize it.

gvar - Displays a list of global options.

Usage: gvar.

These are special options you can configure, such as changing the default compiler for worms or applying additional compilation options.

setgvar - Sets a global option.

Usage: setgvar [name] [value], e.g., setgvar COMPILER_NAME WinePyNuitka.

exit - Exits the Hive console and returns to the Draconus console.

Usage: exit.

build - Starts building the worm into an executable file.

Usage: build or build --options, e.g., build --no_compile.

If the --no_compile option is used, the executable file will not be created; instead, you will receive a file with the raw code.

Many commands offer additional help, accessible with the --help option, e.g., build --help.

About the Project

I understand and acknowledge that the techniques presented in this project are amateur and, for some, may seem primitive. However, I developed this project while teaching myself how all of this is actually created.

I do not work in IT and have never worked in the field. I’m not a professional programmer—just a hobbyist. I’m aware that the entire project could probably be done much better: the code could be written more efficiently, better libraries could be used, and so on. But for me, what matters most is that it works.

The project will continue to evolve, and over time I plan to add new tools and modules.

🚀 Planned Features

In version 1.0, I focused primarily on building and testing Draconus. Less attention was given to creating various modules.

In future versions, I plan to add the following:

More payloads written in PowerShell.

More Python-based worms with different functionalities.

Additional types of DDOS attacks.

Support for building Windows shellcode.

Ability to create DLL files. - DONE

More DLL files.

Changelog

Draconus 1.0

Start Project

Draconus 1.0.1

Improved reading of 'RAW' messages from network sockets.

Added payload 'reverse shell' module in python for linux and windows.

🛠️ Draconus 1.1

New payload building system: Now it's time to come up with something... :)

Added payload module: PS_DeliverObf - An obfuscated PowerShell payload with configurable options.

Added payload module: PyReverse - A reverse shell written in Python for both Windows and Linux.

Added main template: Worm Arkanoid - Enables the creation of DLL files with PowerShell payloads. Additionally, an EXE file is generated to call the payload function. The DLL libraries can be used in any other code.

Improved raw message handling from sockets: A message buffer was introduced to prevent the screen from being flooded with hundreds of single-character messages. See CONFIG.INI for more details.

New functionality: Automatically prepares a directory with only the necessary files for the worm to operate. If the worm requires several files, a folder with the worm's name is created, containing only the essential files.

Bug fixes: Addressed numerous small and significant issues.

🛠️ Changelog for Version 1.1.1

Added support for special "food" variables: These contain predefined data such as shellcodes and various worm-related data.

New worm: WinShell (x86) - A Windows 32-bit worm designed for testing shellcodes.

New worm: WinShell64 (x64) - A Windows 64-bit worm designed for testing shellcodes.

New worm: RiverRaid (x86) - Hides shellcode among multiple text variables.
Generates both an EXE file and a separate DLL with injection functions, making detection more difficult.

New worm: BrutePID (x86) - Scans every process PID within a given range and attempts to inject shellcode into one of the processes.

New cross-compiler: MC_win64 - A 64-bit cross-compiler supporting C, C++, and assembler.

Added text display customization: In CONFIG.ini, a new option allows adjusting text display for different screen sizes.

More information added to the "Queen" console commands.

New DLL building system.

New wrapper: DropZone (not fully functional) - An experimental "worm-in-a-worm" system.
It embeds a compiled worm inside a "wrapper worm" and attempts to execute it as a separate process.
However, it struggles to handle large binary files (several MB). Work is ongoing to resolve this issue.

Added several new tools to assist in building different types of worms.

Bug fixes: Many small fixes, and probably some new bugs as well! 😄

🛠️ Changelog for Version 1.2

New Worm Constructor Completely redesigned the process of building custom worms, improving the creation of new EXE and DLL combinations.

New Single Image CrossComp CompilerA single compiler image containing multiple compilers (mingw-x64, mingw-x32, PyInstaller, Nuitka). Older images can be deleted as they will no longer be used.

New Cscript Module TypeNew scripts for the compilation phase, allowing various descriptions to be added to DLL and EXE files.

New Worm: BrutePID64 (x64) - A test program that attempts to open processes within a specified PID range, inject, and execute shellcode.

New Payload: PyDllInject - A payload written in Python for DLL injection.

New Payload: PyExeShell - A payload written in Python for shellcode injection.

New Module: LodeRunner - A DLL library. Upon import, it starts a thread establishing a TCP connection, downloading a file, and executing it. See the program description for more details.

New Worm: BruteDLL - Written in assembly. Checks each process within the specified range and attempts to inject a DLL using dynamic function import.

🛠️ Changelog for Version 1.2.1

Build Worm as Payload — A new option allows building a Python-based worm and converting it into a payload instead of compiling it. The payload will appear automatically in the payload section of the library. Currently works only with raw Python code (support for compiled payloads is in progress).

Usage: build --payload or build -p.

New Module: Smuggler_DLL — A special library that dynamically imports functions from kernel32 and other DLLs. It locates the Export Table address in memory, allowing the hiding of imports and dynamic linking without recompilation.

New Module: Smuggler_Lib — Same functionality as Smuggler_DLL, but in the form of a static lib library instead of a dll. Designed for manual linking during compilation.

New Worm: Pong — A reverse TCP worm that launches cmd by default. All function names are dynamically generated and hidden, making detection very difficult. Compiled as a single-file executable using additional libraries.

✅ Tested on updated Windows 10 (April 2025). Not detected by Windows Defender.

New Worm: Pong2 — Same as Pong, but split into two files: an exe and a dll containing the worm logic. This separation allows for alternative execution methods.

✅ Tested on updated Windows 10 (April 2025). Not detected by Windows Defender.

New Module: PayloadStorage — A 64-bit Assembly module for embedding large payloads. Accepts any type of binary data and supports basic obfuscation by altering the hex values of each byte. Payload capacity can be adjusted via a variable.

New Module: UnLoader — A stealth module that writes files to disk using imports loaded directly from memory, avoiding static references to common APIs.

New Worm: Falcon — A minimalistic worm written entirely in Assembly. It decodes a payload, writes it to disk, and launches it via WinExec or OpenProcessA. The execution command can be customized using a special variable. Uses memory-only dynamic imports for stealth.

✅ Tested on updated Windows 10 (April 2025). Not detected by Windows Defender.

🛠️ Changelog for Version 1.2.2

Removed Worm: LittleMolly — The LittleMolly worm has been removed and replaced by a new, more advanced version.

New Worm: Montezuma — A Python-based worm that can be customized by adding various modules, including code obfuscators and more. Perfect for building your own payload or compiling into a standalone executable.

Improved Compatibility — Many Python modules have been updated to ensure full compatibility with the new Montezuma worm template.

TCP Module Update — The basic TCP communication module can now receive and interpret commands directly within the worm.

Updated Module: Panther (Ransomware) — Improved with support for fast or slow encryption modes and extended file search across the disk. Now more effective and configurable.

Improved Module Display — The module lists, worm configurations, and variable tables are now displayed using the Python tabulate library for better formatting and readability.
⚠️ Please re-run: pip install -r requirements.txt to update your environment.

🛠️ Changelog for Version 1.2.3

New Commander Launch Option — You can now run the control interface directly with the command: python3 c2.py.
This new loader will automatically activate the virtual environment, create one if missing, install all required dependencies, and then launch Commander.
Both the old and new launch methods are supported and can be used interchangeably.

New Server Type: b64 — A new server type that uses TCP sockets with Base64-encoded communication.
Commands are sent using the standard msg instruction. This server type is required for communication with the new Zaxxon worm.

New Worm: Zaxxon — A fully assembly-written worm and the author's first large-scale project in pure ASM.
- Polymorphic design: every build produces a different binary with randomized code and values.
- Uses hidden imports and passes Defender analysis tests.
- Communicates over Base64-encoded TCP socket (requires server type b64).
- Executes commands in new threads, allowing continuous communication during task execution.
- Supports creation of a secondary socket for file transfer (ideal for send server).
- Can search directories and steal files matching patterns like *.jpg or aa??.bmp.
- Contains space for two separate shellcodes, hidden within large blocks of random text.
- Includes special feature for injecting shellcode in fragments, decoded gradually from hidden text blocks (tested with MSF calc shellcode — undetected and successfully injected).
- Scans process ranges to find candidates for injection.
- Includes a fun feature to spam the screen with MessageBox windows.
- All commands are available after connecting to Draconus. Use the command msg help to view supported options.
- Zaxxon includes customizable parameters: hex names, random text pools for function obfuscation, and more.
- Has the ability to clone itself and add entries to Windows autostart. Be cautious when testing!
  Check the Windows registry to find where Zaxxon has created its autostart entry.

🛠️ Changelog for Version 1.2.4

Update readme

🛠️ Changelog for Version 1.2.42

Fixing bugs

🛠️ Changelog for Version 1.3

New Worm: WShellcode — A new template for generating Windows x64 shellcode.
This main worm type allows you to create shellcode from predefined templates.
To begin shellcode generation, add WShellcode as your base worm with the command:
add worm WShellcode.
Templates are available as a new type of module called scode.
To list all available shellcode templates, run: show scode.

New Module Type: scode — Shellcode templates used to generate working shellcode.
These modules provide different payload behaviors in low-level binary form.

New Shellcode Module: WinExec — A simple test shellcode that uses the WinExec function to launch a program (default: calc.exe, can be changed).
Mainly for testing — unless someone gets creative with the commands 😄

New Shellcode Module: WEPy — A shellcode that uses OpenProcessA to spawn Python via cmd and inject a script directly.
It includes a slot for a Python-based payload that you can insert manually.

New Compiler Option: build --spayload — Builds a shellcode and places it into the payload library.
The generated shellcode can then be used like any other ready-to-use payload in other worms.

New Compiler Option: build --food — Builds a shellcode and stores it as a FOOD-type variable.
These shellcodes can later be inserted into other worms or modules that accept shellcode as input.

Bug Fixes — Several minor bugs were fixed and improvements made for better overall stability.

📦 Version 1.3.1 – Update Summary

🆕 New Modules:

New Shellcode module: MsgBoxA – New shellcode module. Generates MessageBoxA shellcode with custom text (default: "Hello World"). The message box appears as an error-type window.

New Worm: JackRoad – New main worm module written in C++. Designed for shellcode testing. It scans processes within a given PID range, locates a vulnerable process, injects, and executes the shellcode.

Does not use windows.h; instead, it dynamically imports all functions through a custom library. Displays detailed information about the target process, memory allocation, and more.

Successfully tested with shellcode generated via Draconus on Windows 10. Injection and execution worked without detection by Windows Defender.

Note: Not tested with signed shellcode generated via MSFramework.

🔧 Other Changes:

Removed the outdated example RAT creation section from the README.

Added a link to the new tutorial section, which now includes both written guides and video walkthroughs.