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.
Depending on the target you get different scope types. This will also determine what tools you will need.
|Ip Address||Single-address 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.
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.
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.
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:
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:
Unvalidated redirects could redirect the user to an unwanted URL
Als last the OWASP open redirect cheat sheet:
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:
How do we test for these bugs:
Tools for automating: