How to Use the Command 'wfuzz' (with Examples)

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 from path/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.

Related Posts

How to Format an exFAT Filesystem using `mkfs.exfat` (with examples)

How to Format an exFAT Filesystem using `mkfs.exfat` (with examples)

The mkfs.exfat command is a powerful utility used to create an exFAT filesystem on a specified partition or storage device.

Read More
Exploring Network Services with 'avahi-browse' (with examples)

Exploring Network Services with 'avahi-browse' (with examples)

The avahi-browse command is a powerful tool used for discovering network services and hosts using the Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD) protocols on the local network.

Read More
The Power of Sendmail: Effortless Email Delivery (with examples)

The Power of Sendmail: Effortless Email Delivery (with examples)

Sendmail is a classic utility in Unix-based systems used primarily for sending emails.

Read More