Sponsored by

Conference notes: How to Differentiate Yourself as a Bug Bounty Hunter (OWASP Stockholm)

Posted in Conference notes on November 7, 2018

Conference notes: How to Differentiate Yourself as a Bug Bounty Hunter (OWASP Stockholm)

Hi, these are the notes I took while watching the talk “How to Differentiate Yourself as a Bug Bounty Hunter” given by Mathias Karlsson at OWASP Stockholm.


This talk is about how to differentiate yourself from the crowd, to ensure that you are successful at doing bug bounties.

Bub Bounty Effectiveness

  • Bug Bounty Effectiveness (BBE) formula:

  • 3 underrated ways of achieving BBE:

    • Effective recon
    • Golden goose bugs
    • Collaboration

Effective recon

Proactive recon (enumeration)

  • What Mathias does before he starts working on a program
  • It’s the enumeration of all assets & functionalities included in scope
  • Assets can include subdomains, stuff from open source intelligence, virtual hosts, web services, specific paths, the developers’ Github accounts (=> information on how the backend works)
  • Why?
    • More known assets = More code to test = Increase bugs found
    • Things enumerated that are harder to find = Decrease risk of duplicate
    • Things harder to use/understand = Decrease risk of duplicate
      • Most bug hunters discard them because they are intimidating
      • Examples:
        • Learn new technologies like Graphql
        • Get & test the pro version (paid)
    • Automation = Decrease time spent
      • Automate everything you can
      • It doesn’t have to be good, as long as you understand how it works
      • Can be a Bash script that calls a bunch of Perl or Python scripts
      • You don’t want to do anything in your recon process manually more than once

Reactive recon (monitoring)

  • Always do all the programs that you’re invited to
  • Automation will allow you to detect changes in assets
  • Why?
    • Big change in known asset = Decrease risk of duplicate
    • Asset changes = Decrease risk of duplicate
      • If you find an IP or subdomains with no port open, move on but continuously monitor them, in case a new service becomes available
      • You’ll know even before the program notifies hunters of the change, on bug bounty platforms
    • Visualisation
      • Take a screenshot of the web service & push it to Slack
      • Will allow you to find bugs just by scrolling through screenshots, even when you’re tired/not motivated

  • Bonus: Accidental bug find

    • E.g.: Server with 404 error on the main page. Directory bruteforce => Just sending GET /shudown shuts down the server (Denial of service, $12,000)
  • During your recon process:

    • Collect your data creatively
    • Monitor your data carefully
      • Don’t dismiss the data you’ve collected once because it might become valuable even if it’s not now
    • Don’t forget to store it
      • Most important point!

Recon blindness

  • Common issue among bug hunters
  • It’s when you do recon for hours & end up so tired that you don’t have energy left to test for bugs
  • Finding more info on a target is a never-ending process:
    • /admin
    • Web archive
    • Mail server
    • Shodan
    • Censys
    • Subdomain
    • Old software version
  • Recon is a means to an end
  • Data is useless unless you find bugs with it
  • Recon is super fun but don’t over do it, finding bugs is the goal

Golden goose bugs

  • So you can start doing research on a subject in the few hours you have here and there until you find one of these bugs, then look for it on bug bounty programs


  • Seems like a bad idea since you’re splitting the bounty money with someone
  • But it’s not the case because when you collaborate with someone:
    • Time spent is multiplied by 2
    • You can cover different grounds & do not duplicate each other
    • You generally find more bugs & bugs that you wouldn’t have found by yourself


  • It’s more fun
  • You make friends


  • It’s easy to become jealous & envious of others (My bugs!)
    • Work on it because if you can overcome that, you’ll benefit from the positive side of collaboration
  • I found more bugs than you!
    • Be very clear on the terms of your collab before starting
    • He recommends splitting the bounty 50/50 because:
      • If you still feel it’s unfair, pair up with people with the same competence as you
      • Or pair up with someone with less competence than you & view it as an investment to get them to the same level as you
    • Change “I found more bugs than you” to “We found more than any of us could”
    • If you can’t you’re not ready for collaboration


Note: I’m paraphrasing here, not reporting exact quotes…

  • Q: Have you ever hit backlists when monitoring targets & got yourself blocked out because you were monitoring too hard or too often?

  • A: My monitoring is very gentle. It happens but not often. I don’t run tools like Nessus. I only send a few HTTP requests per day. They’re spread out over time

  • Q: [not clear, I understood something like: can you still hack a target even if they’re using a WAF?]

  • A: WAFs are really good at blocking automated attacks but not manual ones. If I detect a WAF, I either give up because it’s a waste of time or figure out a way around it. Many times, it’s possible

  • Q: Do you do recon against the employees of your target? For example, trying to figure out what their programming style is based on what they published on public personal accounts

  • A: yes, that’s what a real attacker would do

  • Q: Did you ever go out of scope & make someone upset?

  • A: It’s happens but accidently. Programs are pretty understanding, I never got into real trouble

See you next time!