How I Design My Prefect Bug Bounty Automation (1)

miniboom
3 min readDec 29, 2022

--

This is a series of articles about how I design and Implemented my prefect Bug Bounty automation. It helps me a lot, so I decide to share it with you, whatever hunting bug or peneration tests,it works 24 hours for me. keeps my job and earn a bounty.

Why

But, first question, why should every bug hunter to build bug bounty automation framework?

I have used many excellent tools to penetration test, such as AMass、Subfinder、Oneforall、Gobuster etc. while using them more often, I’m sorry to find out some problem.

  • each tool requires different input parameters and the output format is also inconsistent
  • the efficiency of maunal copy and paste the data which different tools gived is too low
  • there is not smart way of collection those data, Data relationship is not clear

face the reality! although each tool is wonderful, without automation there will be a lot of repetitive work you have to do.

of course, if you want to build a prefect bug bounty automation, there are a lot of work need to do, so I will give you some great ideas about what benefits will it bring you.

  • boring repetitive work will say goodbye to you
  • you will have your own asset database,if there is a serious vulnerability, you will be able to downloaded the poc from github for the first time to hunt the bug.
  • Capabilities can be transferred, no matter which platform, company you are, your code will work for you all the time, keep making money for you
  • the more experience you have, the more capable your system will be

ok, next I am going to walk you through every attempt I have made to build a bug bounty automation framework including the failures and achievements. Then I’m going to tell you exactly how I design my prefect one.

Attempt 1 Develop My Own Tool

I have tried to read the source code of tools like oneforall, subfinder, amass, httpx, want to integrate their unique ideas and characteristics together to develop my own subdomain libary.

For example, if subfinder judges whether a domain has a CDN, it will use the project discovery team’s own CDN ip database comparison to make a judgment. oneforall judges the pan-analysis by analyzing the similarity of html pages to give the answer.

And the logic in these tools, such as querying crtsh, shadon and other services, I only need to implement is once.

So I practiced my idea with great enthusiasm, and named it jellyfish, hoping that it would have many tentacles and be aggressive like a jellyfish, and could continuously bring me bounties while I was sleeping.

code of jellyfish

I started the subdomain module of jellyfish. After reading the source code of oneforall, substr3, subfinder and httpx, I realized the stitching of these tools with code. It took me nearly two nonths. This progress is beyond my tolerance.

The idea of this idea is very good, but it also has obvious disadvantages:

  • the development languages of these open source tools are inconsistent, including python, go, and rust, and they cannot be directly copied and pasted together to run
  • the cost of learning open source tools is too high, and implementing it again with go is purely wheel-making, which is of little significance
  • maintenance costs are high, and open source tools themselves have bugs, and frequently update versions and iterate functions. once it is integrated in your own code, you can only find the bug again by yourself. and its new functions cannot be used

So, this time jellyfish ended in faulure.

This article is introduced here, and follow-up attempts will continue to be written in the following series. Thanks for reading.

--

--

miniboom
miniboom

Written by miniboom

A technical geek, security researcher, and developer in the web3 world

No responses yet