Burp Intruder Fuzzing: Automated Parameter Testing for Security

HelpMeTest

13 Aug 2026 — 4 min read

Burp Intruder automates sending many variations of a request — testing dozens of payloads against a parameter without manual repetition. It's the right tool when you know what you want to test but need to do it at scale.

This guide covers authorized security testing only. Intruder is a powerful tool — running it against systems you don't own or have explicit permission to test is illegal.

What Intruder Does

Intruder takes a request and lets you define:

Positions — which parts of the request to inject into (parameters, headers, etc.)
Payloads — what values to substitute at those positions
Attack type — how to combine positions and payloads

It then sends all the variations and shows you the responses side by side.

Community vs Professional Edition

Community edition has rate-limited Intruder (approximately 1 request/second), making it impractical for large wordlists.

Professional edition has no artificial rate limiting. Intruder runs at full speed.

For time-sensitive testing, Community edition's Intruder still works — it's just slower.

Sending a Request to Intruder

Find the request in Proxy → HTTP History or Repeater
Right-click → Send to Intruder
Go to the Intruder tab

Configuring Positions

In the Positions subtab, you see your request with injection markers (§). Burp auto-highlights likely parameter positions.

Clear all positions first: Clear §

Then manually mark exactly what you want to fuzz. Highlight the value you want to replace and click Add §.

Example — fuzzing a username parameter:

POST /login HTTP/1.1
...
username=§admin§&password=password123

The §admin§ marks the position to inject into.

Attack Types

Sniper

One payload list, one position at a time (if multiple positions). For single-parameter testing.

Use case: Testing one parameter with many payloads (injection wordlist, common usernames).

Battering Ram

Same payload inserted into all positions simultaneously.

Use case: Testing the same value in multiple places — e.g., testing the same ID in both a URL parameter and a request body field.

Pitchfork

Multiple payload lists, one per position, advanced in parallel (payload 1 from list 1 paired with payload 1 from list 2, etc.).

Use case: Credential stuffing with a username list and corresponding password list — testing known username/password pairs.

username=§alice§&password=§alice_password§

List 1: alice, bob, carol List 2: alice_pass, bob_pass, carol_pass

Pitchfork sends: alice/alice_pass, bob/bob_pass, carol/carol_pass

Cluster Bomb

All combinations of all payload lists across all positions.

Use case: Brute-forcing credentials when you don't have matched pairs — every username with every password.

Be aware: cluster bomb generates n × m requests (payloads × payloads). 100 usernames × 100 passwords = 10,000 requests.

Configuring Payloads

In the Payloads subtab:

Payload Types

Simple list — enter or paste values manually:

admin
administrator
root
test
user

Runtime file — load a wordlist from a file. Burp Suite Professional ships with extensive wordlists in /usr/share/wordlists/ on Kali, or download SecLists.

Numbers — generate numeric sequences (useful for IDOR testing: try IDs 1 through 1000).

Character frobber — vary one character position at a time (useful for token analysis).

Dates — iterate through date values.

Payload Processing

Apply transformations to payloads before sending:

URL encode
Base64 encode
Hash (MD5, SHA1)
Add a prefix/suffix

Example: Add URL encoding to bypass input filters that check for raw characters.

Configuring Options

Request Engine

Set concurrent request threads and throttle:

Threads: 10-20 for Professional; Community is rate-limited regardless
Throttle: Add delays between requests to avoid rate limiting or IDS alerts

Grep — Match

Flag responses that contain specific strings. Useful for success detection:

Add "Welcome" or "dashboard" for login attacks — responses with these strings likely succeeded
Add SQL error patterns: "sql syntax", "ORA-", "mysql_fetch"

Grep — Extract

Extract a specific value from responses for comparison. Useful when you need to compare response content rather than just status codes.

Grep — Payloads

Flag responses that reflect the payload. Useful for finding reflected XSS — look for responses where your payload appears in the output.

Common Intruder Use Cases

Credential Stuffing (Pitchfork)

Test a list of known username/password pairs:

Capture a login request
Send to Intruder
Mark username and password positions
Attack type: Pitchfork
Payload set 1: username list
Payload set 2: corresponding password list
Grep for success indicators

IDOR Testing (Sniper)

Test whether you can access other users' data by iterating IDs:

Capture a request with a user/object ID parameter
Send to Intruder
Mark the ID position
Attack type: Sniper
Payload type: Numbers (e.g., 1 to 500)
Analyze response lengths — different lengths may indicate different data returned

Directory Brute Force (Sniper)

Find hidden directories and files:

Capture any GET request to the target
Mark the path component
Use a directory wordlist (SecLists /Discovery/Web-Content/)
Filter results by status code — 200/301 responses exist, 404 do not

SQL Injection Fuzzing (Sniper)

Test a parameter systematically:

Capture a request with the parameter
Mark the parameter value position
Use an SQL injection payload list (available in SecLists)
Grep for SQL error strings in responses

Analyzing Results

The results table shows:

Request number — which payload
Status code — HTTP response code
Error — whether a network error occurred
Timeout — whether the request timed out
Length — response body length
Comment — any Grep matches

Sort by length — different-length responses often indicate different behavior (e.g., successful login vs. failed login returns different pages).

Sort by status code — 302 redirects after a login attempt often indicate success.

Click any row to see the full request and response for that payload.

Rate Limiting and Detection Evasion

For authorized testing only: If your target has rate limiting or account lockout:

Set thread count to 1 in Options → Request Engine
Add throttle (e.g., 2000ms between requests)
Use the "Retry failed requests" option for transient errors

Exporting Results

Right-click in the results table → Save results → CSV or HTML.