Burp Suite for HTB & CTF Players: Complete Guide (2026)

TL;DR

Burp Suite is the industry-standard web proxy for manually testing web applications. Mastering it separates players who guess their way through HTB web challenges from those who dismantle them methodically. This guide covers every feature you'll actually use in CTF contexts — Proxy, Repeater, Intruder, Decoder, Comparer, and the BApp extensions that matter — with no enterprise fluff.

Introduction

If you've spent any time on HackTheBox or playing CTFs, you've seen Burp Suite mentioned in every web challenge writeup. It's not hype — Burp Suite is the single most powerful tool for manually testing web applications, and mastering it separates players who guess their way through challenges from those who methodically dismantle them.

This guide is written specifically for HTB and CTF players. No fluff, no enterprise sales pitch — just the features you'll actually use, explained in the context of real challenge scenarios. We'll cover the Proxy & Intercept, Repeater, Intruder, Decoder & Comparer, and the BApp Store extensions that make your workflow faster.

Installation & Initial Setup

Burp Suite Community Edition is free and covers everything in this guide except the active Scanner. Download it from portswigger.net.

Open terminal, navigate to the download folder, and make the installer executable:

chmod +x burpsuite_community_linux_v*.sh

Run the installer:

./burpsuite_community_linux_v*.sh

Once installed, open Burp Suite. A popup will ask you to select a project type — choose Temporary project and click Next.

Configuring Your Browser

Burp listens on 127.0.0.1:8080 by default. Route your browser traffic through it before doing anything else.

This is a manual process and can be tedious when you have to switch between the challenge target and normal browsing.

Firefox (recommended): Go to Settings → Network Settings → Manual Proxy Configuration. Set HTTP Proxy to 127.0.0.1, port 8080, and check "Also use this proxy for HTTPS."

Screenshot context: The Firefox manual proxy configuration dialog should show HTTP Proxy set to 127.0.0.1, port 8080, and "Also use this proxy for HTTPS" checked.

To overcome the manual process of switching between the challenge target and normal browsing, you can use FoxyProxy.

FoxyProxy (better for CTFs): Install the FoxyProxy browser extension. Create a Burp profile pointing to 127.0.0.1:8080 and toggle it on/off with one click — essential when switching between the challenge target and normal browsing.

You can also use Chrome, Brave, or any browser of your choice, but you will need to install the CA certificate in that browser as well.

Screenshot context: The FoxyProxy popup should show a saved Burp Suite profile pointing to 127.0.0.1:8080 with the toggle set to active. The proxy icon in the browser toolbar changes color to confirm traffic is routing through Burp.

Installing the CA Certificate

Without this step, Burp cannot intercept HTTPS and every site throws SSL errors.

1. With Burp running and your proxy active, navigate to http://burp/ in your browser.
2. Click "CA Certificate" to download cacert.der.
3. In Firefox: Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import. Select cacert.der and check "Trust this CA to identify websites."

Screenshot context: The Firefox certificate import dialog should show cacert.der selected in the file picker and the "Trust this CA to identify websites" checkbox checked before clicking OK.

Screenshot context: Burp's Proxy → HTTP History tab should show at least one request logged after browsing any HTTPS site — confirming the CA cert is trusted and traffic is flowing through the proxy with no SSL errors in the browser.

Shortcut: Burp Suite includes a built-in Chromium browser accessible from the top-right corner of the interface. It has the CA certificate pre-installed, so you can start intercepting HTTPS immediately without any certificate setup.

Proxy & Intercept — Seeing Everything

The Proxy is the foundation of Burp. Every HTTP/S request your browser makes flows through it.

HTTP History — Your Passive Recon Tab

Browse the target application normally before touching anything. Watch Proxy → HTTP History fill up. This passive phase surfaces:

• All endpoints the app touches, including silent background API calls
• Parameters in query strings, POST bodies, JSON payloads, and cookies
• Custom headers like X-Role, X-Admin, or Authorization that hint at access control logic
• Session token formats — opaque strings, Base64 blobs, or JWTs

Sort by URL to group endpoints, or by Status Code to immediately surface 403s and 302 redirects worth investigating.

Screenshot context: The HTTP History tab should show a populated list of requests with the Method, URL, Status, and Length columns visible. A mix of status codes — at least one 302 and one 200 — demonstrates how sorting by Status Code immediately surfaces redirect chains worth investigating.

Intercept Mode — Stopping Requests Mid-Flight

Click "Intercept is on" and Burp freezes every outgoing request before it reaches the server. Edit anything in the raw HTTP, then click "Forward" to send or "Drop" to discard.

Use Intercept for:

