Burp Intruder is Burp Suite’s built-in fuzzing and automation tool for sending many modified versions of the same request. It is useful for brute force, credential stuffing, endpoint fuzzing, IDOR testing, and parameter discovery, although the Community Edition is rate-limited.
Core idea: define where payloads go, choose how they should be combined, then send many requests and compare the results for anomalies.
Intruder automates repetitive request mutation. You normally capture a real request in Proxy, send it to Intruder with Ctrl + I, then configure positions and payloads.
ffuf, wfuzz, and similar fuzzers.Intruder is organized around four main sub-tabs:
Practical rule: before launching anything, strip the request down to only the positions you actually want to test. Leaving random cookies or tokens selected creates bad results fast.
The Positions tab defines where Intruder will inject payloads. Burp auto-selects likely targets and wraps them in section markers: §value§.
Best practice: clear all markers first, then mark only the exact field, path segment, or parameter you intend to fuzz.
The Payloads tab controls what Intruder inserts into the marked positions.
Important: Burp URL-encodes payloads by default. That is usually correct, but if you are testing raw syntax or special characters, verify the encoding settings.
Intruder has four attack types. Choosing the right one matters more than most beginners expect.
One payload set is used, and Intruder places each payload into each position one at a time. Best for single-parameter fuzzing or quick targeted testing.
The same payload is inserted into every defined position at once. Useful when the same candidate value needs to be tested in multiple fields simultaneously.
One payload set per position, iterated in lockstep. Best for credential stuffing where username and password pairs are already known to belong together.
Every possible combination of the payload sets is tested. Best when the relationship between values is unknown, but it creates the most traffic.
Fast mental model: Sniper = one list across positions, Battering Ram = same value everywhere, Pitchfork = paired lists, Cluster Bomb = all combinations.
username=§pentester§&password=§Expl01ted§With a payload list like burp, suite, intruder, Sniper tests each word in the first position, then repeats for the second position.
username=§pentester§&password=§Expl01ted§Each request uses the same payload in both fields: burp/burp, then suite/suite, then intruder/intruder.
With usernames joel, harriet, alex and passwords J03l, Emma1815, Sk1ll, Pitchfork sends:
joel / J03lharriet / Emma1815alex / Sk1llWith the same two lists, Cluster Bomb tries every username against every password.
Operational caution: Cluster Bomb grows very fast and becomes painful in Community Edition because of rate limiting.
The room’s main practical uses leaked username/password lists against a support login. Because the credentials are already paired, the correct attack type is Pitchfork, not Cluster Bomb.
/support/login/.username and password.usernames.txt into payload set 1.passwords.txt into payload set 2.Result analysis: all responses may have the same status code, so sort by Length and look for the outlier. A shorter or longer response often reveals the successful login.
After logging into the support portal, the room moves to ticket URLs such as /support/ticket/NUMBER. This is a classic place to test for IDOR.
PT1 use case: Intruder is useful for quickly checking whether object IDs are sequential and whether access control is actually enforced per object.
The harder admin login challenge adds a changing session cookie and a hidden loginToken CSRF value, so static brute force requests fail unless each attempt fetches fresh values first.
<input type="hidden" name="loginToken" value="84c6358bbf1bd8000b6b63ab1bd77c5e">This is where Burp Macros come in:
/admin/login/.Key lesson: if values change per request, Intruder alone is not enough. You need session handling or macros so every attack request stays valid.