Draconus

Every USER should have a Cyber Weapon to defend himself.

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.
Code Obfuscation: Explore techniques to disguise and modify code to evade detection.
Code Packing: Compress scripts into a single line, showcasing payload packing methods.
Cross-Platform Compilation: Convert Python scripts to Windows .exe and Linux executables directly from a Linux environment, thanks to emulation and cross-compilers.
Assembler Program Compilation: Compile assembly code for both Windows and Linux targets from Linux, eliminating the need for a Windows environment to create ready-to-run executables.

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.

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.

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.

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.

My First Rat

Below, I will demonstrate how to create simple worms using examples so you can understand the creation process. These are straightforward examples—experimentation is up to you, and who knows, you might come up with something great. Keep in mind that creating complex worms with multiple modules, obfuscation techniques, and other features can result in a lengthy compilation process. For instance, Nuitka might take around 5 minutes to compile a file on a virtual machine with 4 GB of RAM and a dual-core CPU running at 3 GHz. If you plan to create more resource-intensive worms, consider increasing the resources of your virtual machine.

Simple python RAT.

When you are in the HIVE section:

add worm LittleMolly
We choose the LittleMolly template, it has spaces for various modules from which we will build the worm.
add module Tcp_v1
For communication, we choose the module “Tcp_v1” is the one that allows sending and receiving more complex commands. To handle this module server use the default server in Draconus.
add module Binky
We add the “Binky” module, which is a simple RAT, allows you to execute commands on the command line and powershell.
worm
We run the “worm” command to see what our worm looks like.

What we see in the image is a snippet of the worm command output, which displays the modules we have added. This also includes modules automatically added by the program, referred to as "support modules." Draconus adds these modules automatically when another module requires them to function correctly. These modules cannot be removed manually as they are essential for proper operation.

The second section is "Variables", which lists the variables we can configure. Different variables will appear here depending on the modules we add. Many variables will take default values set by Draconus to ensure compatibility with the servers created by the program.

In the displayed table:

First column: Shows the variable name.
Second column: Indicates the module that requires it.
Third column: Contains the current value of the variable.
Fourth column: Provides a description of the variable.

As you can see, the worm automatically retrieved the IP address and other variables directly from Draconus's configuration.

If we have all the variables set and the desired modules added, we can proceed to build the worm. To do this, we issue the command: build and wait for the worm to compile. The default compiler is PyInstaller unless we have changed it to another one.

Once the program is compiled, a directory with the name of our worm will appear in the OUTPUT/Hive folder. Inside this directory, you will find a file containing the code and the executable file.

Small is beautiful, and the smaller, the better

Creating a small worm:

When you are in the HIVE section:

add worm Lil_Py

For the main template, we select Lil_Py, which is written in assembler. Its main advantage is that it doesn’t use variables in the code, embedding everything directly on the stack. Additionally, the executable file does not include any extra DLLs, resulting in a very small final file size of just 3-4 KB.

worm

When we issue the worm command, we’ll see that there are no variables to fill in, but there is space for a payload. To add a payload, the module must have space allocated for it. Some modules allow for multiple payloads, and to add them, we can use an additional option in the add command: -t, which lets us place the payload in a specific location.

In this example, there is space for only one payload, and from the description, we can see that it must be a payload written in Python. Other types of payloads will not work.

add payload MicroRat
worm

After adding the payload, we notice that a section with variables has appeared. Every module, regardless of its type, can have variables that can be modified. Therefore, after adding any module, it’s a good practice to review the entire template using the worm command.

Once we have configured the variables as desired, we can proceed with the build process by issuing the build command. After a short while, our small worm should appear in the Hive directory with a size of approximately 3-4 KB. Keep in mind that the larger the scripts you add, the more space the final file will occupy.

Two Stage Attack

The following steps outline the process for preparing a two-stage attack:

Create the main worm that will ultimately be executed on the victim's computer.
Create a small worm that will download and execute the main worm.
Set up a server for communication with the main worm.
Create and configure a server responsible for sending the main worm.

Step 1: Create the Main Worm

While in the HIVE section, follow these steps:

    add worm LittleMolly

We select LittleMolly as the main template because it is ideal for building custom worms.

    add module Binky

We add the Binky module, which provides RAT (Remote Access Tool) functionality.

    add module Gyruss

We add the Gyruss module, which allows the worm to perform a TCP port scan on the victim's computer or other targets.

    add module Tcp_v1

