It took over two years to build my bug bounty automation framework (The Blue Whale), so I like to share the story of the building process and some details about the project architecture…
Talking about bug bounty automation … basically, you want to automate the tasks that will be repeated over and over, which will cost you effort and time each round.
The second and most important reason is “scalability”, the power of being able to scale a scan of a single bug on all of the bug bounty programs.
To achieve the concept of “scalability”, you will need a solid infrastructure that can run on over 1 million subdomains in a few minutes, and this will take a lot of effort.
First Try (Bash Scripting)
My first try wasn’t too successful, as you can expect, because I relied on bash scripts and bash pipelines to run the tools and direct the outputs to files and other tools.
The problem is that you don’t have a central database to save the results, and any small error in the outputs can break the whole pipeline’s workflow.
So, I did a deep research on the topic to find a solution. After some research, I found this article by Hakluke, where he discussed four ways to build an automation framework, and the one that I liked the most was the second way, using Django Custom Commands.
The Solution (Django Custom Commands)
Django Custom Commands is a way to run a Python script from the CLI, which can be connected to other commands and a central database.
So I started with a test project to learn more about the development process, then I started the “Blue Whale” project.
This solution of using Django will add more features like Django ORM to interact with the backend database, “Django Apps“ which will give you the ability to organize your project into Django apps under the same project (e.g recon app) and one of the best options is the “Django Admin Panel” which will give you direct access to the database (view, add, delete) from a web based admin panel.
The Blue Whale
It’s a bug bounty automation project that will automate the whole bug-hunting process from adding the program into the database to extracting automated bugs.
As I mentioned before, the Django project will be divided into “apps”, and each app will be divided into custom commands and database models.
Following are some details about the main apps and their functionality…
1) Targets app
Used to manage, add, remove, and view programs and domains from the database.
2) Recon app
Used to run recon tools and commands on the target and save the new results into the database
Extract subdomains for each domain
Filter alive-subdomains
Collect parameters and endpoints
Collect IPs and open ports
Fingerprint each live subdomain
Save all results into the database
The call_command() function will run a Django custom command from another one in the same project, so each one of these (subdomains, ports, urls, …) in the screenshot is a Django custom command.
3) Hunting app
This app will run the bug-hunting scans on the collected targets from the recon app (live-subdomains, parameters, and endpoints).
This app has two parts to run the scans
Running open source tools (e.g Nuclei)
Running Python functions using “Threading” techniques
4) Reports app
This app can be used to send Telegram or Discord alerts to report some information about the running workflows and new findings.
I didn’t mention a lot of other details that will make this article very long, but you got the idea.
The latest big development in this project was adding dockerfile and docker-compose.yml files to the project to make it easier and faster to deploy the full project into any new server with a single command.
For me, the project was built for “bug hunting” and “security research” on the largest number of public bug bounty and VD programs.
Following is a screenshot from my main deployment instance, which has over 1.1 million subdomains…
So at the end, if you want to share any new idea or hunt for a zero-day on the scale, you can message me on ( X ) -> https://x.com/__the7th
And thanks for your time dude, I appreciate you…