When you have configured all of the settings for your attack, you need to launch the attack, analyze the results , and sometimes modify the attack configuration , link in with your testing workflow , or carry out other actions.
Launching an Attack
An attack can be launched in two ways:
- You can configure the attack settings in the Target, Positions, Payloads and Options tabs, and select "Start attack" from the Intruder menu.
- You can open a previously saved attack by selecting "Open saved attack" from the Intruder menu.
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 link in with your testing workflow, or carry out other actions.
The results table shows details of all requests and responses that have been made in the attack. Depending on the attack configuration, the table may contain the following columns, some of which are hidden by default and can be unhidden using the Columns menu:
- The request number. If the attack was configured to make an unmodified baseline request, this appears as item number 0 in the table.
- The position number for the current payload (for sniper attacks).
- The payload(s) used in the request.
- The HTTP status code.
- The time of day the request was made.
- The time taken to begin receiving a response (in milliseconds).
- The time taken for the response to complete (in milliseconds).
- Whether or not a network error occurred in issuing the request.
- Whether or not a timeout occurred when waiting for or processing the response.
- The length of the response in bytes.
- Any cookies received in the response.
- The results of any match grep items that are configured.
- The data extracted from any extract grep items that are configured.
- Whether or not the payload was echoed in the response, if payload grep was configured.
- The number of redirections that were followed, if configured.
- Any user-applied comment.
You can reorder the table's contents by clicking on any column header (clicking a header cycles through ascending sort, descending sort, and unsorted). For example, if you prefer the results table to grow "upwards", with the most recent items at the top of the table, then you can apply a descending sort to the request number column. You can copy the contents of a column by Ctrl-clicking the header [Pro version].
If you select an item in the table, the request and response for that item are shown in the request/response pane, provided you configured the attack to store requests and responses . If the attack is configured to follow redirections, all intermediate responses and requests are also displayed, alongside the initial request and final response. The request/response pane contains an HTTP message editor for each message, providing detailed analysis. You can also double-click an item in the table to show the request and response in a pop-up window.
A key part of effectively interpreting the results of an attack is locating interesting or successful server responses, and identifying the requests that 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.
- 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". The types of response features that are relevant will generally depend on the type of attack being performed.
You can use the following techniques to help analyze the attack results and identify interesting items:
- Click on each column header in turn, and review the sorted table to identify any anomalous items.
- Unhide additional columns to analyze response times and cookies.
- Use the display filter to remove items containing or not containing certain expressions.
- Create new match grep items to identify responses containing expressions found in some responses, and sort on the newly added columns.
- If an error message or other interesting data appears in some responses, create new extract grep items to extract this data, and sort on the newly added columns.
The results tab has a display filter that can be used to hide some of its content from view, to make it easier to analyze and work on the content you are interested in.
The filter bar above the results table describes the current display filter. Clicking the filter bar opens the filter options for editing. The filter can be configured based on the following attributes:
- Search term - [Pro version] You can filter on whether or not responses contain a specified search term. You can configure whether the search term is a literal string or a regular expression, and whether it is case sensitive. If you select the "Negative search" option, then only items not matching the search term will be shown.
- Status code - You can configure whether to show or hide responses with various HTTP status codes.
- Annotation - You can configure whether to show only items with user-supplied comments or highlights .
The content displayed within the results table is effectively a view into an underlying database, and the display filter controls what is included in that view. If you set a filter to hide some items, these are not deleted, only hidden, and will reappear if you unset the relevant filter. This means you can use the filter to help you systematically examine a large set of results (e.g. from fuzzing a request containing many parameters) to understand where different kinds of interesting responses appear.
You can annotate attack results items by adding comments and highlights. This can be useful to flag up interesting responses for further investigation.
You can add highlights in two ways:
- You can highlight individual items using the drop-down menu on the left-most table column.
- You can highlight one or more selected items using the "Highlight" item on the context menu.
You can add comments in two ways:
- You can double-click the relevant entry, within the Comment column, to add or edit a comment in-place.
- You can comment one or more selected items using the "Add comment" item on the context menu.
When you have annotated interesting requests, you can use column sorting and the display filter to quickly find these items later.
As well as displaying details of all requests and responses, the attack results let you to control and initiate specific attacks and carry out other actions, using the context menu. The following options are available:
- Scan / Spider / Send to ... - You can send any item to other Burp tools, to perform further attacks or analysis. The ability to send requests between tools forms the core of Burp's user-driven workflow .
- Show response in browser - You can use this to render the selected response in your browser, to avoid the limitations of Burp's built-in HTML renderer. When you select this option, Burp gives you a unique URL that you can paste into your browser (configured to use the current instance of Burp as its proxy), to render the response. The resulting browser request is served by Burp with the exact response that you selected (the request is not forwarded to the original web server), and yet the response is processed by the browser in the context of the originally requested URL. Hence, relative links within the response will be handled properly by your browser. As a result, your browser may make additional requests (for images, CSS, etc.) in the course of rendering the response - these will be handled by Burp in the usual way.
Request in browser - You can use this to re-issue the
selected request in your browser (configured to use the current instance
of Burp as its proxy). The following sub-options are available:
- In original session - This causes Burp to issue the request using the exact Cookie header that appeared in the original request.
- In current browser session - This causes Burp to issue the request using the cookies supplied by your browser.
- Generate CSRF PoC - [Pro version] You can use the Generate CSRF PoC function to create some HTML which, when viewed in a browser, will cause the selected request to be issued.
- Add to site map - This adds the selected item(s) to Burp's Target site map. This option is useful when you are using Intruder to perform customized content discovery , and have identified some new resources on the server which had not been added to the site map through other methods.
- Request item again - This queues the selected item(s) to be requested again by the attack engine. When the item is re-requested, the table entry for the item, and associated HTTP messages, will be updated based on the new request. This option is useful when some attack requests have failed due to network errors, or received an anomalous server response due to some intermittent problem. You can also use it if you have modified the base request or other relevant configuration during the attack, and want to re-request items that were based on the original configuration.
- Define extract grep from response - This opens the response extraction rule dialog showing the selected item's response, and lets you create a new extract grep item derived from that response. This option is useful when some attack requests have generated a different type of response than the base request (for example, a particular format of error message when fuzzing, or a different login message when guessing credentials). When you encounter a different response like this, it is often helpful to create a new extract grep item to extract an interesting part of the response, so that you can quickly review the contents of other similar responses.
- Add comment - You can use this function to add a comment to the selected item(s). See Annotations for more details.
- Highlight - You can use this function to apply a highlight to the selected item(s). See Annotations for more details.
- Delete item(s) - This function removes the selected item(s) permanently.
- Copy links - This function parses the selected item(s) for links, and copies these to the clipboard.
- Save item(s) - This function lets you specify a file to save the details of selected item(s) in XML format, including full requests and responses, and all relevant metadata such as response length, HTTP status code and MIME type.
Attack Configuration Tabs
As well as the Results tab, the attack window contains a clone of each of the configuration tabs from the main UI on which the current attack was based. This enables you to review and modify the attack configuration while the attack is underway.
For further details, see the help on each of the configuration tabs:
When modifying the configuration of a running attack, the following points should be noted:
- Some parts of the attack configuration are fundamental to the structure of the attack (such as the attack type and payload type), and cannot be changed after the attack has started.
- Changing some parts of the configuration while the attack is running may have unanticipated effects. For example, if you are using number payloads and edit the To field, then the changes will take effect as each key is pressed; if you initially delete a digit from the To field, then the attack might abruptly complete because the To field now contains a smaller number. It is strongly recommended that you pause running attacks before modifying their configuration.
The results view contains several menus with commands for controlling the attack, and carrying out other actions. These are described below.
This contains commands to pause, resume, or repeat the attack.
- Attack - This is used to save a copy of the current attack, including results. The saved file can be reloaded using the "Open saved attack" option from the Intruder menu in the main Burp UI.
- Results table - This is used to save the results table as a text file. You can choose to save all rows, or only selected rows. You can also select which columns to include, and the column delimiter. 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 for 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). You can reload the attack configuration using the "Load attack config" option from the Intruder menu in the main Burp UI.
This lets you select which available columns are visible in the attack results table.