This chapter covers web fuzzing techniques specifically for directory busting (dirbusting) and parameter discovery, which are critical for reconnaissance enumeration in the PT0-002 exam. These techniques help penetration testers uncover hidden resources and parameters that may expose vulnerabilities. Approximately 10-15% of exam questions touch on web application enumeration, with fuzzing being a core skill tested under Objective 2.2. Mastering these concepts is essential for the Reconnaissance and Enumeration domain.
Jump to a section
Imagine a burglar trying to break into a large office building. The building has many doors: some are unlocked, some are locked, some lead to storage closets, and one might lead to the CEO's office with the safe. The burglar doesn't have a floor plan. So, he systematically tries each door. He has a list of possible door labels: 'Main Entrance', 'Supply Closet', 'Server Room', 'CEO Office'. He tries each label on every floor. For each attempt, he jiggles the handle. If the door opens, he notes it as a vulnerability. If it's locked, he moves on. This is exactly how web fuzzing works. The web application is the building. The doors are directories, files, or parameters. The burglar's list of labels is the wordlist. 'Jiggling the handle' is sending an HTTP request. An open door is a 200 OK response. A locked door is a 404 or similar. The burglar might also try different keys (parameter values) to see if a locked door opens (a parameter that changes behavior). This mechanistic process of systematic enumeration using a predefined list and observing responses is the core of web fuzzing.
1. What is Web Fuzzing and Why It Exists
Web fuzzing is an automated technique used to discover hidden or non-obvious resources on a web server by sending a large number of requests with varying inputs and analyzing responses. In the context of PT0-002, fuzzing is primarily used for two purposes: directory busting (discovering hidden directories and files) and parameter discovery (identifying GET or POST parameters that the application accepts).
The fundamental principle is that web servers often have resources that are not linked from the main interface but are still accessible. These can include admin panels, configuration files, backup files, API endpoints, and more. Fuzzing automates the process of guessing these resources by using wordlists – large collections of common names, paths, and patterns.
2. How It Works Internally
Web fuzzing tools work by generating HTTP requests based on a base URL and a wordlist. For directory busting, the tool takes a base URL (e.g., http://target.com/FUZZ) and replaces the placeholder FUZZ with each entry from the wordlist. For each request, the tool sends the HTTP request and receives a response. It then analyzes the response status code, response size, and sometimes response content to determine if the resource exists.
Common status codes: - 200 OK: Resource exists and is accessible. - 301/302 Redirect: Resource exists but redirects to another location. - 403 Forbidden: Resource exists but access is denied. - 404 Not Found: Resource does not exist (or is deliberately hidden). - 500 Internal Server Error: Server error, may indicate existence but with issues.
Tools like dirb, gobuster, ffuf, and wfuzz implement this logic. They often use multi-threading to speed up the process. For example, gobuster uses the following syntax:
gobuster dir -u http://target.com -w /usr/share/wordlists/dirb/common.txtThis command attempts to discover directories using the common.txt wordlist.
3. Key Components, Values, Defaults, and Timers
Wordlists: The quality of fuzzing depends heavily on the wordlist. Common wordlists include:
- dirb/common.txt: Approximately 4,600 entries.
- dirb/big.txt: Approximately 20,000 entries.
- dirbuster/directory-list-2.3-medium.txt: Approximately 220,000 entries.
- seclists/Discovery/Web-Content/common.txt: About 4,700 entries.
- raft-large-directories.txt: Over 90,000 entries.
Threading/Concurrency: Most tools allow you to set the number of concurrent threads. Defaults vary:
- gobuster: 10 threads (can be changed with -t).
- ffuf: 40 threads by default.
- wfuzz: 10 threads by default.
Delay/Rate Limiting: To avoid overwhelming the server or triggering rate limiting, you can set delays:
- gobuster: -d for delay in milliseconds.
- ffuf: -p for pause between requests.
- wfuzz: -s for sleep time between requests.
Response Filtering: Tools allow you to filter responses based on status codes, size, or regex. For example, in gobuster:
gobuster dir -u http://target.com -w wordlist.txt -s 200,301,403 -x 200This filters to show only responses with status codes 200, 301, or 403.
Extensions: For file discovery, you can append extensions like .php, .asp, .txt. In gobuster:
gobuster dir -u http://target.com -w wordlist.txt -x php,asp,txt4. Configuration and Verification Commands
gobuster:
Directory mode: gobuster dir -u <URL> -w <wordlist>
DNS subdomain mode: gobuster dns -d <domain> -w <wordlist>
Vhost mode: gobuster vhost -u <URL> -w <wordlist>
ffuf:
Directory busting: ffuf -u http://target.com/FUZZ -w wordlist.txt
Parameter discovery: ffuf -u http://target.com/index.php?FUZZ=test -w wordlist.txt
POST parameter: ffuf -u http://target.com/index.php -X POST -d 'FUZZ=test' -H 'Content-Type: application/x-www-form-urlencoded' -w wordlist.txt
wfuzz:
Basic: wfuzz -w wordlist.txt http://target.com/FUZZ
Parameter: wfuzz -z list,http://target.com/index.php?FUZZ=test
dirb:
Simple: dirb http://target.com /usr/share/wordlists/dirb/common.txt
Verification: After discovering a potential resource, verify manually with curl or browser:
curl -I http://target.com/adminCheck the response headers and status code.
5. Interaction with Related Technologies
Web fuzzing often interacts with:
- Web Application Firewalls (WAFs): WAFs may block requests that appear malicious, such as those with many requests or suspicious patterns. Tools like wafw00f can help identify WAFs.
- Rate Limiting: Some servers limit requests per IP. Fuzzing must be adjusted to avoid detection or blocking.
- Authentication: If the target requires authentication, fuzzing may need to include session cookies or tokens.
- Load Balancers: Responses may come from different backend servers, causing inconsistent results.
- API Endpoints: Fuzzing can discover undocumented API endpoints, which are often hidden but functional.
6. Parameter Discovery
Parameter discovery involves finding GET or POST parameters that an application accepts. This is crucial because hidden parameters might control functionality like debug modes, user roles, or file paths. Tools like ffuf and wfuzz can fuzz parameter names. For example:
ffuf -u http://target.com/page.php?FUZZ=1 -w params.txtHere, params.txt contains common parameter names like id, debug, admin, file, etc. The tool sends requests with each parameter name and a fixed value (e.g., 1). It then analyzes responses for changes that indicate the parameter is accepted.
Value Fuzzing: Once a parameter is discovered, you can fuzz its values. For example, if id is a parameter, you can fuzz numeric IDs to find hidden records.
POST Parameter Fuzzing: Similar to GET, but using POST body:
ffuf -u http://target.com/login.php -X POST -d 'user=admin&FUZZ=test' -w params.txt7. Common Pitfalls and Best Practices
False Positives: Some servers return 200 for all requests (wildcard responses). Check for a pattern by requesting a non-existent file like asdfghjk.html. If it returns 200, you need to filter by response size or content length.
Rate Limiting: Start with low threads and increase gradually. Use delays to avoid being blocked.
Wordlist Quality: Use targeted wordlists based on the technology stack (e.g., PHP apps may have .php files).
Recursive Scanning: Some tools support recursion to discover deeper directories. Use with caution as it can generate many requests.
Output Logging: Always save results to a file for later analysis.
8. Advanced Techniques
Recursive Fuzzing: Tools like gobuster can recursively scan discovered directories:
gobuster dir -u http://target.com -w wordlist.txt -rExtension Fuzzing: Use multiple extensions to find files like config.php.bak.
VHost Fuzzing: Discover virtual hosts by fuzzing the Host header:
gobuster vhost -u http://target.com -w subdomains.txtContent-Type Fuzzing: For APIs, fuzz different Content-Type headers to see how the server responds.
Fuzzing with Custom Headers: Use -H in ffuf to add headers like Authorization: Bearer token.
Identify Target and Scope
Before fuzzing, define the target URL and scope. For PT0-002, the scope is usually provided in the penetration testing agreement. Identify the base URL (e.g., http://target.com) and any known paths. Determine if authentication is required. If so, obtain valid credentials or session tokens. Also, check if the target has a WAF or rate limiting by sending a few test requests and observing responses. This step ensures you don't accidentally disrupt the target or violate scope.
Select Appropriate Wordlist
Choose a wordlist based on the target's technology and purpose. For general directory busting, use common.txt or directory-list-2.3-medium.txt. For CMS-specific targets (e.g., WordPress), use dedicated wordlists like wp-contents.txt. For parameter discovery, use a list of common parameter names (e.g., param-min.txt from SecLists). The wordlist should be tailored to the attack surface. Using too large a wordlist may take excessive time, while too small may miss important resources.
Configure Tool and Run Fuzzing
Select a fuzzing tool (gobuster, ffuf, wfuzz, dirb) and configure it with the target URL, wordlist, and desired options. Set the number of threads (e.g., 20 for gobuster) and optionally set a delay to avoid rate limiting. Specify extensions if looking for specific file types. Use response filtering to ignore 404s and focus on 200, 301, 403, etc. Run the tool and monitor output. For example: `gobuster dir -u http://target.com -w common.txt -x php,html -t 20`. The tool will display discovered paths as they are found.
Analyze Results and Verify
After the fuzzing run, analyze the results. Look for status codes 200 (success), 301/302 (redirect), 403 (forbidden), and 401 (unauthorized). Note the response sizes; often a 200 response with a small size might be an empty page, while a large size indicates content. Verify interesting findings manually using curl or a browser. For example, if /admin returns 200, browse to it and check its content. Also, check for false positives by requesting a random non-existent path to see if the server returns a wildcard response.
Document and Exploit Findings
Document all discovered resources and parameters in the penetration test report. Include the full URL, response status, and any notable content. For parameter discovery, note which parameters are accepted and what values cause changes. If a discovered resource leads to a vulnerability (e.g., exposed admin panel, backup file with credentials), attempt to exploit it within scope. For PT0-002, you may be asked to demonstrate exploitation or explain the impact. Ensure all actions are logged for the final report.
In a typical enterprise penetration test, web fuzzing is a critical phase of reconnaissance. For example, consider a large e-commerce platform. The tester starts by fuzzing the main domain (e.g., www.example.com) using a wordlist of common directories and files. They discover /admin, /backup, and /api. The /backup directory returns a 200 with a directory listing, revealing db_backup.sql. This file contains database credentials, which the tester then uses to access the database. This is a common scenario: misconfigured servers expose sensitive files.
Another scenario involves a SaaS application that uses API endpoints. The tester fuzzes for hidden API parameters. Using a wordlist of common parameter names, they discover that the endpoint /api/user accepts a parameter debug. Setting debug=true returns verbose error messages that reveal the underlying technology stack and database structure. This information helps the tester craft SQL injection attacks.
In production, fuzzing must be tuned to avoid overwhelming the server. For a large-scale test, the tester might use ffuf with 50 threads and a delay of 100ms. They also use response filtering to exclude common false positives, such as a default 200 response for all requests. If the target uses a CDN or load balancer, the tester must ensure they are fuzzing the origin server, not the cache. Misconfiguration here can lead to incomplete results.
Performance considerations: For a wordlist of 100,000 entries with 50 threads, a fuzzing run might take 30-60 minutes. The tester should run it during off-peak hours to minimize impact. Common issues include rate limiting (returning 429 Too Many Requests) and WAF blocks (returning 403 or 406). To mitigate, the tester can rotate IP addresses using proxies or use lower thread counts.
What goes wrong when misconfigured: If the tester uses too many threads, the server may become unresponsive, causing denial of service and potentially violating the testing agreement. If they ignore false positives, they may waste time on non-existent resources. If they don't filter by response size, they might miss important findings buried in noise. Proper configuration and validation are essential.
For PT0-002 Objective 2.2 (Reconnaissance and Enumeration), the exam tests your ability to select and use appropriate fuzzing tools and interpret results. Specifically, you should know:
Tool Syntax: Be able to identify the correct command for directory busting with gobuster, ffuf, or wfuzz. For example, gobuster dir -u <URL> -w <wordlist> is correct; gobuster -u <URL> -w <wordlist> is missing the mode.
Common Wordlists: Know that dirb/common.txt is a standard small wordlist, and directory-list-2.3-medium.txt is larger.
Response Codes: Understand that 200, 301, 403, 401 are indicators of existence, while 404 indicates non-existence. A common trick: the server might return 200 for all paths (wildcard). The exam may ask how to detect this: send a request to a random path like asdfghjkl and check if it returns 200.
Parameter Discovery: Know that fuzzing parameter names is done by replacing the parameter name in the URL with FUZZ. For example: ffuf -u http://target.com/page.php?FUZZ=1 -w params.txt.
Recursive Fuzzing: The exam may ask about -r flag in gobuster for recursive scanning.
Common Wrong Answers:
1. Choosing nmap instead of gobuster for directory discovery. Nmap is for port scanning, not web content discovery.
2. Using dirb with the wrong wordlist path – the exam expects you to know standard locations like /usr/share/wordlists/dirb/common.txt.
3. Confusing parameter fuzzing with directory fuzzing. Parameter fuzzing uses FUZZ in the query string or POST body, not in the path.
4. Assuming a 403 means the resource doesn't exist – it exists but is forbidden, which is still useful information.
Edge Cases:
Servers that return 200 for all requests (wildcard). Filter by response size or content length.
Servers that require authentication – fuzzing may need to include cookies.
APIs that return JSON – check response bodies for differences.
How to Eliminate Wrong Answers: Use the underlying mechanism. If the question asks for a directory busting tool, eliminate any that are not web-focused (e.g., nmap, netcat). If it asks for parameter discovery, look for tools that support FUZZ in the query string. Understand that the goal is to enumerate resources, not to exploit them (that comes later).
Web fuzzing is an automated technique to discover hidden resources by sending many requests with varying inputs.
Common tools: gobuster, ffuf, wfuzz, dirb. Know syntax for at least gobuster and ffuf.
Response status codes: 200 (exists), 301/302 (redirect), 403 (forbidden), 404 (not found).
Always test for wildcard responses by requesting a random path; if it returns 200, filter by response size.
Parameter discovery fuzzes parameter names and values, often using FUZZ in the query string or POST body.
Wordlists should be chosen based on target technology; common lists: dirb/common.txt, directory-list-2.3-medium.txt.
Use threading and delays to balance speed and reliability; start with low threads and increase.
Recursive scanning (-r in gobuster) discovers deeper directories but can generate many requests.
Document all findings with full URLs and response details for the penetration test report.
For PT0-002, be able to select the correct tool and command for given scenarios, and interpret results.
These come up on the exam all the time. Here's how to tell them apart.
gobuster
Written in Go, single binary, fast.
Modes: dir, dns, vhost, s3.
Default threads: 10.
Simple syntax: `gobuster dir -u URL -w wordlist`.
Supports extensions with `-x`.
ffuf
Written in Go, also fast.
More flexible, supports multiple input modes (wordlist, stdin, etc.).
Default threads: 40.
Uses FUZZ placeholder: `ffuf -u URL/FUZZ -w wordlist`.
Can filter by status, size, regex, and more.
Mistake
A 404 response always means the resource does not exist.
Correct
Some servers are configured to return 404 for all requests to hide resources. Always test with a random path to see if you get a 404; if you get a 200 instead, the server is using a wildcard response. In that case, rely on response size or content differences.
Mistake
Gobuster can only be used for directory busting.
Correct
Gobuster has multiple modes: `dir` for directories, `dns` for subdomains, `vhost` for virtual hosts, and `s3` for AWS S3 buckets. The exam may test your ability to select the correct mode for the task.
Mistake
The larger the wordlist, the better the results.
Correct
Larger wordlists take longer and may cause more noise. The best wordlist is tailored to the target's technology. For example, use a PHP-specific wordlist for a PHP app. A huge generic wordlist might include many irrelevant entries and miss specific ones.
Mistake
Fuzzing is only for discovering directories.
Correct
Fuzzing can also discover files, parameters, subdomains, virtual hosts, and even API endpoints. Parameter discovery is a key part of web application testing and is tested in PT0-002.
Mistake
All fuzzing tools work the same way.
Correct
Tools differ in syntax, features, and speed. For example, ffuf is faster due to its implementation in Go, while wfuzz is more flexible with multiple iterators. The exam expects you to know the basic syntax of at least gobuster and ffuf.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Directory busting aims to discover hidden paths (directories and files) on a web server by fuzzing the URL path. Parameter discovery aims to find hidden GET or POST parameters that an application accepts by fuzzing the query string or request body. Both use similar tools but with different placement of the FUZZ keyword. For directory busting, FUZZ replaces part of the path (e.g., `http://target.com/FUZZ`). For parameter discovery, FUZZ replaces the parameter name (e.g., `http://target.com/page.php?FUZZ=value`).
A wildcard response occurs when the server returns a 200 (or other status) for every request, even for non-existent paths. To detect it, send a request to a random, unlikely path like `http://target.com/asdfghjkl`. If you get a 200 response, the server is using a wildcard. In that case, you need to filter results by response size or content length, as the response for non-existent paths will often have a consistent size that differs from real resources.
For WordPress, use a wordlist specifically tailored to WordPress, such as the one from SecLists: `Discovery/Web-Content/CMS/wp-plugins.txt` or `wp-themes.txt`. You can also use a general wordlist like `directory-list-2.3-medium.txt` but add common WordPress files like `wp-admin`, `wp-content`, `wp-config.php.bak`, etc. Alternatively, use a tool like `wpscan` which has built-in WordPress enumeration.
Yes, fuzzing is very effective for API testing. You can fuzz API endpoints to discover hidden endpoints, fuzz parameter names to find undocumented parameters, and fuzz parameter values to cause errors or unexpected behavior. For example, use ffuf: `ffuf -u http://api.target.com/v1/FUZZ -w endpoints.txt` to discover endpoints, or `ffuf -u http://api.target.com/v1/resource?FUZZ=1 -w params.txt` to find parameters.
To avoid rate limiting, use a lower number of threads (e.g., 5-10) and add a delay between requests. In gobuster, use `-t 10 -d 100` for 100ms delay. In ffuf, use `-p 0.1` for 100ms pause. Also, consider rotating user agents or using proxies. If you encounter a 429 status code, stop immediately and reduce the request rate.
Both are directory busting tools, but gobuster is written in Go and is generally faster, supports more modes (dir, dns, vhost, s3), and has more features like recursion and extension handling. Dirb is older and written in C, but still reliable. For PT0-002, gobuster is more commonly referenced in exam materials due to its versatility.
To fuzz POST parameters, you need to send POST requests with the parameter in the body. In ffuf: `ffuf -u http://target.com/login.php -X POST -d 'user=admin&FUZZ=test' -H 'Content-Type: application/x-www-form-urlencoded' -w params.txt`. This will fuzz the parameter name (FUZZ) while keeping the value 'test'. You can also fuzz values by placing FUZZ in the value position.
You've just covered Web Fuzzing: Dirbusting and Parameter Discovery — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?