Most crawlers and brute force subdomain scanners use some lists for checking the existence of files, respectively subdomains that otherwise are not linked or cannot be found by examining the existing visible data.

But you have websites that are focused on a particular area (financial, social, administrative etc). And a word like “game” is less likely to be a subfolder or subdomain of a banking application. A more likely subdomain or directory in this case is “payment”.

In the same time you might need to test a website that primarily uses  a non-English language and if you use an English wordlist you might not be so successful. For example “geschaeftskunden.telekom.de” would probably not be found by such a list.

Of course, in any application you might have “likely” words like “admin”,”api”. But this is another category which is dependent on the platform and not on the content.

So I suggest using a wordcounter to help creating a list of reasonable words from the content of the root website for example.

Here is the list of words I quickly got from pasting http://www.paypal.com into http://www.wordcounter.net/ :

Some of the usual conversation words might appear, but mostly it’s very relevant. And the website has almost all these words, at least as a subdomain or a subfolder.

Of course, lists that are based  on other criteria like CMS or other open source applications that might be used (“/misc/drupal.js” or “wp-admin” or “jira” etc) are something different. You need to check those too.

Because you cannot test a very high number you need to optimize based on context .And the content of the application is a very important variable. The content can be (one example ) reduced to keyword density (maybe filter the junk a little).  And this keyword density can be used as a wordlist.

I think I found the best way to utilize the exploratory testing in security bug bounties. Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. Bug hunting has no rule in finding bugs (there are the rules of conduct, reporting, rewarding – but no one tells you how you need to find the vulnerability).

First you learn about what is a bug bounty program, you learn what companies offer these bug bounty programs, what areas are covered, you learn some technical things specifically to security etc. Then you create your own steps to find the issues. You visualize possible vulnerabilities by just “looking around” and design future actions. You then execute what you have designed (mentally or what you have written down) in your own way. Sometimes you just try manually some things, you might use scanners, you might use complex actions.

One of my favorite approaches is to reduce the messy BB(bug bounty) world (numerous vulnerability programs, areas, bug type) into simple puzzles that I have to solve.

Sometimes you get a little bit bored, like with everything, and  that’s why you need to switch to other ways to find issues, learn new stuff to keep motivation.

Overall I thank all the companies that started these vulnerability reward programs. Some are better than others depending how you measure it and what is your personal experience with it. Its a great opportunity for many out there to test themselves, earn some cash, use a broad level of skills that in a normal job maybe you can’t and just have a little fun.

I did a trip to LA, San Francisco, San Jose, Las Vegas and New York. Too much to mention, but overall I loved it a lot. Nice cities, nice people everywhere.
Highlights of my trip were the visit to Paypal in San Jose, Defcon and the skydiving session in Vegas.
Just sharing some photos, hard to do massive upload of high quality photos..

You may want to start testing for bug bounty programs, you have a couple of hours, but not that many ideas in the beginning.

One tip that I recommend is to decide what BB you wanna approach and then get a list of bugs that you know were rewarded in the past. Then try to find similarities between these bugs and write it down.  It’s good to take two bb programs so you can de-focus, get different perspectives. Also it will reduce the frustration when you don’t find any bug if you focus only in one area/BB.

So for what I described above I do for example:

1) Get a list of 10 bugs (as recent as possible) rewarded by Paypal (make sure these bugs are in scope too, because changes in the rules are often). In this particular case I sent often bugs to Paypal therefore  I will use bugs from my own submissions

2)Get a list of 10 bugs from Google. Although I was rewarded a couple of times by Google is not my most  comfortable BB program. So here I just Google it or look in other people’s blogs

Only these simple steps will help because:

• you get a little bit organized
• you can find a common ground to what was rewarded actually and you can focus on those areas and those types of bugs
• if you lack skills (in security) it’s easier to find a similar bug (even if you don’t fully understand in-depth what it means) ; so basically you are a “repeater” of “duplicator” but that bug will be considered new nevertheless
• just looking at the common elements of those bugs and at the elements that are distinct, again many ideas can come out of it
• a limited number of bugs to have in front of you its better for the focusing than all your bug submissions
• you can decide if you are bored and need to look for other areas and other type of bugs
• and a lot of other things that go into your head that are not conscious will be of much help

I see many examples of rewarded bugs with final POC, or some description on a tool or some article on how someone found a bug etc, but not discussions about approaches in security bug bounties.

Like WHERE do you start from in looking for a vulnerability, WHEN do you try certain stuff and other stuff, WHAT do you look in a certain area, WHY do you do a specific action?

The final POC might be enough for the  submission report, but it doesn’t tell that much on how you find it. You can get some ideas, but vague ones.

I don’t think it’s only that all bug hunters  want to keep all their secrets. I believe they wanna share, but don’t know how. Also they don’t care about that much about the approach or identify it as a vital part.  And even if you wanna keep some stuff, which is normal in any field, you still have a need to discuss with others about something you are not so sure about.

Here are some topics I would propose to look at:

• 80–20 rule or the Pareto principle We spend days where we don’t find anything, yet other times in 5 minutes we find very critical bugs. Is the time spent good enough with the rewarded bugs? Is it a complete random? The 80 percent of the time when we don’t find anything is a total waste or an important part of resource and information gathering?
• They say that 1% (or 10%) of the bug hunters in a bug bounty program get 99%(or 90%?) of the whole rewards. Do you agree with that? Do you think is universal? Why do you think that its happening?
• Regression testing ( or looking again in area with reported bugs or fixed bugs) does it have a higher chance for new vulnerability findings?
• Context and how different applications require different approaches, tools, skills
• Organizing yourself. Is it good to be very organized, or messy, or an alternation of messy and organized in this field?
• What is the best bug type to look for so you can get the most out of the time spent. Is it XSS?

And there would be more topics, but the examples given hopefully should give an idea on what I wanna say.