• Modifying a form submission before it leaves your browser
• Changing a file upload's Content-Type or filename on the fly
• Injecting a parameter or header into a one-time request

Turn Intercept OFF for:

• General browsing while mapping the app — you'll be clicking Forward constantly and missing the bigger picture

For better testing, enable Response interception to capture and analyze server responses before they reach the browser. Go to Proxy → Options and check "Intercept responses".

Screenshot context: The Proxy settings page showing the intercept rules and options available for controlling what Burp captures.

Bypassing Client-Side Validation

This pattern appears in nearly every HTB web challenge. A form enforces restrictions via JavaScript — only certain file types, readonly fields, numeric-only inputs. None of it applies once you intercept the raw request.

1. Fill the form with values that satisfy the JavaScript validation.
2. Enable Intercept just before clicking Submit.
3. When the request appears in Burp, change what you actually want: role=admin, filename="shell.php", price=0.
4. Forward. The server receives your version. The JavaScript never ran on the server.

Using demo.testfire.net for practice — it is intentionally vulnerable and designed for testing purposes.

Screenshot context: The Intercept tab should show a paused POST request with the raw body visible in the lower panel. A field like price=100 clearly readable as plain editable text — showing that the value can be changed before clicking Forward.

Scope — Filtering Noise

Target apps make dozens of requests to CDNs and analytics. Go to Target → Scope → Add, enter your target host (10.129.x.x or target.htb), then click Yes for Proxy history logging. To filter during intercept mode so only in-scope requests are shown, enable "And URL is in target scope" in Proxy → Options.

Screenshot context: The Target → Scope tab should show a host entry added — for example 10.129.x.x or target.htb — in the Include in Scope table. This confirms HTTP History will only log requests to in-scope targets going forward.

For a quicker method, go to the HTTP History tab, right-click any request from the target, and select Add to Scope.

Screenshot context: The right-click context menu on a request in HTTP History should show the "Add to Scope" option. After adding, go to the History filter and enable Show only in-scope items to keep the view clean.

If adding scope this way, also enable "And URL is in target scope" in Proxy → Options, and in the History tab go to Filter and enable Show only in-scope items.

Repeater — Your Manual Testing Workspace

Repeater is where you'll spend most of your active testing time. It replays and modifies any request without returning to the browser.

Sending to Repeater

Right-click any request in HTTP History → "Send to Repeater" or press Ctrl+R. A new numbered tab appears in Repeater.

Screenshot context: The Repeater tab should show the split-panel layout — raw HTTP request on the left, server response on the right after clicking Send. The tab label at the top shows the request number, and the Send button is visible above the left panel.

Common CTF Workflows in Repeater

IDOR enumeration: Find GET /api/user?id=14. Send to Repeater. Change id=14 to id=1, id=2, id=13. Watch response length for anomalies — a longer response on one ID means different data returned.

Bypassing redirects: A 302 Found response with Location: /login gets followed automatically by the browser. In Repeater, you see the full 302 response body — which often contains the admin panel content or flag the redirect was hiding.

Screenshot context: The Repeater response panel should show a 302 Found status with a Location header pointing to /bank/main.jsp, a successful login redirecting to the main page.

Header injection: Add these to any request in Repeater to test IP and role-based access controls:

X-Forwarded-For: 127.0.0.1
X-Real-IP: 127.0.0.1
X-Role: admin
X-Admin: true

Changing request methods: Right-click in the request panel → "Change request method". Burp converts between GET and POST automatically. Some endpoints behave differently by method — test GET, POST, PUT, PATCH, DELETE on the same URL.

Screenshot context: Right-clicking anywhere inside the Repeater request panel should show a context menu with "Change request method" as one of the options. This converts the request between GET and POST automatically, adjusting the Content-Type and parameter placement.

What to Check in Every Response

• Status code — 200 vs 403 vs 500 each tell a different story
• Content-Length — a 0-byte vs 1,200-byte response is meaningful even without visible body differences
• Response headers — Set-Cookie, Location, any custom headers
• Render tab — HTML rendered visually, useful for flags embedded in page content

Intruder — Automated Parameter Fuzzing

Intruder iterates a payload list through a marked position in your request automatically. Instead of changing a value 500 times in Repeater, you define the position and let Intruder run.

Note: Burp Community throttles Intruder. For high-volume fuzzing, use ffuf or wfuzz externally. Intruder remains valuable for targeted, lower-volume attacks.

Setting Up an Attack

1. Right-click a request → "Send to Intruder" (Ctrl+I).
2. Positions tab: Clear all auto-marked positions with "Clear §". Highlight your target value manually, click "Add §".
3. Payloads tab: Configure your payload type and list.

