Burp Suite is an HTTP intercepting proxy used globally to test the security of web applications. It works by intercepting communication between your server and the target application that you wish to test and is packed full of nifty features such as Spider, Scanner, and Repeater. There are too many great Burp features to cover in one session so today I am just going to show you my five favorites which I use in every penetration test.

Feature #1: Setting Up The Target Module

The first one is the target module, and it’s called scope. A scope is really important. You need to set it properly before every pen test because Burp and its modules are distinguishing which domains are going to be tested based on the settings in here. For example, you have the two fields: the first one is included in scope; the second is excluded from the scope. You can probably tell the first one is for included items, the second one is for excluded items.

I’m going to switch to the browser now and generate some traffic. My application is running a local host for 8080. Switch to the sitemap and you see all these domains, which are accessed by Burp when we refresh the page. We are only interested in localhost for 8080. So we right-click on it and say “add to the scope”. It’s now in scope. You see there is included in scope is local host.

Next thing you want to do is to review the scope and maybe exclude some stuff that you don’t want to have there or are not interested in having there. For example, right now you can see that this application will send some category request every few seconds. So let’s say we don’t want them or we are not interested in the lesson of review, and lesson menu.

Now, we can right-click on it and say “remove from the scope”. Also, from the second one. Now, the scope was updated in the target module and the proxy module is already working with the scope, which has limitations. So if you press switch back now, you see the exclude from the scope is the local host 8080 and here lesson of review, and lesson menu.

As I said, the scope settings are shared among modules. For example, a scanner module, which is not available here because is a free version of Burp, but then you have Burp Suite Professional and you can scan sites. And the scanner is distinguishing based on your scope. So it’s really important to set up scope property.

Feature #2: Reversing The Order Of Requests In Scope

If we put this back to the scope now… Defaultly, HTTP should have already been set up in the way that all the new requests are added at the end of this. So for example, now we can see 8-5, 8-7. If you wait for a few seconds, and I scroll down, you see there under new requests. The window, will not scroll through automatically, so cool thing can do if you want to monitor like traffic, like communication, is to go up, and in here, double-click on the pound. You will reverse the order and now all the new messages are added to the top. If you, for example, doing the log on, and you want to see what kind of requests are coming through Burp, you can just easily reverse the order, and you don’t have to scroll down. So I think that’s pretty useful.

Feature #3: Using The Repeater Module

Another thing I want to talk about is the repeater module. A repeater is used to repeated requests to the server, as the name is suggesting. It’s very useful for example when you do cross-site scripting and you are trying different payloads. And in that case, it’s much easier to do it in the repeater than to manually put them to your browser. Also, when you are brute-forcing, for example, log in, then you need to specify for Hydra or a similar tool. And the success and failure conditions and this is based on the responses from the server.

Now let me just quickly show you how to do that. If you go to proxy now, and HTTP history, we see I have a login request in here. Let’s send it to the repeater. In the repeater now we have two requests because I sent it twice. Two requests, which are completely the same. I’ll change the second one to something incorrect. This a wrong password. We’ll send the first one to the server, and we will see welcome. And we’ll send the second one which is incorrect in the server and we see the login error. So these are the response messages we will use in Hydra, for example, to distinguish between successful and unsuccessful login.

But what I wanted to show you is that when you are using the repeater, you will quite quickly create lots of these entries in here. And as you can see, it’s getting quite hard to navigate through them. So what I usually do, I rename them, to something more meaningful than 110 and 111. So for example, this one. It was a successful log on, so call it “okay log in.” And this was unsuccessful so let’s call it “not okay log in.” As you can see now, it makes a little bit more sense.

It’s cool for example when you are returning to the work you did a day or two days ago, and just want to quickly check something, and it is much faster when you have proper descriptions in here. And the second very useful feature is that mostly when you do penetration tests, you will also do a re-test, in a few months depending on how quickly your customers will fix, or they will think they will fix the issues. In that case, when they are retesting, and they have these tabs here properly named and properly documented, it’s much faster for you to perform the same actions you did last time. So it’s really big help.

Feature #4: Using The Proxy Module

Next thing I want to show you is in the proxy module. It’s the intercept feature. Intercept feature used to stop messages, which are coming from your browser to the server. So you can examine them, as you can see a few options here for this server which will send a message to the server. Second is the drop. The message will be deleted, and nothing will happen. You can preference it under actions like send it to different modules like the repeater, which we did previously.

It’s very useful when you, for example, you want to see how exactly log on goes. Then you can just examine them in the forward, examine forward. So that’s really useful.

The second scenario and this is really cool, is when messages have some serial numbers which are incremented every time they leave the browser and the server. In that case, it’s much easier for you to take a message, which you supported the configure properly by a browser, then changing all the fields yourself in order to be accepted by a server. What I wanted to show you, is that we can actually change those messages in the file. So I’m changing the correct passwords to incorrect one right now. Just one. Then we will forward the message. Now if you look the HTTP history, see that this is the original message. And we have a new top here, which is first says original request, second says edited request. And in the edited request, I see the message that I actually edited.

Another cool thing about this is that you have also edited flagging here. It’s showing you that this request was edited by you. You can also filter based on that. So if you click twice, it will show you all the messages you edited. That’s pretty neat.

Feature #5 – Sorting Messages In The HTTP History

The last thing I want to show you is also in the proxy module is the HTTP history. Let me just change the order. As you can see, we have many messages in here, and it’s quite hard to distinguish or to say what they are from the first look. What I usually do when something significant happens, I will just mark it. So you can pick the messages that you want to mark. Right click on them. And in here, and highlight, and change their color. For example, these are unsuccessful logins, so let’s say they will be red. And these two on the top are successful, so let’s say they will be green.

The second thing I’ll do, you can also add comments to them. So this we will call, “not okay log in” and the green ones, we will call “okay log in.”

You can see the comments here. You can see the colors. And also what is really nice that you can filter, based on the comments. For example, you can order all the messages with the same comment, which is really useful.

Another reason why I recommended doing this is that sometimes when you do penetration tests, you have to limit time windows in which you can access the service. For example, you can test only two hours a day. What I usually do in that situation is try to generate as much traffic as I can and then I would properly mark it, make comments, use different colors. Then I would analyze it offline. And it’s much easier when you are searching for the history, of what happens, much easier to navigate when you have those color distinguishing then when you can filter for the comments.

So it was my five favorite features and functionalities of Burp. I hope you enjoyed it. Thanks for watching, reading and stay secure.