timsonner Wfuzz
Purpose
Use this skill for focused fuzzing of paths, parameters, headers, or hostnames when the current hypothesis requires controlled variation of web requests.
Phase Fit
- Primary: Discovery and Reconnaissance, Vulnerability Analysis
- Secondary: Validation and Controlled Impact Demonstration, Retest and Closure
Use When
- Need to fuzz paths, parameters, headers, or virtual hosts.
- Need a more flexible web fuzzing workflow than a simple directory brute force.
- Need a repeatable retest for a discovered input boundary issue.
Avoid When
- Rate limits or application fragility are unclear.
- Broad fuzzing would exceed the approved impact level.
Inputs
- Approved base URL and fuzz point
- Narrow wordlist or payload set
- Rate, filter, and auth constraints
Procedure
- Start with the smallest payload set that answers the question.
- Separate authenticated and unauthenticated fuzzing.
- Filter noise aggressively and validate only meaningful deltas.
- Escalate material findings to manual validation.
- Preserve the exact payload set and filters for retest.
Command Syntax
Replace sample targets with approved in-scope URLs.
# Directory fuzzing, filter 404
wfuzz -c -z file,/usr/share/seclists/Discovery/Web-Content/common.txt --hc 404 https://portal.contoso.com/FUZZ
# POST login fuzzing
wfuzz -c -z file,users.txt -d "username=FUZZ&password=admin" https://portal.contoso.com/login
# Header fuzzing (e.g., X-Forwarded-For)
wfuzz -c -z file,ips.txt -H "X-Forwarded-For: FUZZ" https://portal.contoso.com/admin
# Authenticated scan with session cookie
wfuzz -c -z file,paths.txt -b "session=<token>" --hc 404 https://portal.contoso.com/FUZZ
# Filter by response string (hide known-bad responses)
wfuzz -c -z file,users.txt -d "user=FUZZ" --hs "Invalid user" https://portal.contoso.com/login
# Vhost brute-force via Host header
wfuzz -c -z file,subdomains.txt -H "Host: FUZZ.contoso.com" --hc 400,404 https://contoso.com/
Evidence to Capture
- Paths or parameters that materially changed application behavior
- Exact payload set and filters used
- Minimal proof path for retest
Safety Boundaries
- Keep payloads narrow and rate controlled.
- Stop if the application shows instability or lockout behavior.