Bug Bounty Hunting: Starting with the Basics
When I begin a bug bounty hunting session, I start by reviewing the program’s details to find something with a good scope. Sometimes this means targeting a wide range of assets, like a wildcard domain, while other times, the target may have only one application in scope. For wildcard domains, I typically automate most of the attack surface management using Bash and Python scripts. The time saved through automation allows me to navigate the main application like a regular user and search for interesting features. This process involves creating multiple accounts, testing the signup/forgotten password functionality, and extensively intercepting requests with a proxy like Burp Suite or Caido. This manual exploration helps me fully understand the application and its configurable elements—a process I also apply to any subdomains I find.
Directory Fuzzing: An Essential Technique
Another powerful technique is directory fuzzing, also known as forced browsing. My goal is to enumerate all possible paths and endpoints on an application. For this, I usually use a tool like ffuf, with the following syntax:
ffuf -c -u https://target/FUZZ -w /root/Wordlists/directory.txt -mc 200-c: Colorize output-u: Target IP or URL-mc: Match HTTP status codes-w: Wordlist
One prerequisite for running this tool is to have decent wordlists on your host. There are many sources for wordlists, including:
I recommend finding wordlists you like and combining them to create new lists. Keep track of all the endpoints and interesting elements you find on other targets, and append those findings to your all.txt file. Another technique I’ve used is creating custom wordlists by scraping the HTML source of a website.
Practice Makes Perfect
A good place to practice fuzzing is http://ffuf.me/. There, you can download wordlists to use against the publicly available target.
For the first example, we’ll do basic content discovery at http://ffuf.me/cd/basic. I’ll run the following command with the goal of finding additional content on the web application. I’ve downloaded the wordlists onto my system and will reference them in the scan.
ffuf -c -w ~/wordlists/common.txt -u http://ffuf.me/cd/basic/FUZZ 
As you can see, we found the class endpoint and development.log. Utilize http://ffuf.me/ to better understand the tool and the process of fuzzing.
Tales from the Field – Bounty Edition
I’ve found quite a few security vulnerabilities through fuzzing. While it doesn’t always yield a vulnerability you can submit, it often reveals what I call “crumbs”—small details that help you assess an application more thoroughly. For example, you might find error codes, configuration files, images, or default settings.
In one instance, I conducted extensive subdomain enumeration on a target’s wildcard domain and found multiple URLs to test. I scanned the target using ffuf with a custom wordlist and uncovered sensitive information, including an exposed phpinfo() file that revealed PHP server credentials and an AWS Access Key with its secret. This find earned me $2,500 and was relatively straightforward.
To demonstrate more impact, I input the AWS credentials into Enumerate IAM, a tool that provided all the roles and attached policies associated with the key. Often, this is enough to prove significant impact for a high or critical exposure. I have several other examples to share in the future, but I wanted to explain how I use ffuf and how effective it has been for me.
Important Takeaway
Directory fuzzing is a basic yet essential tool in a web application tester’s toolkit. While it may not always reveal a direct vulnerability, it can lead to discovering crucial information that aids in your overall assessment. In one case, I was able to help secure a product that I interact with daily, contributing to the security of the organization.
Thanks for reading!