Hi! In this article I will focus on the Repeater module of Burp Suite, an extremely powerful tool to master on your penetration tester journey.

I am making these walkthroughs to keep myself motivated to learn cyber security, and ensure that I remember the knowledge gained by THMs rooms. Join me on learning cyber security. I will try and explain concepts as I go, to differentiate myself from other walkthroughs.

Burp Suite Repeater logo

Room URL: https://tryhackme.com/room/burpsuiterepeater

Prerequisites: https://tryhackme.com/room/burpsuitebasics

Task 1 (Outline)

This room covers the basic usage of Burp Suite: Repeater.

Nothing else to do here, so let’s move on to part 2.

Questions

Deploy the machine (and the AttackBox if you are not using your own attack VM), and let’s get started!

Answer: No answer needed

Part 2 (What is Burp Suite Repeater?)

Burp Suite Repeater allows us to craft and/or relay intercepted requests to a target at will. In layman’s terms, it means we can take a request captured in the Proxy, edit it, and send the same request repeatedly as many times as we wish.

This ability to edit and resend the same request multiple times makes Repeater ideal for any kind of manual poking around at an endpoint, providing us with a nice Graphical User Interface (GUI) for writing the request payload and numerous views (including a rendering engine for a graphical view) of the response so that we can see the results of our handiwork in action.

Questions

Familiarize yourself with the Repeater interface.

Answer: No answer needed

Part 3 (Basic Usage of Burp Suite Repeater)

Whilst we can craft requests by hand, it would be much more common to simply capture a request in the Proxy, then send that through to Repeater for editing/resending.

With a request captured in the proxy, we can send to repeater either by right-clicking on the request and choosing “Send to Repeater” or by pressing Ctrl + R. Switching back to Repeater, we can see that our request is now available. The target and Inspector elements are now also showing information; however, we do not yet have a response. When we click the “Send” button, the Response section quickly populates:

If we want to change anything about the request, we can simply type in the Request window and press “Send” again; this will update the Response on the right. For example, changing the “Connection” header to open rather than close results in a response “Connection” header with a value of keep-alive. We could then also use the history buttons to the right of the Send button to go forwards and backwards in our modification history.

Questions

Capture a request to <ip> in the Proxy and send it to Repeater. Practice modifying and re-sending the request numerous times.

Answer: No answer needed

Part 4 (Burp Suite Repeater Views)

Repeater offers us various ways to present the responses to our requests — these range from hex output all the way up to a fully rendered version of the page. We can see the available options by looking above the response box:

1. Pretty: This is the default option. It takes the raw response and attempts to beautify it slightly, making it easier to read.
2. Raw: The pure, un-beautified response from the server.
3. Hex: This view takes the raw response and gives us a byte view of it — especially useful if the response is a binary file.
4. Render: The render view renders the page as it would appear in your browser. Whilst not hugely useful given that we would usually be interested in the source code when using Repeater, this is still a neat trick.

In most instances, the “Pretty” option is perfectly adequate; however, it is still well worth knowing how to use the other three options.

Questions

Experiment with the available view options.

Answer: No answer needed

Which view option displays the response in the same format as your browser would?

Answer: render

Part 5 (Burp Suite Inspector)

In many ways, Inspector is entirely supplementary to the request and response fields of the Repeater window. If you understand how to read and edit HTTP requests, then you may find that you rarely use Inspector at all.

Inspector can be used in the Proxy as well as Repeater. In both cases, it appears over at the very right hand side of the window and gives us a list of the components in the request and response. Of these, the request sections can nearly always be altered, allowing us to add, edit, and delete items.

The other sections available for viewing and/or editing are:

• Query Parameters, which refer to data being sent to the server in the URL. For example, in a GET request to https://admin.tryhackme.com/?redirect=false, there is a query parameter called “redirect” with a value of “false”.
• Body Parameters, which do the same thing as Query Parameters, but for POST requests. Anything that we send as data in a POST request will show up in this section, once again allowing us to modify the parameters before re-sending.
• Request Cookies contain, as you may expect, a modifiable list of the cookies which are being sent with each request.
• Request Headers allow us to view, access, and modify (including outright adding or removing) any of the headers being sent with our requests. Editing these can be very useful when attempting to see how a webserver will respond to unexpected headers.
• Response Headers show us the headers that the server sent back in response to our request. These cannot be edited (as we can’t control what headers the server returns to us!). Note that this section will only show up after we have sent the request and received a response.

Questions

Get comfortable with Inspector and practice adding/removing items from the various request sections.

Answer: No answer needed

Part 6 (Burp Suite Repeater Example)

Repeater is best suited for the kind of task where we need to send the same request numerous times, usually with small changes in between requests. For example, we may wish to manually test for an SQL Injection vulnerability (which we will do in an upcoming task), attempt to bypass a web application firewall filter, or simply add or change parameters in a form submission.

For now, let’s start with an extremely simple example: using Repeater to alter the headers of a request we send to a target.

Questions

Capture a request to http://10.10.8.164/ in the Proxy and send it to Repeater.

Right click on the request and send it to the repeater. Afterwards, click on the repeater tab.

Answer: No answer needed

Send the request once from Repeater — you should see the HTML source code for the page you requested in the response tab. Try viewing this in one of the other view options (e.g. Rendered).

Answer: No answer needed

Using Inspector (or manually, if you prefer), add a header called FlagAuthorised and set it to have a value of True. Send the request. What is the flag you receive?

Add the FlagAuthorised to the request header like so:

Press Send and you will get a flag as response:

Answer: THM{Yzg2MWI2ZDhlYzdlNGFiZTUzZTIzMzVi}

Part 7 (Challenge)

In the previous task, we used Repeater to add a header and send a request; this should serve as an example for using Repeater — now it’s time for a very simple challenge!

With your proxy deactivated, head over to http://10.10.185.96/products/ and try clicking on some of the “See More” links.

Do you notice that it redirects you to a numeric endpoint (e.g. /products/3) when you click for more details?

This endpoint needs to be validated to ensure that the number you try to navigate to exists and is a valid integer; however, what happens if it is not adequately validated?

Questions

Capture a request to one of the numeric products endpoints in the Proxy, then forward it to Repeater.

Visit one of the product endpoints:

Capture a request in the proxy, and forward it to the repeater by right clicking the request in the proxy menu, and selecting “Send to Repeater”:

Answer: No answer needed

See if you can get the server to error out with a “500 Internal Server Error” code by changing the number at the end of the request to extreme inputs. What is the flag you receive when you cause a 500 error in the endpoint?

Answer: THM{N2MzMzFhMTA1MmZiYjA2YWQ4M2ZmMzhl}

Part 8 (SQLi with Burp Suite Repeater)

This task contains an extra-mile challenge, which means that it is a slightly harder, real-world application for Burp Repeater. If you feel comfortable performing a manual SQL Injection by yourself, you may skip to the last question and try this as a blind challenge; otherwise a guide will be given below.

There is a Union SQL Injection vulnerability in the ID parameter of the /about/ID endpoint. Find this vulnerability and execute an attack to retrieve the notes about the CEO stored in the database.

Questions

We know that there is a vulnerability, and we know where it is. Now we just need to exploit it! Let’s start by capturing a request to http://MACHINE_IP/about/2 in the Burp Proxy. Once you have captured the request, send it to Repeater with Ctrl + R or by right-clicking and choosing “Send to Repeater”.

Answer: No answer needed

Now that we have our request primed, let’s confirm that a vulnerability exists. Adding a single apostrophe (') is usually enough to cause the server to error when a simple SQLi is present, so, either using Inspector or by editing the request path manually, add an apostrophe after the “2” at the end of the path and send the request:

You should see that the server responds with a “500 Internal Server Error”, indicating that we successfully broke the query:

Answer: No answer needed

If we look through the body of the server’s response, we see something very interesting at around line 40. The server is telling us the query we tried to execute:

This is an extremely useful error message which the server should absolutely not be sending us, but the fact that we have it makes our job significantly more straightforward.

The message tells us a couple of things that will be invaluable when exploiting this vulnerability:

• The database table we are selecting from is called people.
• The query is selecting five columns from the table: firstName, lastName, pfpLink, role, and bio. We can guess where these fit into the page, which will be helpful for when we choose where to place our responses.

Answer: No answer needed

Although we have managed to cut out a lot of the enumeration required here, we still need to find the name of our target column.

As we know the table name and the number of rows, we can use a union query to select the column names for the people table from the columns table in the information_schema default database.

A simple query for this is as follows:
/about/0 UNION ALL SELECT column_name,null,null,null,null FROM information_schema.columns WHERE table_name="people"

This creates a union query and selects our target then four null columns (to avoid the query erroring out). Notice that we also changed the ID that we are selecting from 2 to 0. By setting the ID to an invalid number, we ensure that we don’t retrieve anything with the original (legitimate) query; this means that the first row returned from the database will be our desired response from the injected query.

Looking through the returned response, we can see that the first column name (id) has been inserted into the page title:

Answer: No answer needed

We have successfully pulled the first column name out of the database, but we now have a problem. The page is only displaying the first matching item — we need to see all of the matching items.

Fortunately, we can use our SQLi to group the results. We can still only retrieve one result at a time, but by using the group_concat() function, we can amalgamate all of the column names into a single output:
/about/0 UNION ALL SELECT group_concat(column_name),null,null,null,null FROM information_schema.columns WHERE table_name="people"

Answer: No answer needed

We have successfully identified eight columns in this table: id, firstName, lastName, pfpLink, role, shortRole, bio, and notes.

Considering our task, it seems a safe bet that our target column is notes.

Finally, we are ready to take the flag from this database — we have all of the information that we need:

• The name of the table: people.
• The name of the target column: notes.
• The ID of the CEO is 1; this can be found simply by clicking on Jameson Wolfe’s profile on the /about/ page and checking the ID in the URL.

Let’s craft a query to extract this flag:
0 UNION ALL SELECT notes,null,null,null,null FROM people WHERE id = 1

Send the request and you wil get the flag!

Answer: No answer needed

Exploit the union SQL injection vulnerability in the site. What is the flag?

Answer: THM{ZGE3OTUyZGMyMzkwNjJmZjg3Mzk1NjJh}

Task 9 (Room Conclusion)

We have now reached the end of the Burp Repeater room. I hope you got comfortable using the program. Remember to keep practicing your newly learnt skills.

Questions

I can use Burp Suite Repeater!

Answer: No answer needed

Like my articles?

You are welcome to give my article a clap or two 🙂
I would be so grateful if you support me by buying me a cup of coffee:

I learned a lot through HackTheBox’s Academy. If you want to sign up, you can get extra cubes, and support me in the process, if you use the following link: