WFuzz Web Fuzzing Guide

WFuzz is a web application fuzzing tool that replaces the

FUZZ

keyword with payload values to systematically test web applications for vulnerabilities.

Core Concept

WFuzz replaces any reference to the

FUZZ

keyword with values from a payload list:

• FUZZ

  = first payload position

• FUZ2Z

  = second payload position

• FUZ3Z

  = third payload position, etc.

Installation

# Kali Linux (pre-installed)
# Or install manually:
pip install wfuzz

Basic Syntax

wfuzz [options] -w <wordlist> <url>

Filtering Options

Filter results to show only interesting responses:

By Response String

--hs "regex"  # Hide responses matching regex
--ss "regex"  # Show only responses matching regex

By HTTP Status Code

--hc CODE     # Hide responses with this status code
--sc CODE     # Show only responses with this status code
--sc 200,202  # Show multiple codes (comma-separated)

By Response Size

--hl NUM      # Hide by number of lines
--sl NUM      # Show by number of lines
--hw NUM      # Hide by number of words
--sw NUM      # Show by number of words
--hh NUM      # Hide by number of characters
--sh NUM      # Show by number of characters

Output Options

wfuzz -e printers    # List available output formats
-f /tmp/output,csv   # Save output to CSV file

Encoders

Transform payloads before sending:

wfuzz -e encoders    # List available encoders

Available encoders:

urlencode

,

md5

,

base64

,

hexlify

,

uri_hex

,

double urlencode

Usage:

-z file,/path/to/file,md5      # Hash each value with MD5
-w /path/to/file,base64        # Encode values in base64
-z list,value1,value2,hexlify  # Inline list with hex encoding

Common Attack Patterns

1. Login Form Brute Force

Single list (username only)

wfuzz -c -w users.txt --hs "Invalid username" \
  -d "name=FUZZ&password=secret&autologin=1" \
  http://target.com/login.php

Two lists (username + password)

wfuzz -c -z file,users.txt -z file,pass.txt --sc 200 \
  -d "name=FUZZ&password=FUZ2Z&autologin=1" \
  http://target.com/login.php

With cookies and proxy

wfuzz -c -w users.txt -w pass.txt --ss "Welcome" \
  -p 127.0.0.1:8080:HTTP \
  -b "PHPSESSIONID=abc123;custom=cookie" \
  "http://target.com/login?user=FUZZ&pass=FUZ2Z"

2. Directory/Endpoint Discovery

# Filter out 404s to find existing endpoints
wfuzz -c -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
  --hc 404 \
  http://target.com/FUZZ

# Whitelist specific codes (200, 301, 302, 403)
wfuzz -c -w wordlist.txt --sc 200,202,204,301,302,307,403 \
  http://target.com/uploads/FUZZ

3. API Parameter Discovery

# Test common API parameters
wfuzz -c -w /usr/share/wordlists/SecLists/Discovery/Web-Content/param-minimal.txt \
  --hc 404 \
  https://target.com/api/FUZZ

# Path parameters
wfuzz -c -w params.txt --hw 11 \
  'http://target.com/path%3BFUZZ=FUZZ'

4. Header-Based Attacks

Basic Authentication

wfuzz -c -w users.txt -w pass.txt --ss "Welcome" \
  -p 127.0.0.1:8080:HTTP \
  --basic FUZZ:FUZ2Z \
  http://target.com/admin

NTLM Authentication

wfuzz -c -w users.txt -w pass.txt --ss "Welcome" \
  -p 127.0.0.1:8080:HTTP \
  --ntlm 'domain\\FUZZ:FUZ2Z' \
  http://target.com/admin

Cookie Brute Force

wfuzz -c -w users.txt --ss "Welcome" \
  -p 127.0.0.1:8080:HTTP \
  -H "Cookie: user=FUZZ" \
  http://target.com/dashboard

User-Agent Testing

wfuzz -c -w user-agents.txt --hc 403 \
  -p 127.0.0.1:8080:HTTP \
  -H "User-Agent: FUZZ" \
  http://target.com/

Virtual Host Discovery

wfuzz -c -w subdomains.txt --hc 400,404,403 \
  -H "Host: FUZZ.target.com" \
  -u http://target.com \
  -t 100

5. HTTP Method Testing

# Test different HTTP methods
wfuzz -c -w methods.txt --sc 200 -X FUZZ \
  http://target.com/admin

# Inline method list
wfuzz -z list,GET-HEAD-POST-TRACE-OPTIONS -X FUZZ \
  http://target.com/

Best Practices

1. Always use

   -c

   flag for colored output (easier to read)
2. Filter aggressively - hide common responses (404, 403) to reduce noise
3. Use appropriate wordlists - match the attack type to the wordlist
4. Test with proxy - use Burp Suite or similar for traffic inspection
5. Save results - use

   -f

   to export findings for later analysis
6. Rate limit - use

   -t

   flag to control thread count and avoid detection
7. Verify findings - fuzzing produces false positives; manually verify results

Common Wordlists

# Directory enumeration
/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
/usr/share/wordlists/dirb/common.txt

# Subdomain discovery
/usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-20000.txt

# API parameters
/usr/share/wordlists/SecLists/Discovery/Web-Content/param-minimal.txt

# HTTP methods
/usr/share/wordlists/SecLists/Discovery/Web-Content/http-methods.txt

Troubleshooting

Slow performance

• Reduce thread count:

  -t 10

• Use smaller wordlists
• Add timeout:

  --timeout 5

Too many false positives

• Tighten filters (use

  --sc

  instead of

  --hc

  )
• Add multiple filter conditions
• Verify with manual requests

Connection errors

• Check proxy configuration
• Verify target is accessible
• Use

  --timeout

  for slow targets