Bugbounty Checklist

March 15, 2019


I was interested in hacking and security from the age of 15, that's almost 20 years now. And always learned new things that interested me. One period I learn more about hardware, Raspberry and Arduino and another about buffer overflow exploitation. Next periods I learn a new programming language, and then more about web security. Because Hacking is such a broad field I never felt like a hacker.  In my eyes, a hacker was always somebody that could write exploit code, spot a vulnerability from miles away and do all this in the command line.
So my journey continued. I got the CEH certificate, learned some more but still, I won't call myself a hacker.
Now I'm at a point in my career where I want to invest more time actively practicing what I've learned over the years. And this brought me to bug bounty programs. I am a member of 2 for a couple of years, but never really searched for bugs, as it was a bit overwhelming at first.
Now I feel confident and going to participate in the community and the programs.

This post is a checklist mainly for me to test a target. In my mind, there is so much to test, and if you're new to bug hunting, you easily forget something that could lead to a bounty. Bug hunting is competitive, but yet a nice community that likes to share, and I want to be part of that.


Scope Types:

Depending on the target you get different scope types. This will also determine what tools you will need.

*.domain.com Full-domain scope
sub.domain.com Sub-domain scope
Ip Address Single-address scope
Application Application scope



Believe it or not, it all starts here. I have read so much content on the internet, watched video's, did CTF's and it all comes down to good and thorough reconnaissance. If you go in blind you certainly missed something. Everywhere I read it is the same, 85% is recon, the rest just using what you discovered.
First of all, document your findings and take screenshots. Organize them and take notes of everything you discover.


First, we do passive recon to see what we can find on the internet. Here is a list of resources for this:

Resource Link Description Scope Type
https://www.shodan.io/ See if there are entries in the Shodan database. Full-domain
https://crt.sh/ Check for certificate information. Full-domain, Sub-domain
https://dnsdumpster.com/ Look for DNS entries Full-domain, Sub-domain
http://dnsgoodies.com/ Collection of DNS tools Full-domain, Sub-domain
http://www.visualsitemapper.com Visual map a website. Sub-domain
https://web.archive.org/ See if there are older versions of the site. Sub-domain
https://github.com/michenriksen/gitrob Scanning GitHub commits history of user or company. Full-domain, Sub-domain
https://github.com/dxa4481/truffleHog Same as above, a GitHub crawler. Full-domain, Sub-domain



Now that we have the basics, we can proceed to actually do requests to the site ourselves. Here we will scan the information we found with the passive recon more in-depth.

https://github.com/1N3/Sn1per A full automated recon and testing tool. Full-domain, Sub-domain
https://bitbucket.org/LaNMaSteR53/recon-ng Web Reconnaissance framework is written in Python Full-domain, Sub-domain
https://github.com/michenriksen/aquatone Another web recon tool. Full-domain, Sub-domain
https://github.com/aboul3la/Sublist3r Scan for subdomains. Full-domain
https://github.com/jobertabma/virtual-host-discovery Finding VHOSTS. Full-domain, Sub-domain
https://github.com/sandrogauci/wafw00f See if there are protections in place. Full-domain, Sub-domain
https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project Brute forcing of web directories. Full-domain, Sub-domain
https://github.com/jobertabma/relative-url-extractor Get paths from JS files. Full-domain, Sub-domain
https://xsser.03c8.net/ Cross-site scripting scanner. Full-domain, Sub-domain


After all these findings don't forget to do a simple portscan on the hosts you discovered, and don't just scan for regular ports.
What I sometimes struggled with was finding good wordlists. Here I discovered a project that collected and structured all sorts of lists.


Structured Documentation:

Now that you have all this information it's important to structure and sort it out a bit. Some of these tools will get duplicates, and one tool will find more than the other. So filtering this information will benefit you later.


Techniques to test:

This will be the description mainly for myself so I don't forget to test anything.
When you got all your recon done and got the endpoints, we can start testing for vulnerabilities. Let's Go.


    XSS ( Cross-Site scripting ):

One of the most common bugs in a web-application are Cross-site scripting bugs. These bugs are usually quickly discovered by researches.

Type 0 DOM Based XSS XSS where the entire tainted data flow from source to sink takes place in the browser
Type 1 Stored or Persistent XSS Occurs when user input is stored on the target server. And then a victim is able to retrieve the stored data from the web application without that data being made safe.
Type 2 Reflected or Non-Persistent XSS Occurs when user input is immediately returned by a web application, without that data being made safe.

Tools to use when searching for XSS:

xsser https://xsser.03c8.net/
owasp zap https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
XSStrike https://github.com/s0md3v/XSStrike


When writing a PoC the best practice is always use alert(document.domain) instead of alert(1). This way you are shute that it comes from the correct domain and it will be a valid XSS bug.
Here I have 2 lists of XSS payloads you can use.
Also here the link to the OWASP XSS cheat sheet:


    Open Redirects:

Unvalidated redirects could redirect the user to an unwanted URL
ex. http://example.com/example.php?url=http://malicious.example.com
Look for the following parameters in the url, source and javascript code:

  • url
  • returnurl
  • redirect
  • getParameters

Als last the OWASP open redirect cheat sheet:


    XXE (XML External Entity):

I find this an intresting attack vector, the idea of manipulating an xml supported document or data to exploit your target amazes me.
So what is XXE:
if XML userinput is not correctly sanitized, an attacker can manipulate the data or files to read local server files or get remote code execution.

Where can we find these bugs:

  • fileuploads xlsx, svg, doxs, xml ...
  • POST or GET data that uses JSON or XML parsing.

How do we test for these bugs:

  • do curl requests ( curl -d @xml.txt http://example.com/login.php )
  • Look for out of band xxe ( when you do not get a responce but the server processes the data.

Some examples:

Tools for automating:

  • XXEinjector