Star Wars fans, let’s be honest here.  All of us at one point or another dreamed of being Boba Fett.  Who doesn’t want a jet pack, a blaster rifle/flame thrower, and an awesome back story?  Not to mention, an inherently bad-ass job.   Even 9 year old Matt was flying his mini version of the Slave 1 around pretending to the be universe’s most dangerous bounty hunter.

So, naturally, when I discovered bug bounty programs, I was drawn to them.  Hunting for vulnerabilities in some of the world’s largest organizations, I became a cyber Boba Fett.

If I had a Boba Fett mask, I’d being wearing it. Alas, I do not and Batman will have to suffice.  But I digress.

The first thing you’re going to want to do is sign up on BugCrowd and/or HackerOne.  These are the two most popular platforms that host bug bounty programs for other organizations.  You can search through their directories, find the details for each program, and submit your bug reports through them.  They essentially act as an intermediate for the process.  You’ll even receive payments through them.  Honestly, it makes the whole process much more manageable and easier for everyone.  You can also find a full list of programs (including ones that are not hosted on either platform) here.  But I would recommend using HackerOne or BugCrowd to get started and familiarize yourself with the process of submitting bug reports.

Now comes the daunting part.  How do you get started?  We’ll cover a few things to help you get moving in this post:

• Scoping and Recon
• Bug Identification
• Exploitation and Severity

So put on your Boba Fett masks (or Dog the Bounty Hunter sun glasses, I won’t judge) and let’s get started.

Scoping and Recon

This is probably the most important part of the entire post.  Properly scoping your target organization will lead to more bugs identified and less time wasted.  The first thing you’ll want to do is read the program’s scope.  Some programs will be specific about the domains that they would like researchers to focus on, others may be more board.  For example, Telsa’s scope is shown below:

I like these types of programs because all sub-domains for their websites are included in scope.  It gives you plenty of attack surface to research and opens a lot of doors for possible vulnerabilities.  It’s also important to note that their are a couple of sub-domains that are out of scope, and any testing should be avoided on these applications.

Now that we know what the scope is, how do we go about finding these all these sub-domains?  I would recommend starting off with Virus Total.  Virus Total allows you to search a top level domain and get a list of sub-domains associated with it.

Now we have a solid list of sub-domains to start off with.  I’ll usually get Burp Suite running and turn spider on as I check each sub-domain that looks interesting.  Burp Suite’s spider tool is absolutely necessary when doing your recon work.  It will pick up plenty of URLs that could easily be overlooked while you’re doing your searching.

Another tool I would recommend is Knockpy Subdomain Scan.  Knockpy is a Python script that will brute-force possible sub-domains from a word list.  It uses a default word list of roughly 1800 common sub-domains, but you can download and utilize much more extensive  lists if you’d like.

Now that you have some potential targets, content discovery will be your next step.  There are a few tools I’ll recommend.  The most valuable (and surprisingly obvious) is Google.  That’s right, good ol’ Google search.  Using Google search operators like site or inurl we can fine tune our searches to discover hidden content or functionality.  Give the following Google search a try and tell me what you find:

site:teslamotors.com filetype:txt

In regards to Burp Suite, spider is going to be your best friend.  Just make sure that your scope is set correctly so that you’re not wasting time spidering unneeded domains.  Also, intruder is completely necessary for directory brute-forcing.  Download the SecLists repository, which has plenty of lists to discover content across multiple platforms.  If you have Burp Suite Pro, I highly recommend utilizing the Reflector extension.  This will show you any parameters that are reflected into the responses as Burp is spidering.

Finally, don’t forget about those nifty little FireFox and Google Chrome extensions.  Wappalyzer is a browser extension that will identify what an application is built on.  Why waste time brute-forcing Apache relate directories when the application is running on ColdFusion?

Take your time with your recon and pay attention to Burp Suite’s site map tab.  If there’s an interesting domain, clear your spider’s queue and spider that domain specifically.  Finding a bug on the program’s flagship application is prestigious, but think about how many researches have combed through that website.  Spend your time wisely, and look for those forgot sub-domains that run a vulnerable version of Apache or haven’t had an update since 1999.

