Contents

What is Burp Intruder?

Configuring Burp Intruder
    Target tab
    Positions tab
    Payloads tab
        Payload sources
        Preset list
        Runtime file
        Custom iterator
        Character substitution
        Case substitution
        Recursive grep
        Illegal Unicode
        Character blocks
        Numbers
        Dates
        Brute forcer
        Null payloads
        Payload processing
    Options tab
    Comms tab

Launching an attack
    Results view
    Results menus

What is Burp Intruder?

Burp Intruder is a tool for automating customised attacks against web applications.

Burp Intruder is not a point-and-click tool. To use it effectively you need to understand how the target application functions, and have some knowledge of the HTTP protocol. Before launching any attacks using Burp Intruder, you need to investigate the functionality and structure of the target application, and in particular the various HTTP messages that pass between the browser and server. You can perform this investigation using a standard browser and Burp Proxy to intercept and view all of the requests and responses generated by the application. When you have identified some interesting HTTP requests that bear closer examination, you are ready to use Burp Intruder.

Burp Intruder is highly configurable and can be used to automate a wide range of attacks. You can use Burp Intruder to facilitate very many kinds of tasks, including enumerating identifiers, harvesting useful data, and fuzzing for vulnerabilities. The types of attacks that are appropriate will depend on the application in question, and may include: testing for flaws such as SQL injection, cross-site scripting, buffer overflows and path traversal; brute force attacks against authentication schemes; enumeration; parameter manipulation; trawling for hidden content and functionality; session token sequencing and session hijacking; data mining; concurrency attacks; and application-layer denial-of-service attacks. For a detailed discussion of the kinds of attack that can be performed using Burp Intruder, see Chapter 13 of The Web Application Hacker's Handbook.

Burp Intruder includes many preset lists of attack "payloads" (strings that are useful in detecting and exploiting common vulnerabilities). It also contains a large number of tools for dynamically generating attack vectors that are appropriate to specific mechanisms often found within web applications. External files can also be loaded and incorporated into Burp Intruder (e.g. lists of enumerated usernames, or fuzz strings for newly-identified vulnerabilities).

The core activity of each attack is to iterate through a number of HTTP requests. These are derived from the basic request identified at the investigation stage. Burp Intruder manipulates this basic request in particular ways designed to identify or exploit application vulnerabilities. It does this by replacing portions of the basic request with one or more payloads. The timing and execution of each attack can also be configured. Multiple threads can be used to generate requests concurrently. Requests can be throttled to prevent IDS detection. A denial-of-service mode can be used to bombard the server with requests while ignoring any responses received.

When an attack executes, a detailed table of results is produced, showing the response received from the server to each request. The results contain all relevant information that can be used to pinpoint responses that are interesting or successful. In addition to the standard results common to every attack, many customisable tests can be performed on the results at runtime, and the results of these are also recorded. For example, Burp Intruder can be configured to extract specific information from HTML pages (e.g. the personal details fields on a user information page), and record this information with each result. All results output can be exported for further manipulation, or to use as an input file for further attacks or other tools.

Burp Intruder is a Java application, and runs on any platform for which a Java Runtime Environment is available. It requires version 1.5 or later. The JRE can be obtained for free from java.sun.com.

Configuring Burp Intruder

The Burp Intruder control panel contains several tabs that can be used to configure an attack.

To create a new attack, set up the required configuration and then select "start" from the "Intruder" menu. The configuration options are described in detail in the sections below.

To load a saved attack, select "open" from the "Intruder" menu, and choose the required file.

Target tab

This tab is used to configure the details of the target server:

The "host" field is used to specify the IP address or hostname of the target server. The "port" field is used to specify the port number of the HTTP/S service. The "use SSL" box is used to specify whether Secure Sockets Layer connections should be used.

Positions tab

This tab is used to configure the template for all the HTTP requests generated in the attack:

The main text box is used to set the contents of the base request, and also to mark the locations where payloads will be inserted into individual HTTP requests during the attack.

