1. Support Center
  2. Documentation
  3. Desktop editions
  4. Tools
  5. Intruder
  6. Options

Attack options

This tab contains Intruder attack options for request headers, the request engine, attack results, grep match, grep extract, grep payloads, and redirections. You can edit these options in the main Intruder UI before launching an attack, and most settings can also be modified in the attack window when the attack is already running.

Attack request headers

These settings control whether Intruder updates the configured request headers during attacks. Note that you have full control over the request headers via the request template in the payload positions tab. These options can be used to update those headers per-request in ways that are normally helpful.

The following options are available:

Request engine

These settings control the engine used for making HTTP requests in the Intruder attack. The following options are available:

Careful use of these options lets you fine tune the attack engine, depending on the performance impact on the application, and on your own processing power and bandwidth. If you find that the attack is running slowly, but the application is performing well and your own CPU utilization is low, you can increase the number of threads to make your attack proceed faster. If you find that connection errors are occurring, that the application is slowing down, or that your own computer is locking up, you should reduce the thread count, and maybe increase the number of retries on network failure and the pause between retries.

Attack results options

These settings control what information is captured in the attack results. The following options are available:

Grep - match

These settings can be used to flag result items containing specified expressions in the response. For each item configured in the list, Burp will add a new results column containing a checkbox indicating whether the item was found in each response. You can then sort on this column (by clicking the column header) to group the matched results together.

Using this option can be very powerful in helping to analyze large sets of results, and quickly identifying interesting items. For example, in password guessing attacks, scanning for phrases such as "password incorrect" or "login successful" can locate successful logins; in testing for SQL injection vulnerabilities, scanning for messages containing "ODBC", "error", etc. can identify vulnerable parameters.

In addition to the list of expressions to match, the following options are available:

Grep - extract

These settings can be used to extract useful information from responses into the attack results table. For each item configured in the list, Burp will add a new results column containing the text that was extracted for that item. You can then sort on this column (by clicking the column header) to order the extracted data.

This option is useful for mining data from the application and can support a wide range of attacks. For example, if you are cycling through a range of document IDs, you can extract the page title of each document looking for interesting items. If you have found a function that returns details of other application users, you can iterate through user IDs and retrieve relevant fields about users looking for administrative accounts or even passwords. If a "forgotten password" function takes a username as a parameter and returns a user-configured password hint, you can run through a list of common usernames and harvest all the associated password hints, and then visually scan through the list looking for easily guessed passwords.

If the same matching item 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, for example when an HTML table contains useful information but there are no unique prefixes with which to automatically pick out each item.

For details of configuring the details of items to extract, see the help on using the response extraction rule dialog.

Optionally, you can configure a maximum length that Burp should capture for each item.

Grep - payloads

These settings can be used to flag result items containing reflections of the submitted payload. If the option is enabled, Burp will add a new results column containing a checkbox indicating whether the value of the current payload was found in each response. (If more than one payload set is used, a separate column will be added for each payload set.)

This feature can be 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.

The following options are available:

Handling redirections during attacks

These settings control how Burp handles redirections when performing attacks. It is often necessary to follow redirections to achieve the objectives of your attack. For example, in a password guessing attack, the result of each attempt might only be displayed by following a redirection. When fuzzing, relevant feedback might only appear in an error message that is returned after an initial redirection response.

The following options are available:

Burp will follow up to 10 chained redirections if necessary. A column in the results table will indicate whether a redirect was followed for each individual result, and the full requests and responses in the redirection chain are stored with each result item. The types of redirection that Burp will process (3xx status code, Refresh header, etc.) are configured in the suite-wide redirection options.

Some further points are worth noting in relation to redirections: