AMA with @bbuerhaus

Thank you for doing this interview! Can you please introduce yourself?

My name is Brett Buerhaus. I usually go by the handle bbuerhaus for everything security related but my online alias has been ziot for a long time. I currently live in California in the US.

I got into web development as a hobby when I was about 10 years old. I started with managing online forum communities and creating modifications for them. I discovered my first critical security vulnerability (remote code execution) while reviewing the phpBB source and quickly discovered that I had a love for application security. I’ve been hacking for around 15 years now.

I started with the Facebook and Google bounty programs. Nowadays I mostly hack on HackerOne, but I’ve also spent some time on Bugcrowd, Synack, and Zerocopter.

Q: How do you manage your personal life, work, and bug bounties? Do you do bug bounties as a job or a hobby?

I currently have a full time Red Team job with past roles in game security, web penetration testing, and application security.

It’s a lot of late nights staying up until 3 AM to stay active in bug bounty

Bug bounty is a part time hobby of mine, somewhat for the money but mostly just to stay relevant. It’s a good opportunity to see how other companies operate. I get to look at applications/infrastructure I might not see at my company. This helps me be prepared for anything I might see in the future or may have overlooked in the past.

Q: How much time do you spend on Hunting for Bugs? On average, how many bugs do you think you report per month?

On average probably 2-3 hours a night during the week, definitely more on the weekends. I aim for 10 decent bugs minimum a month with at least 1 critical a month. I try not to go for number of reports and instead look for interesting vulnerabilities.

Q: How long did it take you until you found your first significant/high impact/payout vulnerability?

I found a decent XSS on after my first few months of hunting in bug bounty that paid a fair amount.

Q: Of all the bugs you’ve found, what was your favorite/most interesting?

There was a target on Zerocopter that had been around for awhile and no one had submitted anything to them. I challenged myself to hit all of the active programs on ZC that I was invited to and see if I could close them out. I struggled with this company for a day or so and could not find a single vulnerability.

I decided to dive a bit deeper and found hints of the CMS they were using. Looking at some of the JS files, I discovered some keywords that led me to believe they were using the framework I kept digging through the JS files and discovered a dev endpoint that had a textbox on it.

After a bit of testing on it, I discovered that it evaluated Viper script code for the Seneca framework to determine if the code was valid or not. Spending a few hours on their docs, I discovered methods to get responses out via response headers. Using that I was able to get the full filepath out. I was able to achieve remote code execution using a function to write code to files on the box once I knew the filepath.

This one was particularly fun for me because I went into it blind, had to research a new framework, and made wild assumptions that paid off in the end. This embodied everything I love about bug bounty hunting.

Q: When and how did you have your breakthrough? When did you realize hacking and bug bounties was something you wanted to dedicate your time to? Please share your insights and the problems you faced to become established Bug bounty hacker?

I already had a past in security and hacking, so none of this was new to me. Hacking has always been a hobby of mine, so getting involved in bug bounty just seemed natural.

The first time I heard about bug bounty was through Facebook’s bounty program. One of my friends linked it to me and I wasn’t aware bug bounty was a thing at the time. I assumed finding a decent vulnerability on Facebook would be a really difficult challenge. I told myself the best hackers out there are probably looking and I wasn’t sure how I stacked up against them.

I spent a month or so looking without finding much. This was probably the biggest hurdle I had getting into bug bounty, but it was not something foreign to me due to my past in security. The vulnerabilities usually exist even if you aren’t finding them. Persistence is the key to succeeding, you just need to keep looking and not give up. I eventually landed on two decent vulnerabilities within the same hour.

It was such an adrenaline rush to finally find something after failing for awhile. I really enjoyed the feeling of the hunt and the rewards you gain from it. This is what made me dive into Google’s program next. Finding a vulnerability on both Google and Facebook hooked me in and made me realize I could do this.

Q: What do you do to keep up with all the new trends?

Primarily Blogs, Slack, and Twitter. The security and bug bounty scene have been great at sharing everything. Building a strong network of people in various niches of the security industry usually means getting coverage on everything interesting.

Q: Do you collaborate with other hackers? Can you name a few?

I collaborate with @nahamsec almost entirely. I occasionally seek insight from smart people like @patrikf, @smiegles, and @jobert.

I could list dozens of people that have helped me out at one point or another in the past year alone. One of the great parts about the Bug Bounty Forum slack is that everyone there is happy to help you if you ask.

Technical Questions

Q: How do you approach a target? What is your routine like? What is your recon process like? What kind of information do you seek in your information gathering process? And how does this information help you? (topics to talk about: Dir bruteforcing, Subdomain bruteforcing, nmap, google dorks, etc).

I covered my methodology from a high level on Bugcrowd’s blog: -

My initial recon process involves collecting a list of servers, subdomains, open ports, and services running on ports (banners).

Initial Recon:

  • Searches
    • Google dorks
    • Collect a list of subdomains (slowly removing them with “site:* -subdomain”)
    • Collect a list of endpoints (slowly removing them with “site:* -/path”)
    • Look for specific extensions (“site:* ext:swf”). This helps with quickly seeing if they have cfm, php, asp, etc. It also helps identify interesting endpoints quickly.
    • Github/Gists (Code committed or pastes posted by devs with info pertaining the domain)
    • Public/Private APIs and API keys
      • Sometimes you’ll find “private” 2nd or 3rd party APIs. You are less likely to find a company like Uber to make a mistake, but partners they work with are more likely to mess up.
    • Secret keys
      • These can sometimes lead to RCE depending on the frameworks being used.
    • Subdomains / Internal subdomains
      • Useful if you find a SSRF vulnerability and need an example to check if you’re on their internal or prod environments.
    • Employee credentials
    • Pastebins (There are many out there, not just
  • Subdomain tools
    • Recursive dictionary wordlist scanning
    • Check if zone transfers are enabled
  • Cert parsing
    • Facebook and Google both have cert transparency tools
    • Parse certs on IPs within their company CIDR ranges
  • Ports/Banners
    • Nmap (nmap banner plugin is great)
    • Censys/Shodan
  • IP/CIDR Ranges
    • All of the IP registries such as ARIN
  • Domains
    • Reverse domain lookup sometimes depending on how the sites are hosted
    • Check domain registry info to see if all domains have a commonality between them such as a registration address or email. This makes finding other domains fairly easy.

I initially look at what services are running before I dive into applications. You can sometimes come across services such as dev panels, unauthenticated Jenkins, ElasticSearch, etc. These are all services that lead to quick wins after you have some experience finding them.

Once I have a list of websites, I’ll start to look for:

  • Repository files (.git, svn, etc)
  • Robots.txt / Sitemaps
  • Frameworks (Wordpress, Joomla?) - I wrote a script to look for common files such as readmes, favicos, template files, etc. There are many ways to identify
    • Once identified, I’ll look for:
    • Version number (known vulnerabilities)
    • Custom code such as changes the company has made or 3rd party plugins they’ve installed. You’re more likely to find vuln code in a lesser known poorly written plugin than code written by a decent engineer.
  • JS Files/Libraries
    • I almost always look for what version of jQuery they have. Older versions may be vuln to easy XSS if user input is in selectors. This will change how I review their JS files.
    • AJAX calls to discover endpoints that may not be implemented or admin specific. I have found many vulnerabilities this way.
    • Sometimes you will find JS files for a library like CKEditor. They may not use any other files from the lib, but they uploaded them all anyways. These libs may contain files with known vulnerabilities ranging from XSS to RCE via file uploads.
  • SWF files (low-hanging XSS)
    • Easy to decompile custom SWF with tools like and relatively easy to quickly find if they’re vulnerable to XSS.
    • A lot of sites usually have out-of-date swf files like jwplayer that have known vulnerabilities.
  • APIs
    • I tend to spend a little bit extra time on APIs to see if they have API docs or Swagger built into them.

At this point I feel comfortable enough with the information collected and will dive into the web applications to start hunting for vulnerabilities.

Q: Do you always look for all vulnerabilities types when you approach a website?

Initially, yes.

As I learn more about the target, I may find that certain vulnerabilities no longer make sense. E.g. If I determine that the templating is Django and I have ruled it out for vulnerabilities, I may no longer be interested in template injection. If it’s ASP.NET with the built-in XSS detection, I will alter my XSS payloads and instead look for specific types of XSS.

This is why persistently hitting the same target for a long period of time is going to help you find higher severity vulnerabilities. You are going to better understand the target, notice things you missed before, and focus in on certain types of vulnerabilities.

Q: Do you use any tools?

I primarily use tools for reconnaissance as I prefer to do most of my application hunting manually.

One thing I spent a few years working on was building infrastructure to automate kicking off scans, parsing the results, and displaying it in a nice format. At the moment I can just input a domain or IP CIDR and collect subdomains, screenshots of websites, web banners, port data, and more.

I did some really fun stuff with AWS that I don’t think anyone else is doing. I just submit a CFP to Blackhat for it. Hopefully I will be able to share that with everyone soon.

Q:This is one of our most popular questions: How do you test for Server Side vulnerabilities such as RCE, SQLi, etc?

This is a fairly broad question that I think goes back to what I was saying about persistence. Getting RCE on an application can range from template injection, deserialization, auth bypass into admin panels, etc. There are many ways you can achieve it, it’s just a matter of understanding the application and the types of vulnerabilities that can exist in it.

A lot of this comes down to reading and researching that application, language, or framework. If you’re hitting a Ruby/Rails app, there are rails specific vulnerabilities that you may miss if you don’t know anything about rails. There are certain types of nuances in Ruby that you could abuse to find vulnerabilities if you know more about how Ruby works.

Spend time learning about what you are testing, research it, and you’ll find things that others are missing.

For SQL injection I mostly test it manually with simple payloads such as “‘ or 1=’1”, “-1 or 1=1”, “‘+sleep(1)+’”, etc. The initial injection into a SQL query is usually basic enough making discovery trivial, the complexity typically comes from overcoming hurdles while extracting data. This is a good thing to takeaway if you’re struggling to find these kinds of vulnerabilities. Don’t rely on tools like sqlmap or crazy polyglots. You’re going to miss vulnerabilities if you’re passing in strings without understanding why they might be failing or why it might be getting blocked by a WAF or application.

Q:How often do you find a bug that has been overlooked after a bounty program has been established and a horde of researchers have been digging?

I think most bug bounty hunters can say they do this regularly because most programs, even private ones, are going to have a handful of solid hackers on them. I don’t think you should ever approach a program with the mentality that you are not going to find anything because other people have looked first. You should always go in with the mentality that it doesn’t matter how many people have looked at it.

Regardless of rank or skill, some researchers are going to be better at finding certain types of vulnerabilities than others. It’s very possible to find something low-hanging and obvious that a decent hacker missed.

Also keep in mind that big companies are pushing out code changes on a daily or weekly basis. They are also pushing out patches for all the vulnerabilities reported. Vulnerabilities will come with code changes. You can find vulnerabilities that may not have even existed when the hordes were looking at the program.

Q:Do you think being a pentester, web developer, or being in a related field, helps you with bug bounties? Where should they start?

I think it’s essential to approach hacking from the technical side if you want to be good at it. I spent some time putting together training courses for people to get involved in bug bounty. I quickly learned that it’s hard for people to grasp web vulnerability concepts without a basic foundation in web development.

My recommendation is always the same to people new to web hacking. Learn the basics of web development and program all the vulnerabilities you learn about. Look into how people are exploiting the vulnerabilities and reproduce it in your sandbox. Spend some time learning how to fix them. Once you have built the vulnerability, played with it, and fixed it, you’ll have a decent grasp on what to look for in the wild.

All of these things are essential for understanding how a website is responding when you start manipulating requests. A vast majority of the time you aren’t getting meaningful responses. If you are triggering a generic 500 response, it may mean absolutely nothing to you and you may miss a vulnerability. You need both that hacker intuition and developer experience to make guesses on what is occurring behind the veil.

Having the experience of actually exploiting the vulnerability will help you better understand the true severity of an issue and deliver quality reports. You never want to undersell or oversell a vulnerability - providing proof-of-impact and an explanation of it can lead to higher payouts.

Time to wrap it up!

Q:What kind of music do you listen to?

Depends on the mood, but usually heavy metal.

Q:What do you do when you aren’t hacking?

I think equal to hacking is my love for video games. The constant struggle with my free time is whether to play a video game or hack a bounty program.

Q:What kind of impact/role have bug bounties played in your life?

I think one of the bigger impacts is the doors it has opened for me. I’ve had the opportunity to work with many companies, blog about interesting write-ups, travel to hacking events, and collaborate with a lot of researchers. Some of the companies I have reported to have even expressed interest in hiring me. Bug Bounty is a great way for people new to the industry to break into it.

Most importantly, it’s helped provide me with enough additional income to buy my first home in SoCal. As much as I do this out of passion and interest for hacking, I also do it to provide for my family.

Q:What is an advice you received as a beginner that helped you with your bug bounty career?

Writing a high quality report is almost as important as discovering the vulnerability itself.

If you don’t provide enough information, have a bad attitude, or don’t demonstrate impact, you may not get the reward you deserve for the effort you put into it.

Assume that you are reporting a vulnerability to someone that doesn’t understand the issue or the impact. Question whether you would understand the report without knowing the application at all. Provide enough information that it is easily reproducible the first time they walk through it. You can relax on this a bit as you grow a stronger relationship with the team and know what they expect from the reports.

Q:What is one area of hacking you wish you knew more about / plan on focusing your learning on?

I wish I had spent more time learning assembly, binary exploitation, and reverse engineering when I was younger. It’s a skill that requires a steep time investment and has a lot of depth to it. I don’t have as much time now as I used to!

I plan on spending more time on this area because I find browser hacking super interesting and it would be fun to build a fuzz farm.

Q:If someone with basic technical background asked you, “where should I start?”, what are 3 things you would recommend they do before diving into bug bounties?

1.) Earlier I talked a bit about programming vulnerabilities in a sandbox. I recommend this as the number one thing to do before you start hunting for them. Get a strong grasp on the technical details. A good hacker is almost always a good programmer.

2.) Try to discover and exploit vulnerabilities on your own before seeking help from others. This is an industry where there is strength in finding solutions to your problems. Most of your questions early on will be answerable with a single Google search. It doesn’t hurt to ask for direction, but it may hurt to have people handing you all the answers. You will eventually get to a point where you may have no one to ask and need to rely on yourself.

3.) Read write-ups from public vulnerability disclosures. Seek blog posts that tell the entire story, such as how they discovered the issue and not just the vulnerability itself. Getting a narrative from successful discoveries will help you find what people looked at and why.

Q:Someone was eager to know, what do you put on your toast?

Toast? I’m all about that bagel life.

Q:What’s your worst bug bounty story/experience? (Please do not mention a customer name or platform in your answer)


Q:If you had to pick one hacker to collaborate with, who would it be?

Given the chance, I would love to sit down and work with filedescriptor and see how he tackles the discovery of JavaScript vulnerabilities. There are times when I’ll be trying to reverse through obfuscated JavaScript on Google and give up because I’m overwhelmed. Getting some insight into his processes would be a great experience.

Q:What’s the one feature you would like to see in the platforms?

Collaborative reporting so that multiple researchers can be on the same ticket. There are times when I’ll discover a vulnerability with a friend and only one of us will get the rep/recognition for it.