In this article we’ll summarise how various active and passive scanning tools can automate and streamline your Burp Suite workflow – saving you time in the process.
Outline
📁 Goals for Burp automation
📂 Burp extensions and built-in tools used
├─ Extensions
├─ Built-in tools
📁 Automated workflow
📂 Active scans
├─ BCheck
├─ Burp Bounty
📂 Passive scans
├─ Passive scanner
├─ Passive live crawler
├─ Error Message Check and Response Grepper
├─ BCheck
📁 Logger++
📁 Manual testing still matters
Burp Suite automation: Our goals
The goal of this Burp Suite automation is to save time and automate less complex tasks that are needed to improve manual testing. The automation should cover the very core of our target application and collect as much information as possible. The primary method is using passive scanners to avoid making too much noise as an attacker.
All the information we collect helps us to better understand the application and thereby improve our active automation in the long term.
Burp extensions and built-in tools used
Extensions
- BChecks
- Burp Bounty (Pro extension)
- Error Message Checks (Pro extension)
- Response Grepper (alternative to Error Message Checks)
- Logger++
Built-in tools
- Passive scanner (Pro version)
- Passive crawler
Automated Burp workflow
The automated workflow is divided into two fields: the blue ones represent passive scans while the red ones represent active scans.
The passive scanners will benefit from analysing the outcomes of the active scanners. For example, an active scanner that has triggered a behavior in the target application that leaks an error message in the application's response. The passive scanner will analyse and report the discovered error message to Burp's dashboard, allowing the scanners to work efficiently together and keep our results organised in Burp's dashboard.
As shown in the workflow image above, we will handle the distribution of responses in the following way: responses captured by the proxy will be given to both the passive and active scanner, while responses intercepted by the repeater, extensions and scanners will only be given to the passive scanner.
This structure is built to keep an efficient flow and synchronise all ongoing scans. The passive scanner can dig deep into the responses produced by the active scanners. and the active scanners will keep a low request volume to our target. Since the active scanners have a low request volume to our target, the passive scanner using our hardware's performance will be able to handle the responses without stacking up a massive queue of tasks.
We will have all our ongoing live tasks on Burp's dashboard tab, which will resemble this setup:
Active scans with Burp
The active scans will contain our automated attack process. The primary goal of this automation is not to fully exploit the application with these attacks. Instead, it is to discover and trigger as much back-end functionality as possible, by performing black-box techniques on the target application.
BCheck
BCheck is a fairly new feature in Burp, at the time of writing this article. The main reason to use it for our purposes is that it allows us to write BCheck scripts directly in Burp itself. This is useful because it allows us to quickly write new BChecks to perform attack techniques adapted to our collected scan results.
The second reason is that, rather than running complex scans, we can conduct scans like fuzzing a list of files and directories on newly discovered hosts or preform friendly payload spraying to detect possible behaviors within our targets.
It's good practice to keep track of the requests made for each BCheck that performs an active scan. We can do this by adding a custom header - eg: X-BCheck-Track: bcheck={BCHECK_NAME}, tag={TAG}. With this header, we can more easily track and organise all BCheck requests that appear in Logger++.
Burp Bounty
The Burp Bounty extension is an excellent choice when it comes to slightly more complex scans, with the main advantage of offering great customisation. We can both provide and tamper with the payload used during the scanning process. Burp Bounty also gives us the ability to select detection rules, which allows us to leverage our experience of how different payloads may affect the application we are pentesting.
Passive scans with Burp
The passive scans play an important role as a second layer of detection. They can take advantage of the performance of our own hardware to search for errors or patterns and/or compare behaviors already performed by the active scans. This way, we can do more in-depth analysis of the responses from the target, which can lead to discoveries that the active scanner missed.
Passive scanner
Burp's built-in passive scanner is great because it covers a wide range of detection techniques. These techniques include detecting services, version banners, misconfiguration and a whole lot more.
We will use Burp's built-in passive scanner to collect as much information as possible from our target.
However, in some cases the JavaScript analyzer used in the passive scanner can draw a lot of hardware performance. If you encounter such issues, read Burp's official documentation for configuration advice on mitigating this problem.
Passive live crawler
The passive crawler helps us build up a base of the sitemap for our target. We can analyse the discovered routes that are passively added, and get an idea of how the application is structured and what functionalities might be available for us to test.
Error Message Check and Response Grepper
Error and pattern discovery is one of the most important parts of automation. By looking for errors and patterns within your target, you can extract a lot of useful information. This information can be used both to understand your target and to adapt your active scanners in the future, as it can catch trace errors and other differences in responses that the active scanner itself may have missed.
BCheck
In the passive scanning process, BChecks will be used to discover the technologies and service that the target application is running. By finding out the technology and/or service of the application, we can filter out data and payloads. By extracting information that allows us to see that our target application mainly uses PHP as its programming language, for example, we can ignore/reduce the amount of payloads related to Java, Ruby, Python and other languages. This allows our automation to maintain its flow and avoid building up a large queue of unnecessary processes.
As mentioned before (see section: Active scans : BCheck), adding a tracking header to each BCheck that defines a primary tag and the name of the BCheck used is an effective way to keep track of your requests (see section: Logger++).
Logger++
The Logger++ extension is a powerful extension that allows us to log every request and response from all sources in Burp. It offers advanced filtering and highlighting rules that we will use to monitor and analyse all our traffic. We will also use Logger++ to troubleshoot our automation process if something goes wrong.
As the image above shows, we can highlight requests from various tools and requests containing the custom header that we use to track processes such as BCheck scans.
Manual testing still matters
Automation is generally useful, but you should always try to keep the automated workflow aligned with your manual testing.
Automation will always miss things, so don't rely on it entirely. Rather, combine with manual testing and examine the results of both. This way you can focus more on the creativity of hacking and spend less time looking for new features in the application.