• Download
• Buy
• Help
• Forum
• Blog
• Contact
• Login

• Home
• >Burp
• >Help
• >Intruder

Burp Intruder Help

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 let you configure one or more attacks simultaneously, in their own numbered tabs. You can create a new tab, or rename existing tabs using the Intruder menu.

The configuration of each individual attack is carried out in a number of sub-tabs (target, positions, payloads, options). The easiest way to create a new attack is to locate the relevant base request within another Burp tool (such as the proxy history or site map), and choose "send to intruder" from the context menu. This will populate the target and positions tabs with the relevant details. You can use the Intruder menu to control how the payloads and options tabs are set up when you create a new attack tab. You can choose to use the default attack configuration, copy the configuration from the first attack tab, or copy from the last attack tab. In this way, you can set up a standard attack configuration in your first attack tab (e.g. for fuzzing all parameters and grepping for error messages) and have this configuration copied into each new attack which you send to intruder. You can also copy attack configurations between arbitrary tabs, or save and load attack configurations, using the Intruder menu.

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

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

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 editor 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. There is a context menu providing access to various functions.

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, site map 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 highlighted for clarity. You can use the option on the Intruder menu to control whether payload markers are positioned so as to replace or append the existing parameter values. Above the request editor, 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 editor, if necessary.
• clear - This deletes the entire contents of the editor.

Note that automatic placement of payload positions recognises XML-formatted data within the currently-selected range of the request template. Some applications send XML-encapsulated data within a multipart request body, for example:

If you perform auto-placement of payload positions on the entire message, then Intruder will mark the whole of the XML block as a single insertion point, which is probably not what you want. Instead, if you manually select the exact XML block, then the auto-placement function will recognise that the selection contains XML, and will mark the individual XML parameter values as insertion points.

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 customised 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.

You can customise the predefined lists of payloads that are accessible on the "add from list" menu. To do this, select "configure preset payload lists" from the Intruder menu, and choose your own directory containing payload files. You can use the "copy" button to copy all of Burp's built-in payload lists into your custom directory, to use alongside your own payloads lists:

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:

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:

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:

E	Sat
EEEE	Saturday
d	7
dd	07
M	6
MM	06
MMM	Jun
MMMM	June
yy	03
yyyy	2003
/ . : etc	/ . :

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.

Char frobber

This payload source operates on the existing base value of each payload position, or on a specified string. It cycles through the base string one character at a time, incrementing the ASCII code of that character by one.

This payload source is useful when testing which parameter values, or parts of values, have an effect on the application's response. In particular, it can be useful when testing which parts of a complex session token are actually being used to track session state. If modifying the value of an individual character within the session token still causes your request to be processed within your session, then it is likely that this character in the token is not actually being used to track your session.

Bit flipper

This payload source operates on the existing base value of each payload position, or on a specified string. It cycles through the base string one character at a time, flipping each (specified) bit in turn.

You can configure the bit flipper either to operate on the literal base value, or to treat the base value as an ASCII hex string. For example, if the base value is "ab" then operating on the literal string and flipping all bits will result in the following payloads:

Whereas treating "ab" as an ASCII hex string and flipping all bits will result in the following payloads:

This payload source can be useful in similar situations to the char frobber but where you need finer-grained control. For example, if session tokens or other parameter values contain meaningful data encrypted with a block cipher in CBC mode, it may be possible to change parts of the decrypted data systematically by modifying bits within the preceding cipher block. In this situation, you can use the bit flipper payload source to determine the effects of modifying individual bits within the encrypted value, and understand whether the application may be vulnerable.

Username generator

This payload source takes human names as input, and generates usernames using various common schemes.

For example, supplying the name "peter weiner" results in up to 115 possible usernames, as follows:

This payload source can be useful if you are targeting a particular human user, and you do not know the username or email address scheme in use within an application.

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 defined rules are executed in sequence, and can be toggled on and off to help debug any problems with the configuration. The following types of rule are available:

• add prefix
• add suffix
• match/replace
• substring (from a specified offset up to a specified length)
• reverse substring (as substring, but indexed from the end of the payload)
• modify case (same options as for the case substitution payload source)
• encode (as URL, HTML, Base64, ASCII hex and constructed strings for various platforms)
• decode (as URL, HTML, Base64 and ASCII hex)
• hash
• addition of raw payload (this can be useful if you need to include the same payload in both raw and hashed form)

Finally, you can configure which characters within the resulting payload should be URL-encoded for safe transmission within HTTP requests:

It is recommended to use this setting for final URL-encoding, rather than a payload processing rule, because the payload grep option can be used to check responses for echoed payloads before the final URL-encoding is applied.

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.

Note: Earlier versions of Burp Intruder contained options here to add a cookie header to the request, based on the response to a different request. These configurations have now been removed, and you should use the suite-wide session handling support instead.

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 retry settings determine how many times Burp will repeat a request if a network failure occurs (e.g. the connection is refused or times out), and how long it will wait between retries.

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 the attack will save the contents of individual requests and responses. Saving requests and responses consumes disk space in your temporary directory, but enables you to view these in full during an attack, repeat individual requests if necessary, and send items to other Burp tools.

If the "make unmodified baseline request" option is selected, then in addition to the configured attack requests, Burp will issue the template request with all payload positions set to their base values. This request will show as item #0 in the results table.

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.

If the "store full payloads" option is selected, Burp will store the full payload values for each result. This option consumes additional memory but may be required if you want to perform certain actions at runtime, such as modifying payload grep settings, or reissuing requests with a modified request template.

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 configured to follow redirects, 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. You can configure whether to follow only on-site (i.e. same protocol, host and port) redirects, only in-scope (defined in Target tab) redirects, or to follow all redirects.

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 attack" from the Intruder menu. To load a saved attack, select "open saved attack" 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 displays the results of the attack as they are generated, enables you to modify the attack configuration in real time, and also contains a number of options for controlling the attack, and saving the results, server responses and the attack itself.

Note: When modifying the live configuration of a running attack, you should proceed with caution and consider pausing the attack before making changes.

Results tab

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 directories. 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). You can copy the contents of a column by ctrl-clicking the header [Pro version].

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.

You can annotate individual or multiple items, by adding comments and highlights:

You can highlight individual items using a drop-down menu on the left-most table column:

And you can comment individual items in-place by double-clicking and editing the table cell:

When you have annotated interesting requests, you can use column sorting and display filters to quickly find these items later.

If the attack was configured to store requests and./or responses, then you can use the preview pane to view these or 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.

If the attack is configured to follow redirections, all intermediate responses and requests are also displayed, alongside the initial request and final response.

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

You can send the selected item to other tools, add multiple items to the Suite site map, annotate items with comments and highlights, or mark items to be re-requested. This option is useful if network errors or other problems have affected some of the results. If you have modified the base request template or other options during the attack, items to be re-requested will be rebuilt with the current configuration if possible. So, for example, if your application session has been terminated part way through an attack, you can modify the base request template with a new session token, and re-issue any failed requests so that they are executed within your new session.

At the top of the results table is a filter bar, which you can use to hide certain results, based on HTTP status code, search terms, and user-applied annotations:

As well as filtering, you can also permanently delete items from the results, by selecting one or more items in the results table, and choosing "delete" from the context menu.

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.
• attack configuration - This is used to save the configuration of the currently executing attack (not the results) enabling you to load that configuration into the main Intruder control panel to configure the same or a similar attack.

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).

Copyright © 2010 PortSwigger Ltd. All rights reserved.

• Company
• Legal
• Contact