In this video guide we’ll be covering the basics of BurpSuite, the web-application proxy. BurpSuite, also known as Burp, is an industry standard penetration testing tool. Burp is used for multiple tasks, but its primary purpose is to use the information gathered with other tools to test the vulnerabilities of the web application being pen-tested.

In this demonstration, we’ll go through the basics in 5 steps:

Step 1 – Setting up BurpSuite. In this example, we’re going to be using Burp in a test environment using the IP address 10.1.1.102. First of all, enter the IP address in to your web browser. We’re using Firefox, as it interacts best with Burp. You’ll then need to set up your web browser to accept intercepts from Burp. To do this in Firefox, open the Hamburger menu in the top right of the browser and select preferences. Then, scroll down and you should see Network Proxy; select this. You now need to specify a manual proxy that Burp will be interacting with. Because Burp is looking at a local connection, you set your local loop back address – mine is 127.0.0.1. You’ll need to set the port address too – by default Burp uses port 8080 which is typically used for a personally hosted web server. You’ll then want to utilise this proxy for all protocols, so select Set All Protocols. Then select OK and close the preferences tab. The browser is now ready to use Burp; now open Burp from the toolbar. When Burp has loaded, select create a temporary new project, and select next to start Burp. You should now see the main panel. You now want to make sure that the proxy you’ve set up in Firefox is switched on, so select the proxy tab. You should then see Intercepts, and, if you select the options tab, you should be able to see that the loop back address and port are on. If it is, this means that Burp is working.

Step 2: Intercepting your target Now that you’ve checked that Burp is connected to Firefox, you’ll want to test that Burp is intercepting the website. First, select intercept on. Then, return to the browser page and attempt to select one of the links we’re trying the link bwapp). The next page isn’t loading. This is because Burp is holding the page. From here, you can get Burp to interact with the app. When you select the link in the browser, you send a Get request in HTTP; you can confirm this by looking in the Raw section under the intercept tab where you should see Get/bwapp. As you want Burp to continue with this, you can tell it to carry on with the Get request by selecting forward. As you can see, it has done this in my web browser, and the next page on the web application has been loaded.

Step 3: Trying to get in Now that Burp has successfully intercepted the web application, you can begin to attempt to access the web application. If you return to Burp, and look at the file menu on the left hand side, you should see the IP address of the target. If you select it, you should see that Burp has automatically begun to spider through the webapp, so you can access each of the pages we have access to. Looking at the pages it’s spidered, it’s found a portal; let’s try and get in. What we want to do now is to find where the login details are entered within the HTML code. Let’s get the browser back up, and type “test” in to both the username and password fields, and select login. If you now select the proxy tab, and select “Drop” – just a warning – you may have to select this multiple times, and it may freeze for a short period – you should now be able to see the login dot PHP line; it should also give you the login you tried in cleartext.

Step 4 – set up repeater. Now that you have a potential point of entry in to the back-end of the site, you can try to test the log in. For this demonstration, we suggest you use repeater. What you first need to do is send the login information to repeater; so, on the proxy tab, select action, and then send to Repeater. If you then look at the repeater tab, you can resend the request by selecting go. In this case, we can see if there are any errors that may be created after a certain number of log in attempts from the test IP address, or we may be able to try repeatedly. As this is a test environment, it’s showing us the log in details of bee (username) and bug (password). If we return to BurpSuite, change the log-in details to reflect the known log-in details in the PHP script and press go, the repeater should now show that we can log in. Step 5 – Intrusion and Attacks Where repeater sends one request at a time, you can use intruder to send multiple requests automatically. For example, if you’ve managed to collect some data with other tools, you could now use it in BurpSuite to attempt to brute force your way in to the web app. Return to the proxy tab in Burp and send the information to the intruder tab. Selecting action, send to intruder and opening up the intruder page you should see your login request. You should also see a drop down menu for types of attack. By default, it will be set to Sniper attack but, in this example, you want to set it to cluster attack. If you then highlight the 2 positions to cluster attack – in this case the login and password – you can get Burp to load in wordlists. Burp will then use these wordlists to attempt to use these log ins to see if any of them get you in.

In this video guide we’ve shown you how to set up BurpSuite, how to intercept between Burp and the target site, how to navigate the Burp proxy, repeater, and intruder tabs, where to find the information gathered by Burps intercepts, and how to use that to try and get in to a target web app.