The easiest way to set up the attack template is to locate the relevant request within one of the other Burp tools, and select the "send to intruder" option. You can send requests from any place within Burp Suite where an HTTP request or response is displayed, and also from the Burp Proxy history, Burp Spider results tree or table, and from within an already executing Burp Intruder attack:

The positions of payloads are marked using pairs of § characters, which may enclose portions of the template text between them. When a payload is placed into a particular position for a given request, the § characters for that position, and any text which appears between them, are replaced with the payload. When a particular position is not assigned a payload for a given request (this applies only to the "sniper" attack type - see below), the § characters for that position are simply removed, and any text which appears between them remains unchanged.

When you send a request from elsewhere within Burp Suite, Burp Intruder makes a best guess at where you are likely to want to place payloads, and it positions these at the value of each URL and body parameter, and each cookie. The markers and enclosed text for each position are automatically colour-coded for clarity. Below the text box, the number of defined positions and the size of the template text are indicated.

You can also use the buttons on this tab to control the positioning of payload markers:

add § - This inserts a single position marker at the cursor position.
clear § - This removes all position markers, either from the entire template or from a selected portion of the template.
auto § - This makes a guess as to where it might be useful to position payloads and inserts position markers accordingly, either for the entire template or for a selected portion of the template. Any existing markers are removed. This is a useful function to quickly mark positions suitable for attacking certain common vulnerabilities (such as SQL injection), but manual positioning is required for more customised attacks.
refresh - This refreshes the colour-coding of the text box, if necessary.
clear - This deletes the entire contents of the text box.

The "attack type" drop-down menu is used to define a key aspect of the behaviour of Burp Intruder - the way in which payloads are placed into the specified positions to form individual requests. The four possible attack types are described below:

sniper - This uses a single set of payloads. It targets each position in turn, and inserts each payload into that position in turn. Positions which are not targeted during a given request are not affected - the position markers are removed and any text which appears between them in the template remains unchanged. This attack type is useful for testing a number of data fields individually for a common vulnerability (e.g. cross-site scripting). The total number of requests generated in the attack is the product of the number of positions and the number of payloads in the payload set.
battering ram - This uses a single set of payloads. It iterates through the payloads, and inserts the same payload into all of the defined positions at once. This attack type is useful where an attack requires the same input to be inserted in multiple places within the HTTP request (e.g. a username within the Cookie header and within the message body). The total number of requests generated in the attack is the number of payloads in the payload set.
pitchfork - This uses multiple payload sets. There is a different payload set for each defined position (up to a maximum of 8). The attack iterates through all payload sets simultaneously, and inserts one payload into each defined position. I.e., the first request will insert the first payload from payload set 1 into position 1 and the first payload from payload set 2 into position 2; the second request will insert the second payload from payload set 1 into position 1 and the second payload from payload set 2 into position 2, etc. This attack type is useful where an attack requires different but related input to be inserted in multiple places within the HTTP request (e.g. a username in one data field, and a known ID number corresponding to that username in another data field). The total number of requests generated by the attack is the number of payloads in the smallest payload set.
cluster bomb - This uses multiple payload sets. There is a different payload set for each defined position (up to a maximum of 8). The attack iterates through each payload set in turn, so that all permutations of payload combinations are tested. I.e., if there are two payload positions, the attack will place the first payload from payload set 1 into position 1, and iterate through all the payloads in payload set 2 in position 2; it will then place the second payload from payload set 1 into position 1, and iterate through all the payloads in payload set 2 in position 2. This attack type is useful where an attack requires different and unrelated input to be inserted in multiple places within the HTTP request (e.g. a username in one parameter, and an unknown password in another parameter). The total number of requests generated by the attack is the product of the number of payloads in all defined payload sets - this may be extremely large.

Payloads tab

This tab is used to configure one or more sets of payloads. If the "pitchfork" or "cluster bomb" attack types are defined (see Positions tab) then a separate payload set must be configured for each defined payload position (up to a maximum of 8). Use the "payload set" drop-down menu to select which payload set to configure.

For each payload set, it is possible to define the "source" of payloads to use (e.g. preset list, character blocks, brute forcer, etc.), and also various additional processing to be performed on each payload. A large number of payload sources are available within Burp Intruder. Some of these are highly configurable and provide for a huge variety of customoised attacks. The source for the current payload set is selected using the drop-down menu. Each payload source is explained separately below.

Payload Sources

Preset list

This is the simplest payload source, and configures a preset list of payload items:

The main controls for configuring the list are at the bottom right of the panel. Items can be added manually using the text box and the "add" button. The "add from list" pull-down menu can be used to add predefined lists of useful payloads, including common usernames and passwords, strings designed to detect common vulnerabilities such as SQL injection, etc. The "load." button is used to import items from a text file. The "paste" button adds a list of items from the clipboard. The "delete" button removes the selected item, and the "clear" button removes all items from the list.

Runtime file

This payload source configures an external text file from which payloads will be read at runtime. This is useful when a very large list of predefined payloads is needed, to avoid holding the entire list in memory. One payload is read from each line of the file, hence payloads may not contain newline characters.

Custom iterator

This payload source provides a powerful way to generate custom permutations of characters or other items according to a given template. For example, a payroll application may identify individuals using a personnel number of the form AB/12; you may need to iterate through all possible personnel numbers to obtain the details of all individuals.

The custom iterator defines up to 8 different "positions" which are used to generate permutations. Each position is configured with a list of items, and an optional "separator" string, which is inserted between that position and the next. In the example described above, positions 1 and 2 would be configured with the items A - Z, positions 3 and 4 with the items 0 - 9, and position 2 would be set with the separator character /. When the attack is executed, the custom iterator iterates through each item in each position, to cover all possible permutations. Hence, in this example, the total number of payloads is equal to 26 * 26 * 10 * 10.

The "scheme" drop-down menu can be used to select a preconfigured setup for the custom iterator. These can be used for various standard attacks or modified for customised attacks. Available schemes include "directory / file . extension", which can be used to enumerate web content, and "password + digit" which can be used to generate an extended wordlist for password guessing attacks.

The controls at the bottom right are used to configure the items at each position. They function in the same way as the controls in the preset list source. The "clear all" button removes all configuration from all positions of the custom iterator.

Character substitution

This payload source takes a preset list of payload items, and produces several payloads from each item by replacing individual characters in the item with different characters, according to customisable rules. This payload source is useful in password guessing attacks, e.g. for producing common variations on dictionary words:

The controls at the bottom right are used to configure the list of preset items. They function in the same way as the controls in the preset list source.

The list of checkboxes on the right is used to configure the substitution rules. When the attack is executed, the character substitution source works through each of the preset items in turn. For each item, it generates a number of payloads, to include all permutations of substituted characters according to the defined rules. For example, for the first item in the above screenshot, the following payloads will be generated:

aahed
4ahed
a4hed
44hed
aah3d
4ah3d
a4h3d
44h3d

Case substitution

This payload source takes a preset list of payload items, and produces one or more payloads from each item by adjusting the case of characters within each item. This payload source may be useful in password guessing attacks, e.g. for producing case variations on dictionary words. 

The controls at the bottom right are used to configure the list of preset items. They function in the same way as the controls in the preset list source.

The checkboxes on the right are used to configure the case substitution rules. The available rules perform the following functions:

no change - the item is added to the payload set without being modified
to lower case - all letters in the item are converted to lower case, and the result is added to the payload set
to upper case - all letters in the item are converted to upper case, and the result is added to the payload set
to Propername - the first letter in the item is converted to upper case, the subsequent letters are converted to lower case, and the result is added to the payload set
to ProperName - the first letter in the item is converted to upper case, the subsequent letters are not changed, and the result is added to the payload set

When the attack is executed, the case substitution source works through each of the preset items in turn. For each item, it generates a payload for each of the selected case substitution rules. If the rule results in a new unique payload, it is added to the payload set (i.e. duplicate payloads are discarded). For example, for the first item in the above screenshot, the following payloads will be generated:

aahed
AAHED
Aahed

Recursive grep

This payload set works together with the "extract grep" function (which is explained below). It allows payloads to be generated recursively on the basis of responses to earlier requests. The "extract grep" function captures a portion of a server response following a matched regular expression. With "recursive grep" payloads, the captured text from the previous server response is used as the payload for the subsequent request. 

This can be used for various enumeration tasks. For example, it may be possible to enumerate the contents of a database via SQL injection by recursively submitting queries of the form:

union select name from sysobjects where name>'a'

The server's error message discloses the name of the first database object:

Syntax error converting the varchar value 'accounts' to a column of data type int.

The query is then repeated using 'accounts' to identify the next object. This task can be easily automated using recursive grep payloads to quickly enumerate all of the objects within the database.

The payload to use in the first request must be manually specified. The payload source can be configured to stop when duplicate successive recursive grep items are found, as this usually indicates that the enumeration is complete. Note that because of the nature of this payload source, attacks which use it cannot use multiple request threads.

Illegal Unicode

This payload source takes a preset list of payload items, and produces a number of payloads from each item by replacing a specified character within each item with illegal Unicode-encodings of a specified character. This payload source may be useful in attempting to circumvent input validation based on pattern-matching, for example defences against path traversal attacks which match on expected encodings of the ../ and ..\ sequences.

The controls at the bottom right are used to configure the list of preset items. They function in the same way as the controls in the preset list source.

The two text boxes at the top configure the character to be substituted within each preset item (here *), and the character to be used as the basis for the illegal encodings (here /). The latter can be specified using the ASCII character itself, or the two-digit hex code for the character (e.g. 00) - this is useful for specifying non-printable ASCII characters, such as null.

The controls in the middle configure the types of illegal encodings which will be generated. These are explained below:

maximum overlong UTF-8 length - The Unicode encoding scheme allows up to 6 bytes to be used to represent a single character. Basic ASCII characters (0x00 - 0x7F) are correctly represented using a single byte. However, it is possible to represent these in the Unicode scheme using more than one byte (i.e. "overlong" encoding). This drop-down menu is used to specify whether overlong encoding should be used, and if so to set the maximum size that should be used.
illegal UTF-8 variants - This option is available if a maximum overlong UTF-8 length of 2 bytes or more is selected. When a character is encoded with more than one byte, the bytes following the first should take the binary form 10xxxxxx, to designate that they are continuation bytes. However, the most significant bits of the first byte also identify how many continuation bytes will follow, so Unicode decoding routines may safely ignore the first 2 bits of continuation bytes. This means that three illegal variants of each continuation byte are possible, with the binary forms 00xxxxxx, 01xxxxxx and 11xxxxxx. If this option is selected, then the illegal Unicode payload source will generate 3 additional encodings for each continuation byte.
max permutations - This option is available if a maximum overlong UTF-8 length of 3 bytes or more is selected, and "illegal UTF-8 variants" is selected. If the "max permutations" option is not selected, then the illegal Unicode payload source will work through each continuation byte in turn when generating illegal variants; for each continuation byte, three illegal variants will be generated and the other continuation bytes will be unchanged. If the "max permutations" option is selected, however, then the illegal Unicode payload source will generate all permutations of illegal variants for continuation bytes - i.e. more than one continuation byte will be modified simultaneously. This feature may be useful in attempting to circumvent advanced pattern-matching controls on the target system.
illegal hex - This option is always available. When the list of illegally-encoded items has been generated using overlong encoding and illegal variants of continuation bytes (if selected), it is possible to modify the hexadecimal encoding of the resultant byte sequences to confuse certain pattern-matching controls. Hex encoding uses the characters A - F to represent the decimal values 10 - 15. However, some hex decoders interpret G as decimal 16, H as decimal 17, etc. So 0x1G may be interpreted as decimal 32. In addition, if illegal hex characters are used in the first position of a two digit hex code, then the resultant decoding overflows the size of a single byte, and in this case some hex decoders only use the 8 least significant bits of the resulting number. So 0xG1 may be decoded as decimal 257, which is then interpreted as decimal 1. Each legal two digit hex code has between 4 and 6 corresponding illegal hex representations which are interpreted as that same hex code if decoded as described above. If the "illegal hex" option is selected, then the illegal Unicode payload source will generate all possible illegal hex encodings of each byte in the list of illegal-encoded items.
max permutations - This option is available if a maximum overlong UTF-8 length of 2 bytes or more is selected, and "illegal hex" is selected. If the "max permutations" option is not selected, then the illegal Unicode payload source will work through each byte in turn when generating illegal hex; for each byte, between 4 and 6 illegal hex encodings will be generated and the other bytes will be unchanged. If the "max permutations" option is selected, however, then the illegal Unicode payload source will generate all permutations of illegal hex for all bytes - i.e. more than one byte will be modified simultaneously. This feature may be useful in attempting to circumvent advanced pattern-matching controls on the target system.
add % prefix - If this option is selected, then the % character will be inserted before each two digit hex code in the payloads generated.
lower case hex - This option determines whether lower or upper case alphabet characters will be used in hex codes.
max encodings - This option places a ceiling on the number of illegal encodings that will be generated. This can be useful if large overlong encodings are being used and / or max permutations have been selected, as these options may generate huge numbers of illegal encodings.