Screenshot context: The Intruder → Positions tab should show the raw request with one payload marker highlighted in orange — for example §14§ around a numeric ID parameter like id=§14§. The "Add §", "Clear §", and "Auto §" buttons should be visible on the right side of the panel.

Screenshot context: The Payloads tab should show "Numbers" selected as the payload type with the range configured from 1 to 500 and a step of 1. This is the standard setup for sequential ID enumeration against endpoints like /api/user?id=§1§.

Attack Types

Sniper — One position, one list. Each payload substitutes into the position one at a time. Use for IDOR enumeration, parameter fuzzing, username enumeration.

Battering Ram — One list, multiple positions. The same payload is inserted into all marked positions simultaneously. Use when the same value needs to appear in multiple places at once — for example when a username appears in both a cookie and a POST body parameter and both must match for the request to be valid.

Cluster Bomb — Multiple positions, multiple payload lists. Tests every combination of all lists. Use for credential stuffing: username list × password list.

Pitchfork — Multiple positions, multiple lists iterated in parallel. Position 1 gets list 1 item 1 while position 2 gets list 2 item 1 simultaneously. Use when a username and its corresponding token must be tested together.

All four attack types compared by positions, lists, and primary use case:

Analyzing Results

Sort the attack results window by Length. Responses that deviate from the baseline length are your targets — a 403 that becomes 200, or a response 500 bytes longer than the rest.

Screenshot context: The Intruder attack results window should show all completed requests with the Length column sorted. One row should have a noticeably different length from the rest — this is the anomaly. Right-clicking that row shows the "Show response" option to inspect what the server returned for that specific payload.

Decoder & Comparer — Making Sense of Encoded Data

Decoder

Decoder handles encoding, decoding, and hashing for any value you paste into it. In HTB challenges, encoded data appears constantly in cookies, tokens, and response bodies.

1. Navigate to the Decoder tab.
2. Paste the encoded string.
3. Click "Decode as" and select the encoding type.
4. Chain operations — decode Base64, then URL-decode the result in the same view.

Screenshot context: The Decoder tab should show a Base64 string like dXNlcjphZG1pbg== pasted in the top input box, with "Decode as Base64" selected, and the decoded output user:admin displayed in the panel below — confirming the value contains structured credential data hidden behind encoding.

Common encodings in CTF and HTB challenges:

JWT tokens appear as three Base64-encoded segments separated by dots: header.payload.signature. Paste the middle segment into Decoder, decode as Base64, and read the JSON claims — {"role":"user","admin":false} — which may be tamperable.

Screenshot context: The Decoder tab should show the middle segment of a JWT token pasted in the input — the payload section between the two dots. Decoded as Base64, the output panel should display a readable JSON object containing claims like "role": "user" or "admin": false, showing the data that can be tampered with before re-encoding.

Comparer

Comparer runs a byte-level or word-level diff between two items. Use it when:

• Testing authentication to find the exact difference between a valid and invalid login response
• Comparing before/after responses after a parameter change
• Intruder returned two similar-length responses you suspect differ in small ways

Right-click any request or response in History, Repeater, or Intruder → "Send to Comparer". Send a second item. Open Comparer, select both, click "Words" or "Bytes".

Screenshot context: The Comparer tab should show two responses loaded side by side with a word-level diff active. Green highlights mark content present in one response but not the other — for example "role": "admin" appearing in the modified response where the original had "role": "user". This visual diff pinpoints the exact access control difference between the two responses.

Extensions & BApp Store — Supercharging Burp for CTFs

Install extensions via Extender → BApp Store. Community-compatible extensions are marked in the store.

Essential Extensions for CTF Work

JWT Editor is the most important extension for modern web CTFs. It automatically detects JWTs in requests and adds a dedicated tab to decode, modify, and re-sign them. Supports the alg: none attack, custom key signing, and embedded JWK injection. Available free in Community.

Screenshot context: A Repeater tab containing a request with a JWT in the Authorization or Cookie header should show a "JSON Web Token" sub-tab at the bottom of the request panel. Clicking it reveals the decoded header and payload as editable JSON fields, with an "Attack" dropdown button that exposes options including the alg: none bypass.

Param Miner discovers hidden parameters the application accepts but never advertises. It fuzzes headers and body parameters in the background using a built-in wordlist, often surfacing debug=true, admin=1, or undocumented API parameters.

Turbo Intruder is a Python-scriptable, high-speed replacement for throttled Community Intruder. It sends thousands of requests per second using HTTP pipelining. Essential for race condition attacks and any fuzzing scenario where Intruder's Community throttle is the bottleneck.

