I remember when I was first starting bug bounty and offensive security. I approached it in the same manner as my previous learning sprints. Immerse myself with a mix of educational videos, and physical books. I found that the amount of educational videos and youtube videos were daunting. It reminded me of how much I didn’t know. I had to shift my thinking to believe that every piece of information I can understand is a win. Sometimes learning in a modular way works best for me, and I try to learn one thing in and out at a very technical level. These building blocks are key in my ability to continue learning daily. Pace my learning and use time to reflect and question my understanding of that thing.
When I began bug bounty I fell into some initial traps. The first was the monetary aspect of the activity. I had security experience but I began to see how much money people were claiming to make from this. The quick money aspect of it lured me in, but it would be some time before I actually made a single dime off bug bounty.
In the beginning I would use nuclei against a large number of targets from one vps. I know, it is very inefficient but I just thought I could scan a huge list and wake up in the morning with hits. Instead I would wakeup to a lot of informational alerts from nuclei, and things that did not necessarily lead to a real security vulnerability. I tuned the scans to only include – medium/high/critical events and I began receiving some hits. These turned into some quick reports on Hackerone, Bugcrowd, and Intigriti, but they were mostly only Vulnerability Disclosure Programs (VDPs). But since I was running the script at night, I was not around to restart the process if something were to hang. It was a complete inefficient process as I would have to wait an entire day or sometimes more to finish a scan….if it did finish. Ultimately, the VPS wasn’t ready for all that network traffic. Also, since I was just using the default settings of nuclei or a framework like reconftw, I was sending potential malicious traffic at a target. This taught me a lot about Web Application Firewalls and how to become less chatty, and less finger-printable. I began working on bypasses for simple payloads, and to my surprise these modifications often bypassed the waf security controls. This was about a year of my time, and I realized my initial approach was totally wrong (for me, and my learning style). But I continued to evaluate the time I put into this, and the eventual results. I began to develop a methodology to use on a repeatable basis to find vulnerabilities.
I started out using bash to orchestrate security tools that were installed on my VPS. I wanted to be very thorough with recon and subdomain enumeration. I used the widely available subdomain tools like subfinder, amass, etc. I would then deduplicate and sort the list by unique entries. I saved this subdomain list and wanted to use it with multiple different workflows to find different bugs. I would do port scans, look for live endpoints using httpx probing, search for subdomain takeovers and more. I was presented with the same VPS problem, but thought I just needed more servers.
I started looking into distributed frameworks for automating the VPS deployment process. I started using Axiom and it greatly increased my ability to do mass scanning. I loved the fact that it would split my target list across 25-50 small virtual machines and run each tool in a more efficient way. For each vulnerability class I learned about, I thought how I would be able to create a workflow to find this specific bug. Reading this article by Otterly really helped me get it setup and fully understand Axiom. I found quite a bit of unique bugs this way, and I am continuously updating my methodology to this day. Something else that helped me was using cron jobs to run my bash scripts. This was an excellent way to have things running all day across multiple servers in different regions. This guide explains the process for Linux.
I will be posting past success stories of bugs found, and I’ll try to include my thought process and how I went about finding the bug. I will also have some posts on things I learned from the reporting process and how to make your report easily readable. This concludes this post, as I could have kept rambling on things that I tried and used in the last two years.
Thanks for reading!