wfuzz

Directory and file bruteforce using the specified [w]ordlist and also [p]roxying the traffic

$ wfuzz -w [path/to/file] -p [127.0.0.1:8080:HTTP] [http://example.com/FUZZ]

$ wfuzz -w [path/to/file] -f [filename] [http://example.com/FUZZ]

$ wfuzz -c -w [path/to/file] --sc [200,301,302] [http://example.com/FUZZ]

$ wfuzz -w [path/to/file] -H "[Host: FUZZ.example.com]" --hc [301] --hw [222] -t [100] [example.com]

$ 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]

$ wfuzz -z list,[word1-word2-...] [https://api.example.com] -d "[id=FUZZ&showwallet=true]"

$ wfuzz -z file,[path/to/file],none-base64-md5 [https://example.com/FUZZ]

$ wfuzz -e [encoders|payloads|iterators|printers|scripts]

wfuzz [options] -u <url> -z <payload_source> ...

Example: wfuzz -c -z wordlist,common.txt -u https://example.com/FUZZ
Example with multiple payloads: wfuzz -c -z file,/usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -z file,/usr/share/wordlists/rockyou.txt -u "https://example.com/admin/FUZZ.php?user=admin&pass=FUZZ2"

-u <url>
    Specifies the target URL for fuzzing. It must contain the FUZZ keyword (or FUZZn for multiple points) where payloads will be injected.

-z <payload_source>
    Defines a payload source for the FUZZ keyword. Payloads can be from wordlists, numbers, character ranges, or custom generators.

--hc <code>
    Hides responses with specific HTTP status codes (e.g., 404, 500). Can be a comma-separated list or range.

--hh <lines>
    Hides responses with a specific number of lines in the content.

--hw <words>
    Hides responses with a specific number of words in the content.

--hl <chars>
    Hides responses with a specific number of characters (bytes) in the content.

--sc <code>
    Shows only responses with specific HTTP status codes. Opposite of --hc.

--sh <lines>
    Shows only responses with a specific number of lines. Opposite of --hh.

--sw <words>
    Shows only responses with a specific number of words. Opposite of --hw.

--sl <chars>
    Shows only responses with a specific number of characters. Opposite of --hl.

-c
    Enables colorized output for better readability in the terminal.

-X <method>
    Specifies the HTTP method to use for the request (e.g., GET, POST, PUT, DELETE).

-d <data>
    Specifies the data to send with POST requests. Can include FUZZ for injection into the POST body.

-H <header>
    Adds an HTTP header to the request (e.g., 'Cookie: foo=bar'). Can include FUZZ for fuzzing header values.

--req <file>
    Loads an HTTP request from a specified file, allowing complex requests to be fuzzed.

--proxy <host:port>
    Routes requests through an HTTP proxy for monitoring or bypassing restrictions.

--timeout <seconds>
    Sets a timeout for each HTTP request, preventing long waits for unresponsive servers.

--follow-redirects
    Configures wfuzz to automatically follow HTTP redirects (3xx responses).

wfuzz is a powerful and versatile open-source web fuzzer designed for web application security testing. It automates the process of discovering hidden web content, testing for various vulnerabilities like SQL injection, cross-site scripting (XSS), directory traversal, and brute-forcing authentication mechanisms.

wfuzz operates by injecting various payloads into specified points (marked with FUZZ) within an HTTP request. It supports multiple payload types, including wordlists, numbers, character ranges, and even custom generators. Its strength lies in its highly customizable filtering system, allowing users to hide or show responses based on HTTP status codes, response length, number of lines, words, or characters. This enables efficient identification of interesting responses amidst a large volume of requests. wfuzz also supports different HTTP methods, request headers, POST data, proxies, and authentication schemes, making it an indispensable tool for penetration testers and security researchers.

wfuzz can generate a large volume of requests, which might trigger Intrusion Detection/Prevention Systems (IDS/IPS) or cause denial of service (DoS) if not used carefully. Ethical considerations are paramount; always ensure you have explicit permission before using wfuzz against any system. Misuse can lead to legal consequences. It also requires a good understanding of HTTP and web application structure to be used effectively.

wfuzz is a powerful tool designed for security testing. Always ensure you have explicit, written permission from the system owner before conducting any scans or tests. Unauthorized use can lead to serious legal consequences and is unethical. Responsible usage involves respecting privacy, data integrity, and system availability.

The FUZZ keyword (or FUZZn for multiple points) is central to wfuzz's operation. It marks the injection points in the URL, headers, or POST data where payloads will be inserted. Understanding where to place FUZZ is crucial for effective testing and maximizing the tool's capabilities.

wfuzz was initially developed by Carlos Arce (xmendez) and first released around 2006. It quickly gained popularity within the penetration testing community due to its flexibility and effectiveness in automating web vulnerability discovery. Its development has been community-driven, with continuous updates and improvements over the years, solidifying its position as a staple tool in many security professionals' arsenals. Its design, focusing on the FUZZ keyword and powerful filtering, set a standard for subsequent web fuzzing tools.

curl(1), nmap(1), hydra(1), gobuster(1), ffuf(1)