Screenshot context: The Turbo Intruder window should show a Python script editor with the default template loaded — the def queueRequests(target, wordlists) function visible with a queue() call inside it. This is the entry point where payload logic is defined before clicking "Attack" to start the high-speed run.

Logger++ adds regex filtering, column customization, and log export to HTTP History. Write filters like Response.Body CONTAINS "flag" to auto-highlight matching responses across hundreds of requests.

Retire.js passively detects outdated JavaScript libraries with known CVEs in target responses. Runs silently in the background and flags vulnerable library versions in the HTTP History annotations.

Hackvertor applies encoding transformations inline inside Repeater requests using tag syntax. Wrap a payload in <@base64>payload<@/base64> and it encodes on the fly before sending — useful for multi-encoded payloads.

Installing Extensions

To browse and download extensions directly: BApp Store

After downloading, go to Extensions → Add → Extension type: [Extension Type] and select the downloaded file.

For extensions written in Python or Ruby, Burp Suite runs on Java and requires Jython or JRuby to execute them. Configure this before installing:

1. Download the Jython standalone JAR or the JRuby JAR.
2. In Burp Suite, open Settings → Extensions.
3. Under Python Environment or Ruby Environment, click Select file and choose the downloaded JAR.
4. Go to Extensions → BApp Store, refresh the list, and install your desired extension.

To install a custom extension file manually:

1. Go to Extensions → Installed and click Add.
2. In Extension Details, select the extension type (Java, Python, or Ruby).
3. Click Select file and choose the extension file.
4. (Optional) Configure Standard output and Standard error to log messages.
5. Click Next to load the extension.
6. Review messages in the Output and Errors tabs, then click Close.

Workflow Cheat Sheet for HTB Web Challenges

1. Configure proxy + CA cert

• FoxyProxy profile pointing to 127.0.0.1:8080
• CA cert imported into Firefox trust store

2. Passive recon

• Browse normally, watch HTTP History fill
• Set scope to filter CDN and analytics noise
• Identify: endpoints, parameters, headers, cookies, token formats

3. Map the app

• Spider via Target → Site Map
• Look for /admin, /api/*, /debug, hidden paths

4. Identify attack surface

• Numeric parameters → IDOR candidate
• 302 redirect chains → check response bodies in Repeater
• File uploads → intercept and change Content-Type / filename
• Encoded cookies or tokens → Decoder

5. Manual testing in Repeater

• Change methods, parameters, header values
• Add X-Forwarded-For, X-Role, X-Admin headers
• Modify JWT claims, re-sign with JWT Editor

6. Automate with Intruder / Turbo Intruder

• Enumerate numeric IDs
• Fuzz parameters with wordlists
• Sort results by Length to find anomalies

7. Decode in Decoder

• Base64, URL encoding, HTML entities, JWT payload segment
• Re-encode modified values before injecting in Repeater

8. Diff in Comparer

• Compare valid vs invalid responses
• Isolate the exact bytes that change between access levels

Key Mindset for CTF Web Challenges

The server is the authority, not the browser. JavaScript, HTML attributes, and CSS are suggestions your browser follows. Burp ignores them and communicates with the server directly. Every client-side restriction is a bypass waiting to happen.

Read full responses. The flag or the clue is often in a response header, an HTML comment, or the body of a redirect your browser never rendered. Burp shows you everything — use the Render tab, check headers, read the raw body.

Encoding is not encryption. A cookie that looks like dXNlcjoxMjM= decodes to user:123. A JWT payload decodes to readable JSON. Challenge authors hide data in encoded formats expecting players to skip them. Don't.

Anomalies are leads. A response 200 bytes longer than the rest. A 200 OK in a sea of 403s. A Set-Cookie that appears only on one specific path. These are intentional signals from the challenge designer — not noise.

Frequently Asked Questions

Conclusion

Burp Suite is not a tool you learn once — it's a workflow you build over dozens of challenges. The proxy intercepts everything; Repeater lets you pull anything apart manually; Intruder automates the tedious parts; Decoder strips away obfuscation; Comparer shows you exactly what changed. Stack JWT Editor and Turbo Intruder on top and the Community Edition covers every web challenge HTB puts in front of you.

All techniques described are for use in authorized environments — HTB machines, CTF challenges, and your own test labs. Never proxy traffic you do not have permission to intercept.

Sources

• Burp Suite Official Documentation — PortSwigger's complete reference for all Burp Suite features and configuration
• PortSwigger Web Security Academy — Free labs covering every vulnerability class testable with Burp Suite
• OWASP Web Security Testing Guide — Industry standard methodology that maps directly to Burp Suite's toolset
• JWT Editor BApp — Official BApp Store listing with installation and usage notes
• Turbo Intruder GitHub — Source and documentation for the high-speed Intruder replacement