ffuf Tutorial: Web Fuzzing for Directories, Virtual Hosts, and Parameters

Photo by Kevin Ku on Pexels

When you land on a web server in a CTF or engagement, the first question is: what’s actually here? The web server might have dozens of directories, files, and virtual hosts that aren’t linked anywhere. ffuf’s job is to find them by trying every entry in a wordlist and reporting back what exists.

The FUZZ keyword is what makes ffuf flexible. Unlike tools with fixed operation modes, ffuf lets you place FUZZ anywhere — in the path, in a header, in POST body data, in query parameters. One tool, one paradigm, multiple use cases.

Installation and Setup

# Kali / Debian / Ubuntu
sudo apt update && sudo apt install ffuf -y

# From source (latest version, recommended for active engagements)
go install github.com/ffuf/ffuf/v2@latest

# Verify
ffuf -V

SecLists Wordlists

ffuf needs a wordlist. SecLists is the standard collection for web fuzzing:

# Kali
sudo apt install seclists

# Manual
git clone https://github.com/danielmiessler/SecLists /usr/share/seclists

Key SecLists paths for web fuzzing:

• /usr/share/seclists/Discovery/Web-Content/common.txt — 4,614 entries, fast baseline
• /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt — 220,560 entries, thorough
• /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt — 30k unique directories
• /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt — virtual host fuzzing
• /usr/share/seclists/Discovery/Web-Content/web-extensions.txt — file extension list

Core Flags Reference

The standard starting point — place FUZZ in the URL path and let ffuf try every word in the list:

ffuf -u http://target.com/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt -c -mc 200,301,302,403

Adding File Extensions

Use -e to append extensions to each wordlist entry. ffuf tries admin, admin.php, admin.html, and admin.txt for each word:

ffuf -u http://target.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  -e .php,.html,.txt,.bak,.old \
  -c -mc 200,301,302,403 \
  -ic

Recursive Fuzzing

When ffuf finds a directory, -recursion automatically fuzzes inside it. Useful when you need depth but can be slow — use -recursion-depth to limit how far it goes:

ffuf -u http://target.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -c -mc 200,301,302,403 \
  -recursion \
  -recursion-depth 2

Filtering Results

Filtering is the skill that separates useful ffuf output from noise. Two approaches: match (show only) and filter (exclude):

Filtering by Response Size

When a server returns HTTP 200 for all requests (custom 404 page), filter by the size of that default response. First, make a request to a nonexistent path and check its size. Then filter that size:

# Check default response size
curl -s http://target.com/doesnotexist123 | wc -c
# Returns: 1587

# Filter that size from ffuf
ffuf -u http://target.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -c -fs 1587

Filtering with Regex

# Exclude responses containing "Page Not Found"
ffuf -u http://target.com/FUZZ \
  -w wordlist.txt \
  -fr "Page Not Found"

# Match only responses containing "admin" in body
ffuf -u http://target.com/FUZZ \
  -w wordlist.txt \
  -mr "admin panel"

Virtual host fuzzing discovers subdomains served by the same web server. The technique: place FUZZ in the Host header and watch for responses that differ from the default. Common in CTF machines where the IP resolves to a main site but hides an admin panel on a subdomain.

ffuf -u http://10.10.10.X/ \
  -H "Host: FUZZ.target.htb" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -c \
  -ac

If auto-calibration doesn’t work cleanly — make a request with a fake hostname, check the response size, and filter it manually:

# Find default response size
curl -s -o /dev/null -w "%{size_download}" -H "Host: notasubdomain.target.htb" http://10.10.10.X/
# Returns: 612

# Run ffuf with size filter
ffuf -u http://10.10.10.X/ \
  -H "Host: FUZZ.target.htb" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -c -fs 612

POST Body Fuzzing

Use -X POST and -d to fuzz POST data. Common for username enumeration or form fields:

ffuf -u http://target.com/login \
  -X POST \
  -d "username=FUZZ&password=wrongpassword" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -w /usr/share/seclists/Usernames/top-usernames-shortlist.txt \
  -c -fr "Invalid username"

GET Parameter Discovery

Discover hidden GET parameters by placing FUZZ in the query string key position:

ffuf -u "http://target.com/page?FUZZ=test" \
  -w /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt \
  -c -fs 1234 -mc 200

Multi-Wordlist Fuzzing (FUZZ + W2)

When you need to fuzz two positions simultaneously — like testing all username/password combinations in a small set — use named keywords:

ffuf -u http://target.com/login \
  -X POST \
  -d "user=USER&pass=PASS" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -w /tmp/users.txt:USER \
  -w /tmp/passwords.txt:PASS \
  -c -mr "Welcome"

Many web applications return HTTP 200 with a “Page Not Found” or “Error” page instead of a proper 404 response. Standard status code matching (-mc 200) would flag every single request as a hit. -ac solves this automatically:

ffuf -u http://target.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  -c \
  -ac

What -ac does internally: before the main scan starts, ffuf sends several requests with random FUZZ values (e.g., abc123xyz789). It records the status code, response size, word count, and line count of these “not found” responses. Then, during the real scan, it filters out any response that matches this baseline profile. The calibration adapts per-scan — no manual size-checking needed.

Auto-calibration works well when the custom 404 responses are consistent. If the application returns variable-length error pages (e.g., error messages that include the attempted URL), auto-calibration may not filter perfectly — in that case, combine with -fr regex filtering.

Output and Saving Results

ffuf -u http://target.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -c -ac \
  -o results.json -of json

Output formats: json, ejson (extended JSON), html, md (markdown), csv, ecsv. JSON is the most useful for piping into other tools or scripts:

cat results.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for r in data.get('results', []):
    print(r['url'])
"

Defensive Context

What ffuf traffic looks like: ffuf generates a high volume of HTTP requests to paths that don’t exist. In access logs, this appears as a flood of 404 or 403 responses from a single IP in a short time window. Any WAF or IDS with rate-based signatures will catch this quickly. The -rate and -p flags exist partly to slow requests below detection thresholds on engaged targets.

What to do on the blue side: Web application firewalls (WAFs) can detect and block directory brute-force patterns by tracking request volume per IP and triggering on excessive 404/403 rates. Rate limiting at the application or CDN layer (Cloudflare, AWS WAF rules) reduces the effectiveness of tools like ffuf against production assets. For internal networks, web server access logs should be monitored for bursts of 404s against non-existent paths.

What gets found that shouldn’t be there: The directories and files ffuf commonly surfaces — /backup, /.git, /admin, /.env, /config.php.bak — represent forgotten or inadvertently exposed resources. Restricting web server directory listing, returning proper 404 status codes, and reviewing what’s accessible in the web root before deployment reduces the attack surface that tools like ffuf exploit.

Frequently Asked Questions