Other Tools

• Shodan.io (check out our tutorial)
• OWASP Dirbuster (now part of OWASP ZAP)
• Censys and DNSGoodies

Bug Identification

So now that the hard part is over, we can get the party started.  Many common vulnerabilities will be in scope, but it’s still important to check the program’s exclusions.  For example, many programs will accept open redirects as bug that is in scope, but Telsa’s program excludes these.  We obviously want to avoid wasting time testing for vulnerabilities that won’t count in the end.

Let’s be honest, cross-site script is still a disease across many applications.  BugCrowd reported that cross-site scripting account for 66% of valid bug submissions (excluding uncategorized reports).  This comes as good news and bad news.  The good news is that there are plenty of bugs for you to hunt down.  The bad news is that even after all this time, we STILL can’t properly handle user accepted data.

Reflector is going to be your best friend while hunting for cross-site scripting.  It’s a Burp Suite extension that shows you which parameters are reflected back into the response.  Unfortunately, it’s a pro extension, but if you have some Java/Python skills, consider making a version for yourself.

The SecList repository also has plenty of test payloads for fuzzing parameters.  It’s an extremely thorough list, covering all types of vulnerabilities.  Even if you’re not using Burp Suite’s intruder, the repository is still a useful resource for gathering ideas on possible payloads.

Alright, so then there’s this thing called PunkSpider.  It’s a global web application vulnerability search engine.  Yeah, you read that correctly.  Don’t get too excited though.  PunkSpider is pretty cool to play around with, but it’s not as in-depth as you’re imagining.  You also can’t use wild cards in your searches, making it a pain to search for multiple sub-domains.  But there’s no harm in taking a few minutes to look around.  Who knows, maybe you’ll get lucky?

For the love of the cyber security gods… do not forget about those platform specific vulnerabilities.  Imagine you’re a system administrator working in one of these large corporations.  You’ve got hundreds of domains to keep up-to-date on security patches, and your under-budgeted team is just smiling through the tears as you patch and pray.  You’re gonna miss a patch or two at some point.  If you know the version of Apache, look up some related CVEs.  Shodan Exploits can be extremely helpful with this as well.

Other Resources

• HackerOne publicly disclosed reports (SUPER helpful)
• BugCrowd Resources
• Follow Bug Bounty Hunters on Twitter

Exploitation and Severity

I’m not going to spend too much time here.  After you’ve proven that a bug exists, the final step is to show what level of severity is associated with it.  As you may have assumed, this is where people get themselves into trouble.  Just because you have a valid SQL injection vulnerability, that doesn’t mean to need to dump out the entire database into neatly organized CSV files.  Organizations just want to know that the bug is actually exploitable.  As with the previous sections of this post, read the terms and conditions.  It’s important to describe some scenarios of exploitation.  The more severe a vulnerability is, the higher the reward will be.

Let’s say you have a reflected cross-site scripting vulnerability.  Some good exploitation scenarios would be:

• Stealing session cookies (check the HTTP Only flag on the session ID)
• Hooking the victim’s browser using the BeEF Framework
• Facilitating CSRF
• Web site defacement

Take some time to educate yourself on how the vulnerability has been exploited in the past and see what works for your scenario.

In the case of more serious vulnerabilities (such as SQL injection or remote code execution), some programs will explicitly state what they would like you to do to prove the vulnerability.  Do not go beyond those limits.  In the case of a privilege escalation or authentication bypass, keep in mind that you are on a production system and you could compromise the integrity of user data.  Create multiple user accounts to test access controls.  Remember that we are ethical hackers (and jail isn’t a fun place).

Once you have all your evidence, all that’s left to do is write up your report.  BugCrowd has a nice form to fill in that specifies all the required information.  HackerOne has more of an open format, but you can view publicly disclosed bugs to get an idea of what a good report should look like.  Check out this blog post from BugCrowd about how to write a great vulnerability report. Remember that the quality of your reports will determine the quality of the response.

A huge part of bug bounty hunting is being able to learn along the way.  I can’t describe how much I’ve learned just from diving into possible vulnerabilities.  Don’t be afraid to Google everything.  Good luck and happy hunting!