Burp Suite for picoCTF: From Proxy Setup to Repeater Tricks

The four panels that matter

You can solve almost every picoCTF web challenge with four panels in Burp Suite Community Edition: Proxy, HTTP history, Repeater, and Decoder. The rest of the UI is a feature tour you can learn on demand. People give up on Burp because they sit down expecting a curve and run into a setup wall, or they install the free edition, hit the rate-limited Intruder, and assume they need the $499/year Professional license. Both problems have a fix that takes less time to read than this paragraph.

If you just want the keystrokes, jump to the quick reference. If you have never set Burp up before, start at setup. If you have it open but feel slow, jump to Repeater.

Why Burp at all, when curl exists

The first time I solved a picoCTF web challenge I did it with curl and a notebook full of half-remembered headers. It worked. It also took an hour, and most of that hour was me retyping the same request with one byte different. The pitch for Burp is not that it does anything curl cannot do. The pitch is that it remembers every request you have ever sent, and lets you fork any of them into an editor with one keystroke.

Burp Suite is a local HTTP proxy from PortSwigger with a graphical interface for replay, inspection, and tampering. You point your browser at it, it logs every request and response, and you send anything interesting to a panel called Repeater where you edit and resend it without touching the browser. That is the entire core workflow. Every fancy feature, including the scanner, the collaborator, the BApp store, the macros, sits on top of that one loop.

Burp is not faster than curl. It is faster than curl plus the notebook, plus the up-arrow, plus the "wait what cookie was I using."

The closest comparable tool is your browser's DevTools Network tab. DevTools is fine for reading requests. It is hostile for editing and resending them. By the time you have copied a request as fetch, pasted it into the console, edited a parameter, and run it, Burp would be on its third iteration. For a 30-second one-off, DevTools wins. For everything else, the proxy wins.

Setup that doesn't fight you for 30 minutes

The single biggest reason beginners bounce off Burp is the certificate dance. Here is the path that has the fewest steps and the fewest things that can go wrong.

1. Download Burp Suite Community Edition from portswigger.net/burp/communitydownload. The installer bundles its own Java runtime, so you do not need to install Java separately.
2. Launch Burp. Accept the defaults on every prompt. You want a temporary project with Burp defaults. Save-project is a Pro feature; do not chase it.
3. On the Dashboard, click Open browser. This is Burp's embedded Chromium and it is already trusted by the proxy. This is the move ninety percent of tutorials skip. Use it for the first month. You can configure Firefox later when you actually want side-by-side tabs.

Two settings to change before you do anything else. First, in Proxy → Proxy settings → Response interception, make sure response interception is off. You do not want Burp pausing every response while you read the page. Second, in User options → Display → HTTP message display, bump the font size. The default is small enough to give you a headache by hour two.

That is the entire setup. If it took you longer than ten minutes, the issue was not Burp. It was a browser or a Java install fighting you. Start over with the embedded browser.

Intercept is a trap (use HTTP history instead)

Every Burp tutorial teaches you to click Intercept on, browse to the target, and step through requests one at a time. That works exactly once, on a static site with three requests. The moment the page loads thirty assets, autocomplete fires off five XHRs, and a Google Tag Manager script wakes up, you are clicking Forward for two minutes trying to find the one request you wanted.

The real workflow is the opposite. Leave intercept off. Browse the site normally. Then open Proxy → HTTP history and find the request you care about in the log. Right-click, Send to Repeater, done.

The filter bar at the top of HTTP history is the second-best feature of Burp. Filter by extension to hide images and CSS. Filter by host to drop third-party noise. Filter by status to find only the 200s, or only the 302s. By the time you reach Repeater, you have the exact request you wanted, not the seventeenth one in a queue.

The opinion: nobody who solves web challenges quickly uses intercept as their primary workflow. They use it to tamper a specific request on the way out, two or three times per session. The rest of the time it is off.

Repeater is the whole game

If you spend the next month using only one panel, make it Repeater. The loop is:

1. Right-click a request in HTTP history, Send to Repeater (shortcut: Ctrl+R).
2. Edit any byte: a header, a cookie, a URL parameter, a JSON body, the HTTP verb.
3. Click Send (shortcut: Ctrl+Space). Read the response on the right.
4. Repeat. Each send is a tab in the response history, so you can compare iterations.

That is it. Every cookie-tampering challenge, every parameter-tampering challenge, every "is this filter server-side or just JavaScript" question, every blind SQL injection where you flip one byte and wait for the response time to change, runs through this loop. The SQL injection guide describes the payload theory; Repeater is where you actually try them.

A real example. The challenge gives you a login form. You submit, see a cookie like admin=false, and get a generic page. In Repeater:

GET /dashboard HTTP/1.1
Host: challenge.example
Cookie: admin=false
 
# Send. Response is the boring page.
# Edit the Cookie line:
Cookie: admin=true
# Ctrl+Space. Response is now the admin panel with the flag.

That is the most embarrassing version of the challenge. Most are subtler: JWT tokens, base64-wrapped session blobs, signed cookies that you have to crack first. The Cookie and JWT Attacks post walks the cracking side. The point here is that no matter how complex the payload, the iteration loop is the same three keystrokes.

A small thing that took me an embarrassing amount of time to discover: you can rename Repeater tabs. Double-click the tab name. Suddenly "Repeater 1, Repeater 2, Repeater 3" becomes "baseline, sqli probe, working payload." If you spend more than ten minutes in Repeater, you will be glad you did this.

The other three you actually use

Past Repeater, three panels earn their place. Everything else is on demand.

