Unveiling my Methodology for Exciting Bug Discoveries and Optimal Results

Purple dropper feeds samples into array of test tubes.

When I first started getting into bug hunting, I tried to create the perfect methodology by mimicking what the greats were doing. I wanted to do recon and automation like Jason Haddix and become a command line guru like Tom Hudson.

It was fun learning how to use tons of tools but I quickly became bored. I spent more time waiting for tools to finish running and scrolling through text files containing hundreds of URLs than I did hacking. Then there was the issue of organizing all of the overwhelming amount of information I had gathered. Bug hunting began to feel less fun and more like a chore. I began to get discouraged and doubt that cybersecurity was the right field for me.

Switching it up

One day, while I was waiting for amass to wrap up finding everything it could on a program with a massive scope, I decided to poke around on Google to see what I could dig up.

Right away, I found interesting login pages and older looking pages and began focusing my attention on those. Before I knew it, I was on the path to finding bugs before my scan even finished running! Not only did I find bugs faster this way but I was having fun doing it.

It finally dawned on me: I wasn’t losing interest in cybersecurity–I was just doing it wrong!

Keeping it casual

Through my experience, I realized that I wasn’t a fan of using tools, taking extensive notes, or organizing scans. I loved exploring web applications and noting what I thought was interesting. As a result, my bug hunting methodology reflected just that.

Recon

I have the most fun interacting with websites in a more visual manner than what text-based tools have to offer. So, my weapon of choice is Google.

Google offers a variety of advanced queries that can be used to map web applications and find juicy areas that aren’t regularly found with normal searches. For example, I usually start my recon by finding subdomains with this simple Google dork:

site:example.com

Right off the bat, I’ll have some links I can explore to get a feel for what kind of organization I’m dealing with. For more dorks, check out my post about this interesting subject.

I also like to use other search engines like crt.sh or shodan for more technical detail.

This method makes recon much more fun for me. I’m almost like a kid in a toy store perusing around endless aisles of fun!

If I exhaust my Google searches, I’ll try subdomain brute-forcing using wordlists refined with the information I gathered previously. For example, if I stumbled upon some dev or test domains, I may try those domains or similar permutations on other (sub)domains I’ve found. Similarly, I’ll fuzz for hidden directories. Lately, my tools of choice have been gobuster and wfuzz.

Exploitation

Once I’ve narrowed down what area of the scope I want to test, I’ll start manually interacting with it.

Usually, I’ll use mitmproxy to do this. For a command line tool, it has a great interface. Plus, I can save everything I captured to go back to later (can’t do that with Burpsuite Community Edition).

Whatever I want to test, I can forward over to Burpsuite. I frequently use the Repeater to test requests.

As you can see, my tool-set is pretty simple. All I need is a proxy (mitmproxy and Burpsuite) and a fuzzer (gobuster and wfuzz). The reason I keep my toolkit relatively small is that tools and vulnerabilities are constantly changing and evolving. There are a tons of tools out there just for testing XSS and new bypasses are being developed everyday. So, whenever I come across something I want to test, I lookup the new ways people break things currently because defense is always evolving.

This also keeps me from being overwhelmed with having too many tools. It’s hard to keep track of which tools to use when and how. I’m also not overly concerned with brushing up on web app hacking because I learn as I hunt for bugs this way.

And that’s it!

I know, pretty underwhelming right? But that’s the point! My methodology may be simple but it’s flexible, which is extremely important in the field of cybersecurity.

Being simple also makes me a more effective bug hunter as I’m focused on the fun parts instead of making hunting boring. Having fun while hunting for bugs makes me more motivated and following my intuition and curiosity makes me dig deeper into the application to find bugs that automation would normally miss.

Of course, this is the method that works for me. You might be fine with letting tooling do the heavy lifting. One thing is for sure, though: if you’re not having fun, you’re doing it wrong!