When the attack is executed, this payload source iterates through the list of preset items, and for each preset item replaces all instances of the specified character with each item in turn in the set of illegal encodings.

Character blocks

This payload source generates character blocks of specific sizes using a given input string. It can be useful in detecting buffer overflow and other boundary condition vulnerabilities in software running in a native (unmanaged) context:

The "string" field specifies the input string from which the character blocks will be generated. The "min" and "max" fields specify the lengths of the smallest and largest character blocks that may be generated. The "step" field specifies the increment in the length of each character block.

Numbers

This payload source generates numbers, either sequentially or at random, in a specified format:

The "from" and "to" fields specify the smallest and largest number that may be generated. If "sequential" is selected, the numbers start at the value in the "from" field, and are incremented by the value in the "step" field. If "random" is selected, the "how many" field specifies the number of numbers to be generated. Numbers can be generated in decimal or hexadecimal form. If hexadecimal is selected, then the "from", "to" and "step" fields must contain hexadecimal integers; otherwise they may contain decimal integers or fractions.

The controls on the right-hand side specify the number format which will be used.

Dates

This payload source generates dates between a specified range, at a specified interval, in a specified format. This payload source may be useful during data mining (e.g. trawling an order book for entries placed on different days) or brute forcing (e.g. guessing the date of birth component of a user's credentials):

The dates generated start with the date specified in the "from" controls, and are incremented by the interval specified in the "step" controls, up to or including the date specified in the "to" controls. Several predefined date formats can be selected in the "format" pull-down menu, or a custom date format can be entered in the text field. The following examples illustrate the codes that can be used to specify custom date formats:

Brute forcer

This payload source generates a set of payloads of specified lengths which contain all possible permutations of a specified character set.

Null payloads

This payload source generates "null" payloads - i.e. zero-length strings. It can generate a specified number of null payloads, or continue indefinitely.

This payload source is useful when an attack requires the same request to be made repeatedly, without any modification to the basic template. To achieve this, a single pair of position markers should be placed together anywhere in the request template (see Positions tab). This can be used for a variety of attacks, for example harvesting cookies for sequencing analysis, application-layer denial-of-service attacks where requests are repeatedly sent which initiate high-workload tasks on the server, or keeping alive a session token which is being used in other intermittent tests.

Payload processing

For each payload set, in addition to the "source" of payloads to use, it is possible to define various additional processing to be performed on each payload. This processing is carried out after all manipulation performed by the selected payload source:

The case settings perform the following functions:

do not modify - No processing is performed.
to lower case - All letters in the payload are converted to lower case.
to upper case - All letters in the payload are converted to upper case.
to Propername - The first letter in the payload is converted to upper case and the subsequent letters are converted to lower case.
to ProperName - The first letter in the payload is converted to upper case and the subsequent letters are not changed.

The match / replace settings perform the following functions:

match regex - Specify a Perl-like regular expression to match within each payload.
replace with - Specify a string to replace the matched expression.
replace all - Specify whether to replace all matched occurrences, or only the first.

The encoding settings perform the following functions:

do not encode - No processing is performed.
URL-encode these characters - Any of the specified characters which appear within the payload string are URL-encoded (e.g. space characters are replaced by %20). This is useful where spaces or other problematic characters appear in payloads that are inserted into the URL or message body; these may cause some web servers to return errors unless properly encoded for safe transmission over HTTP.
base-64 encode - This adds any specified prefix and suffix to the payload, and base-64 encodes the entire string. A possible use of this function is in brute forcing Basic HTTP authentication controls. Adding the prefix "username:" to the payload enables a simple word list to be used to perform password guessing against the specified username.
hash - This adds any specified prefix and suffix to the payload, and takes a cryptographic checksum of the entire string, using the selected algorithm (MD5, SHA, etc). This function may be useful when attacking custom authentication schemes that use hashed values.

Options tab

This tab contains various configuration options which control the behaviour of individual attacks.

These options are used to configure the manipulation of HTTP headers in generated requests.

If the "update Content-Length header" box is checked, then Burp Intruder will add or update the Content-Length HTTP header in each request, with the correct value for the length of the HTTP body of that particular request. This feature is usually essential for attacks which insert variable-length payloads into the body of the template HTTP request. The HTTP specification, and most web servers, require the correct value for the length of the HTTP body to be specified using the Content-Length header. If the correct value is not specified, then the target server may return an error, may respond to an incomplete request, or may wait indefinitely for further data to be received in the request.

If "set Connection: close" is checked, then Burp Intruder will add or update the Connection HTTP header to request that the connection is closed following each individual request. In some cases (when the server does not itself return a valid Content-Length or Transfer-Encoding header), this option may allows attacks to be performed more quickly.

If the "add Cookie header" box is checked, then Burp Intruder will add or update the Cookie HTTP header in each request. The value of the cookie will first be obtained using the separate request specified in the text box. This function can be used in two ways:

• If the "reuse cookies" box is checked, then a single cookie will be obtained at the beginning of the attack. This cookie will be inserted into each subsequent request. This function can be useful if an attack is being configured in advance, or may be executed multiple times, but must use a currently valid session token in order to work correctly. If an authenticated session is required for the attack to work, then the cookie request can be used to POST valid authentication credentials to the application to obtain a token for an authenticated session.
• If the "reuse cookies" box is not checked, then a fresh cookie will be obtained prior to each request of the attack. Effectively the attack will alternate a "nice" request, which obtains a valid cookie using the same specified request each time, and a "nasty" request built from the template request in the Positions tab and including the obtained cookie. This function can be useful if an attack is targeting an element of the application which uses a session token to maintain state, and will only tolerate a small number of malicious or exception events before, e.g., responding to all subsequent requests with an error message or a redirect. An example of this would be a login page which will only process input within a valid session, and will reject all requests within that session if three failed login requests are received.

The concurrent threads setting determines whether the attack will launch requests synchronously in a single thread, or concurrently using multiple threads. Using multiple threads can rapidly accelerate a large attack, where the main time factor is the latency between issuing each request and receiving a response. It can be used to test for concurrent processing vulnerabilities in applications. And it can be used to increase the effectiveness of application-layer denial-of-service attacks.

The throttle settings are used to configure any time delay required between requests. A fixed delay may be desirable as a stealth precaution, to avoid a performance impact, to preserve bandwidth or processing power for other activities, or to perform a required action periodically, such as keeping alive a session token which is being used in other intermittent tests. A variable delay can be useful to automate the detection of session timeout values.

The start settings determine whether the attack will begin immediately when launched, or will begin after a specified delay, or will wait until the "resume" command is selected (see Results view). This function can be useful if an attack is being configured which will be executed at some future point, or saved for future use.

The storage settings determine whether and how the attack will save the contents of individual requests and responses. This can dramatically effect the amount of system resources consumed by the Burp Intruder process.

If the "DoS mode" option is selected, then the attack will issue requests as normal but will not wait to process any responses received from the server. As soon as each request is issued, the TCP connection is closed. This function can be used to perform application-layer denial-of-service attacks against vulnerable applications, by repeatedly sending requests which initiate high-workload tasks on the server.

The "grep" settings are used to configure various pattern-matching based tests to be performed at runtime on server responses. There are three types of tests:

match grep - This is used to check each server response for specified expressions, either simple pattern matches or Perl-like regular expressions. For each specified expression, the attack will include a column in the results table indicating whether a match was found. This basic feature has a wide variety of uses, for example: in password guessing attacks, scanning for phrases such as "password incorrect" or "login successful"; in testing for SQL injection vulnerabilities, scanning for messages containing "ODBC", "error", etc.

If regular expressions are used as matching expressions, then these may contain newline characters.

extract grep - This is used to check each server response for specified expressions, and if present to extract the text immediately following the matched expression (up to a specified delimiter or maximum length). For each specified expression, the attack will include a column in the results table containing the text extracted from each server response. This feature can be used for data mining, where access has been gained to a web page containing useful information, and an automated means of extracting this information is required. For example, if you have gained access to a user administration page, which is used to access or update the account information of the user whose ID is specified in the URL query string, then you can execute an attack which iterates through user IDs and extracts the username and password of each user.

If the same matching expression is added multiple times in succession, then each server response will be searched for multiple occurrences of that expression, and the text immediately following each occurrence will be captured. This can be useful, e.g. when an HTML table contains useful information but there are no unique prefixes with which to automatically pick out each item.

payload grep - This is used to check each server response for the payload string(s) which were used in the corresponding request. This feature is useful in detecting cross-site scripting and other response injection vulnerabilities, which can arise when user input is dynamically inserted into the application's response.

If the "match against pre-encoded payloads" option is selected, then responses are searched for the raw form of each payload string before any encoding was applied (see Payload processing). Setting this option is normally desirable - for example, if you use XSS test payloads containing typographical characters, these will typically need to be URL-encoded in the payload processing options, but will appear in responses in their pre-encoded form if the application is vulnerable.

The redirect settings control whether Burp Intruder will follow HTTP redirects (i.e. those with a 3xx status code and a Location header containing a new URL) when performing an attack. If the option is selected, then when a redirect is received Intruder will request the redirection URL (following up to 10 redirections if necessary), and record the details of the subsequent response within the results. A column in the results table will indicate whether a redirect was followed for each individual result. Note that off-site redirects are not followed, to prevent you inadvertently attacking third-party applications.

The option to follow redirects is often useful when an application returns a 3xx response to various kinds of input, with the more interesting features of the application's processing of your request being returned when the redirection target is requested. For example, when fuzzing for common vulnerabilities, the application may frequently return a redirect to an error page - this page may contain useful information about the nature of the error which can be used to diagnose bugs like SQL injection.

Note that in some situations it may be necessary to use only a single-threaded attack when redirects are being followed, for example if the application stores within the session the information which is returned by the next request to the redirection target. Note also that automatically following redirects may sometimes cause problems for your attack - for example, if the application responds to some malicious requests with a redirection to the logout page, then following redirects may result in your session being terminated when it would not otherwise do so.

If the "process cookies in redirects" option is selected, then any cookies set in the 3xx response will be resubmitted when the redirection target is followed. For example, this option may be necessary if you are attempting to brute force a login challenge which always returns a redirection to a page indicating the login result, and a new session is created in response to each login attempt.

Launching an attack

To create a new attack, use the control panel tabs to set the required configuration, then select "start" from the "Intruder" menu. To load a saved attack, select "open" from the "Intruder" menu, and choose the required file.

When a new attack is executed, various validation checks are performed on the specified configuration. This includes verifying that payload position(s) and payload set(s) are correctly defined, that timing and grep settings are valid, etc. Some failures generate errors which prevent the attack from executing; others generate warnings which may be ignored.

Each attack opens in a separate window. This window (the "results view") displays the results of the attack as they are generated, and also contains a number of options for controlling the attack, and saving the results, server responses and the attack itself.

Results view

The following is an example of the results view for an attack performing basic content enumeration on a target website:

This attack uses the sniper attack type (see Positions tab) to make requests for a series of common names of web pages. For this attack type, the results view displays by default the number of each request, the payload position used (if more than one is configured), the payload inserted, the HTTP status code received from the server, whether or not an error or timeout occurred, and the length of the server's response. Additional results columns that can be displayed include the "received response" and "finished response" timers for each request, and any cookies received. Various configuration options, such as the grep functions, will cause additional columns to appear in the results view. Columns can be hidden or revealed using the "view" menu. The set of results can be sorted according to the contents of any results column by clicking on the relevant header (and reverse-sorted by shift-clicking the header).

A key part of effectively interpreting the results of an attack is locating interesting or successful server responses, and identifying the requests which generated these. Interesting responses can usually be differentiated through at least one of the following:

• a different HTTP status code;
• a different length of response;
• the presence or absence of certain expressions;
• the occurrence of an error or timeout; or
• the time taken to receive or complete the response.

For example, in a content discovery exercise, requests for existing resources might return a "200 OK" response of varying lengths, while requests for nonexistent resources might return a "404 Not found" response, or a "200 OK" response containing a fixed-length custom error page. Or in a password guessing attack, failed login attempts might generate a "200 OK" response containing the keywords "login failed", while a successful login might generate a "302 Object moved" response, or a "200 OK" response of a different length containing the word "welcome".

Burp Intruder can provide assistance in identifying any of the above differentiators. The grep functions (see Grep tab) can be used to mark responses containing known keywords, or to extract interesting information from key parts of the page. In the results view, results can be sorted by clicking a column header, or reverse sorted by shift-clicking the header. In the above example, the HTTP status code is the main differentiator of interesting results, and the results have been sorted to pinpoint these.

If the attack was configured to store requests and./or responses, then you can double-click an individual result to display details of the request and response. This display provides detailed analysis and rendering of each HTTP message. The "previous" and "next" buttons can be used to cycle through the set of results. If the table in the results view has been sorted, then the results will be displayed in the sequence currently showing in that view.

You can use the "action" button to send the request or response to other Burp Suite tools, such as Repeater or Decoder. You can also right-click any item in the results table to show a context menu allowing the item to be sent to other tools.

Results menus

The results view contains several menus with commands for controlling the attack, and saving the results, server responses and the attack itself. These are described below.

Attack menu

This contains commands to pause, resume, or repeat the attack.

Save menu

attack - This is used to save a copy of the current attack, including results. The saved file can be loaded for further use from within the Burp Intruder control panel.
results table - This is used to save the results table as a text file. Individual rows and columns can be selected, or the entire table can be saved. The field delimiter can also be configured. This function is useful for exporting the results into a spreadsheet for further analysis, or for saving a single column (such as data mined using the extract grep function) to be used as an input file for subsequent attacks or other tools.
server responses - This is used to save the full responses received from the server to all requests. These can either be saved in individual files (sequentially numbered), or concatenated in sequence into a single file. 

View menu

This contains commands to view or hide each of the available data columns in the results table (the columns available depend upon the configuration of the current attack).