That is the working set: Proxy, HTTP history, Repeater, Decoder, with Inspector and Comparer as backup. I have solved hundreds of web challenges and I still touch the Scanner, Sequencer, and Macros tabs roughly once a year.

Intruder Community, and the Python escape hatch

The thing everyone tells you is that you need Burp Professional for Intruder. The PortSwigger marketing page agrees. It is technically true and practically wrong for the picoCTF tier.

Intruder is Burp's automated request fuzzer: take a request, mark positions with §, give it a wordlist, send N permutations, see which one returned a different status or length. In Community Edition, Intruder is rate-limited. The exact throughput PortSwigger does not publish, but in practice it is around one request per second after the first burst. For a 5,000-word wordlist that is more than an hour.

Here is the trick: most CTF brute-force does not need 5,000 words. A login bypass against a four-digit PIN is 10,000 requests; you would not do that one in Burp Community even with Pro. But an enumeration of 20 user IDs, or a fuzz across 50 candidate paths, or a 100-payload test of an injection point, runs in a minute or two of Community Intruder. That is most picoCTF cases.

When the case is genuinely too big, you do not buy Pro. You drop into Python with the cookies Burp already has. Right-click any request in Burp and choose Copy as curl command. Open a terminal:

# 1. Copy request as curl from Burp, paste here once to confirm it works:
curl 'http://challenge.example/api' \
  -H 'Cookie: session=abc123...' \
  --data-raw 'id=1'
 
# 2. Convert to Python with curlconverter.com, or write it yourself:

import requests
 
url = 'http://challenge.example/api'
cookies = {'session': 'abc123...'}
 
for i in range(1, 1001):
    r = requests.post(url, cookies=cookies, data={'id': i})
    if 'picoCTF' in r.text or len(r.text) > 200:
        print(i, r.status_code, len(r.text))
        print(r.text[:500])
        break

That is the full "replace Pro Intruder for free" trick. The Python script runs at the actual server speed, not Burp's throttle, and you have all of requests and threading available for the few cases that need real concurrency. The Python for CTF guide covers the patterns. The netcat post covers when to skip HTTP entirely.

picoCTF walkthroughs: where Burp wins

Concrete examples. Each of these is solvable with the four-panel workflow above. The point is not the writeup; the point is which panel does the work.

• IntroToBurp (2024) is the on-ramp. The challenge intentionally has client-side validation that is not enforced on the server. Browse with proxy on, find the validation request in HTTP history, send to Repeater, change the validation value, send. Flag.
• Cookie Monster (2025) is a cookie tampering exercise. The session cookie is base64-encoded JSON. Decoder → edit → Decoder (re-encode) → Repeater with the new cookie. The four panels all show up.
• head-dump (2025) is a header-driven leak. HTTP history filter on the right host, find the response with the suspicious header, follow it to the dump endpoint, send to Repeater to confirm. Inspector makes the header reading bearable.
• n0s4n1ty 1 (2025) is upload-then-execute. Burp's job is intercepting the upload and changing the filename or Content-Type to bypass the filter, then triggering the uploaded file. The File Upload Exploitation post covers the bypass theory; Burp is where you actually flip the bytes.
• Bookmarklet (2024) looks like a JavaScript-only puzzle. Burp's value is proving that the "encryption" happens entirely in the browser, by watching the network and seeing zero outbound requests for the decrypted flag.
• 3v@l (2025) is a server-side eval challenge. Repeater is the only sensible way to iterate through payloads against the input filter. The Command Injection guide has the theory; Repeater is the runway.
• No Sql Injection (2024) and More SQLi (2023) are SQLi sandboxes. Repeater for payload testing. Comparer when the response is "invalid query" vs "invalid login" and you need to spot the difference. See the SQL Injection guide.
• WebDecode (2024) is Decoder bait. The flag is wrapped in three layers of encoding and the answer is "paste, decode, paste, decode, paste, decode." The keyboard shortcut Ctrl+Shift+D earns its keep.

The pattern across all of these: view through Burp, send the interesting request to Repeater, modify, resend, read the response. If you can do those four things without looking up shortcuts, you are operational.

When Burp is the wrong tool

I do not want to oversell this. Burp is the right answer for most web CTFs, not all of them. Three cases where I close the proxy and reach for something else.

• Pure client-side JavaScript challenges. When the puzzle lives entirely in the browser (obfuscated JS, a bookmarklet that runs locally, a service worker that intercepts requests before they ever leave), DevTools is faster. Burp will show you what is on the wire, which by definition is nothing.
• Heavy WebSocket challenges. Burp has a WebSocket tab and Repeater can replay frames, but the workflow is rough enough that I usually drop to a Python websocket-client script for anything more than reading frames. The challenge websockfish (2025) is the case that taught me this.
• Brute force past a few thousand requests. Already covered above. Drop to Python or Turbo Intruder. Do not fight the Community rate limit at scale.

And one anti-pattern. Do not use Burp's Scanner on a CTF, ever. The Scanner is a Pro feature, it is slow, it generates noise, and any hint of automated scanning against the target's server can rate-limit your IP for the rest of the competition. Web challenges are designed to reward the one specific bug, not surface every theoretical issue.

Quick reference

The keystrokes worth memorizing in order of how often you will use them.

For deeper dives on the bug classes you will be testing through this proxy, the related posts: SQL Injection, Command Injection, XSS, Cookie and JWT Attacks, File Upload Exploitation, and the broader Web Challenges and Real-World Bug Patterns survey.

Once Burp is three keystrokes (Ctrl+R to send to Repeater, Ctrl+Space to send, Ctrl+Shift+I for Inspector), you stop thinking about the tool and start thinking about the challenge. That is when web starts being fun.