![How to Use the Command 'wfuzz' (with Examples)](/images/commands/general-3_hu1d66b4797bd84091a646043ceed9a191_12728_1110x0_resize_q90_h2_lanczos_2.webp)
How to Use the Command 'wfuzz' (with Examples)
Wfuzz is a robust web application bruteforcer designed to aid penetration testers and web security professionals in uncovering vulnerabilities and potential security loopholes within web applications. Essential for security assessments, it offers a wide range of functionalities, including directory brute-forcing, customizable headers, and advanced authentication techniques, making it a versatile tool in a penetration tester’s arsenal.
Directory and File Brute-force with Wordlist and Proxying
Code:
wfuzz -w path/to/file -p 127.0.0.1:8080:HTTP http://example.com/FUZZ
Motivation:
This use case is particularly valuable when you want to discover hidden directories and files on a web server. By brute-forcing directories and files, testers can identify resources that are not publicly linked but accessible over the web. The ability to proxy traffic allows for capturing and analyzing requests in tools like Burp Suite, which can be useful for deeper analysis and auditing.
Explanation:
-w path/to/file
: This argument specifies the path to the wordlist that contains potential directory and file names. It’s crucial for generating the URLs to fuzz.-p 127.0.0.1:8080:HTTP
: This option sets the proxy server that the requests are routed through. It is important for monitoring and manipulating traffic.http://example.com/FUZZ
: The target URL where “FUZZ” indicates the place in the URL to insert words from the wordlist.
Example Output:
The output would typically display each attempted URL and its corresponding HTTP response status, indicating which URLs are valid or potentially of interest.
Save Results to a File
Code:
wfuzz -w path/to/file -f filename http://example.com/FUZZ
Motivation:
Saving results to a file is essential when conducting extensive fuzzing over large wordlists, as it enables the tester to review the results conveniently and ensures data is not lost if the terminal session is accidentally closed.
Explanation:
-w path/to/file
: Specifies the wordlist, as before, for generating potential URLs.-f filename
: Directs Wfuzz to write the results to the specified file named “filename”.http://example.com/FUZZ
: The target website with the fuzzing point.
Example Output:
Execution will create a file with the designated filename, containing all the targeted URLs and their resulting HTTP response codes.
Colorized Output with Specified Response Codes
Code:
wfuzz -c -w path/to/file --sc 200,301,302 http://example.com/FUZZ
Motivation:
This use case is designed for users who prefer a colorized terminal output, making it easier to distinguish between successful requests and responses. Filtering for specific response codes, such as 200 (OK) or 301/302 (redirections), allows testers to quickly hone in on successful finds without having to sift through the noise of irrelevant responses.
Explanation:
-c
: Enables colorized output for better clarity and readability.-w path/to/file
: Indicates the wordlist file being used.--sc 200,301,302
: Limits the results to only show HTTP response codes 200, 301, and 302.http://example.com/FUZZ
: The target URL for fuzzing.
Example Output:
The console will display colored output, emphasizing the URLs returning the specified response codes, making successful fuzz attempts stand out.
Fuzz Subdomains with Custom Header and Multi-threading
Code:
wfuzz -w path/to/file -H "Host: FUZZ.example.com" --hc 301 --hw 222 -t 100 example.com
Motivation:
When testing a server for subdomain vulnerabilities, this method allows the tester to craft custom headers and brute-force potential subdomains with high efficiency by utilizing multi-threading. Hiding specific response codes and word counts further refines the results concentration on potentially interesting subdomains.
Explanation:
-w path/to/file
: Refers to the list of potential subdomains.-H "Host: FUZZ.example.com"
: Applies a custom header to each request for testing various subdomains.--hc 301
: Hides responses with HTTP 301 codes, which might be unimportant for understanding server behaviour.--hw 222
: Suppresses displaying responses with a word count of 222, focusing on variations in server responses.-t 100
: Sets the number of concurrent threads to 100, speeding up the testing process.example.com
: Target domain.
Example Output:
Results will highlight attempts with unique or suspicious responses, potentially uncovering misconfigured or vulnerable subdomains.
Brute Force Basic Authentication with Hidden Unsuccessful Attempts
Code:
wfuzz -c --hc 401 -s delay_between_requests_in_seconds -z file,path/to/usernames -z file,path/to/passwords --basic 'FUZZ:FUZ2Z' https://example.com
Motivation:
By attempting multiple combinations of usernames and passwords, this use case helps security professionals to identify weak authentication mechanisms. Hiding unsuccessful attempts helps in concentrating on valid credentials without flooding the terminal with irrelevant data.
Explanation:
-c
: Enables colorized output.--hc 401
: Hides unsuccessful login attempts (401 Unauthorized responses).-s delay_between_requests_in_seconds
: Introduces a delay between requests, reducing the risk of being blocked by the server for excessive requests.-z file,path/to/usernames
: Specifies the file containing a list of usernames.-z file,path/to/passwords
: Defines the file with password candidates.--basic 'FUZZ:FUZ2Z'
: Sets up basic authentication using the provided username and password lists.https://example.com
: The target URL for basic authentication testing.
Example Output:
Only valid authentication attempts or those with non-401 responses are displayed, potentially revealing vulnerable accounts or access points.
Provide Wordlist Directly and Use POST Request
Code:
wfuzz -z list,word1-word2-... https://api.example.com -d "id=FUZZ&showwallet=true"
Motivation:
Directly supplying words from the command-line caters to quick tests where a full wordlist might not be necessary. Utilizing POST requests is suitable for APIs or forms that depend on post parameters, aiding testers in verifying the end-points’ robustness.
Explanation:
-z list,word1-word2-...
: Provides a direct list of words separated by dashes, bypassing the need for a file.https://api.example.com
: The target URL of an API or service accepting POST requests.-d "id=FUZZ&showwallet=true"
: The payload of the POST request where “FUZZ” is replaced by values from the supplied word list.
Example Output:
Reveals interacting POST request paths or vulnerabilities when specific words lead to notable responses.
Wordlists with Base64 and MD5 Encoding
Code:
wfuzz -z file,path/to/file,none-base64-md5 https://example.com/FUZZ
Motivation:
When web applications encode inputs or rely on hashing mechanisms, utilizing encoded fuzzed wordlists can highlight discrepancies or weaknesses in how the applications handle encoded data, potentially leading to vulnerabilities.
Explanation:
-z file,path/to/file,none-base64-md5
: Reads words frompath/to/file
, with outputs encoded in none (plain), Base64, and MD5 formats.https://example.com/FUZZ
: Uses the website as the attack target.
Example Output:
Responses will show results according to plaintext, Base64, and MD5 encoded inputs, identifying potential mishandling or misconfiguration in encoding processes.
List Available Encoders/Payloads/Iterators/Printers/Scripts
Code:
wfuzz -e encoders|payloads|iterators|printers|scripts
Motivation:
Understanding the available encoders, payloads, iterators, printers, and scripts assists testers in tailoring fuzz tests to specific needs and expanding the capacity for creative and comprehensive audits.
Explanation:
-e encoders|payloads|iterators|printers|scripts
: Lists all available options based on the designer’s selection of encoders, payloads, iterators, printers, or scripts, facilitating the selection of appropriate ones for test scenarios.
Example Output:
The command lists details of each encoder, payload, etc., ensuring the tester can make informed decisions when configuring tests to maximize coverage.
Conclusion:
Wfuzz stands out as a powerful and flexible tool for web application security testing. By enabling testers to configure tests comprehensively, from custom headers to encoded payloads, Wfuzz addresses intricate testing needs efficiently and effectively, proving indispensable in a security auditor’s toolkit.