Repeater and Intruder Workflows

The Problem Repeater Solves

You have captured a request in Burp Proxy and want to test how the server responds when you change a parameter. You could edit the request in the browser dev tools, but that is slow and limited. Repeater gives you a dedicated workspace to modify any part of a request — method, path, headers, cookies, body — and resend it as many times as you need, with full visibility into each response.

Sending a Request to Repeater

Right-click any request in Proxy > HTTP history (or the site map) and select Send to Repeater. The request opens in a new Repeater tab. You see the raw request on the left and the response on the right. Edit anything in the request, then click Go to send it.

What You Can Modify

Every byte of the request is editable:

• Request line — Change HTTP method (GET to POST), path, or query parameters
• Headers — Modify Host, User-Agent, Content-Type, Authorization, or add custom headers
• Cookies — Edit session tokens, role identifiers, or any cookie value
• Body — For POST requests, modify form data, JSON payloads, or XML content

Practical Example: Testing IDOR

Suppose you captured a request:

GET /api/documents/1001 HTTP/1.1
Host: target.example.com
Cookie: session=abc123

You suspect an Insecure Direct Object Reference (IDOR) vulnerability. In Repeater, change the document ID:

GET /api/documents/1002 HTTP/1.1

Click Go. If the response contains another user's document, you have confirmed IDOR. You can rapidly iterate through IDs 1002, 1003, 1004 to map the exposure.

Repeater Workflow Tips

• Use the Inspector — The right-side panel provides structured views of parameters, headers, and JSON bodies, making targeted edits easier than raw text editing
• Compare responses — Send the same request twice with one variable changed and diff the responses to spot behavioral differences
• Change Content-Length — When modifying POST bodies, Burp automatically recalculates Content-Length when you click Go, so you do not need to update it manually
• URL-encode carefully — If you insert special characters in parameters, use the URL-encode key shortcut (Ctrl+U) to ensure proper encoding

The Problem Intruder Solves

Repeater is powerful for testing one parameter at a time, but what if you need to test hundreds of values? Manually changing a parameter and clicking Go 500 times is impractical. Intruder automates this: you define a request template, mark the positions to fuzz, provide a payload list, and Burp sends all requests and collects the responses.

Setting Up an Intruder Attack

Step 1: Right-click a request and select Send to Intruder.

Step 2: Go to the Positions tab. Burp auto-detects parameters and marks them with § symbols. For example:

GET /api/documents/§1001§ HTTP/1.1

The §1001§ marks the payload position. You can add or remove positions manually using the Add § and Clear § buttons.

Step 3: Choose an Attack Type:

• Sniper — Tests one position at a time with each payload. Best for single-parameter fuzzing.
• Battering ram — Tests all positions simultaneously with the same payload. Best for testing the same value in multiple fields.
• Pitchfork — Tests multiple positions with corresponding payloads from different lists. Best for username/password pair testing.
• Cluster bomb — Tests all combinations of multiple payload lists. Best for credential stuffing or multi-parameter brute force.

Step 4: Go to the Payloads tab and configure your payload set. You can:

• Paste a simple list of values
• Load a wordlist file
• Use built-in payload lists (numbers, dates, brute forcers)
• Apply payload processing rules (URL-encode, hash, prefix/suffix)

Practical Example: Fuzzing for Hidden Parameters

You want to discover hidden API parameters. Send a request to Intruder, mark the query string value as a position, and load a wordlist of common parameter names:

GET /api/search?q=test§&debug=true HTTP/1.1

Actually, a better approach: mark the entire query string and fuzz with parameter names:

GET /api/search?§param§=value HTTP/1.1

Payload list: debug, admin, test, verbose, format, callback, api_key

If the server responds differently to ?debug=true (e.g., verbose error messages or debug output), you have found a hidden feature.

Analyzing Intruder Results

After the attack completes, Intruder displays a table of all requests and responses. Sort by:

• Response length — Different lengths often indicate different behavior
• Status code — 200 vs 500 vs 403 reveals different handling
• Response time — Time-based differences can indicate SQL injection or command execution

Use Grep - Match in the Options tab to flag responses containing specific strings (e.g., "error", "admin", "success"). This automatically highlights interesting results in the table.

Payload Processing Rules

Intruder lets you transform payloads before sending. In the Payloads tab, under Payload Processing, you can add rules:

• URL-encode — Ensures special characters do not break the request
• Base64-encode — Useful for parameters that expect encoded values
• Hash (MD5/SHA1) — Useful when the server expects hashed input
• Prefix/Suffix — Add static text around each payload
• Match/replace — Replace specific patterns within payloads

Example: You are fuzzing a JWT token payload. You need Base64url-encode each test value. Add a processing rule: Base64-encode, then replace + with - and / with _ (Base64url variant).

Grep Extractors for Response Analysis

When responses contain dynamic content (CSRF tokens, session IDs), you need to extract and correlate data. Grep - Extract in the Options tab lets you define regex patterns to pull specific data from each response and display it as a column in the results table.

Example: You are testing password reset tokens. Extract the token from each response:

Pattern: token=([a-f0-9]{32})

Each row in the results table now shows the extracted token, making it easy to correlate which payload produced which token.

Resource Management

Intruder attacks can generate significant load. Use these controls:

• Request threads — Limit concurrent requests (default 10, reduce for fragile servers)
• Throttle — Add delay between requests to avoid overwhelming the target
• Pause/Resume — You can pause an active attack, adjust settings, and resume

When to Use Repeater vs Intruder

Common Pitfalls

• Not clearing auto-marked positions — Burp may mark positions you do not want to fuzz; clear them before starting
• Ignoring response length — The default sort should be by response length; identical lengths often mean identical behavior
• Overwhelming the target — High thread counts on production systems can cause denial of service; always test against staging when possible
• Missing rate limiting — Some applications rate-limit requests; Intruder will show identical error responses that look like findings but are actually rate-limit responses