We add the Tcp_v1 module to enable TCP communication. This module allows sending commands, receiving messages, and transferring multiple files simultaneously.

This is just an example. If you want, you can add other modules, use code obfuscators, and apply a starter.

    worm

Finally, we use the worm command to review the current state of our worm configuration.

Next, we locate the Variables section and observe that our port has a default value (usually 4444). Since we will be hosting the main worm on a separate server, we change the port value by issuing the following command:

    var PORT "5555"

This sets the PORT variable to 5555. Our worm will connect through this port.

Once our worm configuration is ready, we start the build process with:

    build

Now, we wait for the worm to compile. After a successful build, the compiled worm will appear in the OUTPUT/Hive directory.

Step 2: Create the Small Worm

First, we issue the following command to clear the previous configuration and start creating a new worm template:

    rebuild

Next, we set a name for the new worm to ensure it doesn’t overwrite the previous one:

    name deliver

Here, we named it deliver (you can use any other name). During compilation, a new file will be created instead of replacing the previous worm.

We then select the Lil_Py worm template, which is very small and has space for a Python payload:

    add worm Lil_Py

Now, we add the PyDelivery payload, a simple script that connects to the server, downloads a file, and executes it:

    add payload PyDelivery

To verify our configuration, we use:

    worm

If the port value is different from the expected 4444, we set it using:

    var PyD_port "4444"

Once everything is configured, we proceed with the build process:

    build

After a short wait, the compiled small worm will be created in the OUTPUT/Hive directory.

Step 3 & 4: Preparing the Servers

Once our worms are ready, we need to prepare the servers. We exit the HIVE console and return to the main Draconus console by issuing:

    exit

Creating the Master Server

In the Draconus console, we create the main server that will handle communication with the primary worm:

    server master 5555

This command creates a server named master on port 5555, which matches the port set in our main worm. We do not specify a server type so that the default type is created, allowing full communication with the worm (enabled by the Tcp_v1 module).

After issuing this command, you should see a message indicating that the server is ready and listening for incoming connections.

Creating the File Delivery Server

Next, we create a server responsible for sending files, which will communicate with the small worm:

    server post 4444 -t send

This command creates a server named post on port 4444 with the send type. This server is specifically designed for file delivery.

After creating the send server, a directory named after the server (in this case, post) will automatically appear in the IN folder located in Draconus's main directory.

We place the main worm file (built in Step 1) into the post directory. The send server will automatically send any file located in its directory to clients requesting it.

Once the servers are ready, we navigate to the main Draconus directory and then to the OUTPUT folder using a file browser or console. From there, go to the HIVE folder where the worms are located.

You should see two directories:

MyWorm - Contains the main worm.
deliver - Contains the small worm used to initiate the first stage of the attack.

Navigate to the MyWorm directory and copy or move the main worm executable MyWorm.exe to the IN/post folder. Once the worm is placed in this folder, anyone who runs the deliver worm will automatically connect to the post server, download the main worm, and execute it on the target computer.

Testing the Attack

Start a Windows machine (e.g., a virtual machine).
Place the deliver.exe worm on the machine and run it.
After a short while, the main worm will be downloaded and executed. It will appear as a process in the Task Manager.

In the Draconus console, the master server should accept the connection. You will see a message along with the unique ID assigned to the connection.

You can now start remote management of the worm by issuing the following command:

    conn [number_ID]

For example:

    conn 2

Once you enter the client's console, you can execute the following command to retrieve a list of available commands:

    msg help

This command sends a request to the worm, asking for the list of commands it supports. The list of commands will depend on how the worm was built, its available options, and the modules used.

Conclusion

I have demonstrated through examples how to create simple worms. The rest is up to you. Experiment, try new things, and create crazy ideas :)) – who knows, something amazing might come out of it!

I’ve spent a lot of time testing the entire project, but despite this, some errors may still occur. Occasionally, a compiler might refuse to cooperate or freeze during compilation (this is rare, but it can happen). If this happens, try compiling the worm again—it should work.

Good luck!!

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! 😄

Name		Name	Last commit message	Last commit date
Latest commit History 5 Commits
app		app
img		img
CONFIG.ini		CONFIG.ini
Commander.py		Commander.py
Draconus.py		Draconus.py
readme.md		readme.md
requirements.txt		requirements.txt

LittleAtariXE/Draconus

Folders and files

Latest commit

History

Repository files navigation