Running Attacks
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:
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.
Results Tab
The Results tab contains the full details of every request issued in the
attack. You can
filter and annotate this information to help analyze it, and also use it to drive your
testing workflow.
Results Table
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.
Analyzing Results
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.
Display Filter
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.
Annotations
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.
Testing Workflow
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.
Results Menus
The results view contains several menus with commands for controlling the
attack, and carrying out other actions. 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 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.
Columns Menu
This lets you select which available columns are visible in the attack
results table.