- Joined
- Dec 30, 2024
- Messages
- 381
- Reaction score
- 206
- Points
- 62
- Website
- blackhatpakistan.net
- Points
- 1,033
- USD
- 1,033
A Burp Suite tutorial for beginners covers the proxy-intercept workflow that turns a browser into a testing rig: Burp Suite sits between your browser and the target, records every request, lets you edit and replay them, and builds the site map that drives the rest of a web assessment - proxy, repeater, intruder, and decoder are the four tabs that carry 90% of real work. This tutorial runs the setup end to end: install, browser configuration, first intercepted request, repeater edits, intruder fuzzing, and the session-handling tricks that keep you authenticated while you test.
TL;DR - The loop is: Proxy intercept on -> browse -> edit the live request -> send to Repeater for manual variants -> send to Intruder when the payload position is repeatable -> read findings in Target/site map. Configure the browser proxy to 127.0.0.1:8080, install the CA certificate for HTTPS, and turn Intercept is on off until you actually want to catch a request - beginners lose more traffic to an armed intercept than they gain from it.
INSTALL AND EDITIONS
Community Edition is free and covers everything in this tutorial:
Professional adds intruder at full speed, session handling rules, and the scanner - the workflow below is identical on both.
STEP 1 - WIRE THE BROWSER
Burp listens on 127.0.0.1:8080 by default (Proxy -> Options to change). Point Firefox at it:
- about
references -> Network Settings -> Manual proxy: HTTP 127.0.0.1 port 8080, "also HTTPS"
- Proxy -> CA Certificate -> download, then aboutreferences -> Certificates -> Import -> trust as CA
Better route: use Burp's own browser (Chromium, pre-wired, no cert dance) or FoxyProxy to toggle profiles - a browser you only ever point at Burp keeps personal traffic out of your site map.
STEP 2 - FIRST INTERCEPT
Proxy -> Intercept -> "Intercept is on", browse to the target. The raw request lands editable:
Change id=1 to id=2, Forward it, watch the response pane. The intercepted request is also your site map seed - every link you follow now appears under Target -> Site map with full request/response history.
Workflow rule: leave intercept ON for login and state-changing actions (you want to see the real POST), OFF for crawling (you want to see the pages).
STEP 3 - REPEATER, YOUR MAIN WORKBENCH
Right-click any request -> Send to Repeater (Ctrl+R). Repeater is manual request editing with history:
The length column is the tell: two-digit differences mean boolean blind, changed status codes mean logic, stacked-query responses mean the backend runs multiple statements. Keep a naming habit (repeater tabs labelled by parameter) - a twenty-tab mess at hour three costs more than the testing.
STEP 4 - INTRUER, WHEN IT REPEATS
Send a request to Intruder (Ctrl+I):
1. Positions -> Clear, then highlight exactly the value you fuzz (the id, the search box)
2. Payloads -> Simple list -> add your wordlist (or Pitchfork for two synchronized lists)
3. Resource pool -> set concurrent requests to 4-6 against anything with rate limiting
4. Start -> read the Status/Length columns, sort, look at outliers
Useful payload sets:
The Sniper attack (one payload position) does parameter-by-parameter fuzzing; Battering ram throws the same payload at two positions; Pitchfork pairs two lists (username list against password list); Cluster bomb runs the full cartesian product - that last one is the credit-card-combo generator pattern, and it will wreck your request budget if you point it at rockyou.
STEP 5 - SITE MAP AND SCOPE
Target -> Scope -> add your domain (right-click -> Add to scope) with exclude rules for analytics and CDN noise - otherwise every page load drags third-party domains into the map. The site map view shows unvisited endpoints (grey) your crawl has not touched: those grey links are frequently the forgotten admin panels and debug handlers.
[CRAWL NOTE] Burp's crawl (Dashboard -> New scan, crawl-only) follows links and JS-generated routes. Keep it scoped, keep throughput modest, and review the discovered endpoints list before launching anything with Intruder attached.
STEP 6 - SESSION HANDLING - STAY LOGGED IN
Proxy -> Options -> Session Handling rules. The rule every authenticated test needs:
- Rule: "Fix cookies" - macro runs the login request, applies the fresh session cookie to all requests in scope
- Scope: your target only
Without it, a session timeout mid-Intruder run means 500 requests all bouncing to the login page - the results table fills with identical 302s and the real finding hides behind the wall. Verify with a single Repeater send after two minutes idle: if the response is still 200, the rule works.
DECODER AND EXTENSIONS
Send any selected value -> Decoder: hash it (MD5/SHA), base64, URL, hex, unicode. The tab answers "what is this blob" in one click during token analysis.
Must-install extensions (BApp Store, Extender tab):
REPORTING
Dashboard -> Issues collects findings with evidence requests. Right-click a confirmed issue -> Report -> export the request/response pair for the client report. Community Edition exports manually; keep your own evidence log alongside - screenshot plus raw request is the report standard regardless of edition.
FAQ
Q: Why does my HTTPS browsing break when I enable the proxy?
A: Missing or distrusted CA certificate. Re-import Burp's CA and check the browser trusts it for websites; if the site uses certificate pinning (banking apps, some SPAs), test that endpoint from a normal browser outside Burp.
Q: Repeater or Intruder?
A: Repeater when you are thinking - each request is a hypothesis. Intruder when you know the shape - the position is fixed and only the payload varies. Starting an Intruder run you could answer with three Repeater sends wastes the request budget.
Q: Burp or ZAP?
A: Same workflow vocabulary (proxy, replacer, fuzzer); ZAP is free and scriptable in multiple languages, Burp has the polished session handling and extension ecosystem. The methodology transfers between them completely.
Q: What should a beginner test first through Burp?
A: Walk the authenticated app with intercept off, review the site map for unseen endpoints, then take the three most interesting parameters to Repeater and run the SQL/XSS/traversal probe sets above.
RELATED ON BLACKHAT PAKISTAN
SQLMap Tutorial for Beginners 2026 - take the injectable parameter Burp found and automate the extraction.
Advanced Web Hacking Tools - the rest of the web-tier toolkit Burp plugs into.
Kali Linux Tools List 2026 - Burp in the full attack-phase stack.
Nmap Cheat Sheet 2026 - confirming what is actually serving port 443 before you proxy it.
TL;DR - The loop is: Proxy intercept on -> browse -> edit the live request -> send to Repeater for manual variants -> send to Intruder when the payload position is repeatable -> read findings in Target/site map. Configure the browser proxy to 127.0.0.1:8080, install the CA certificate for HTTPS, and turn Intercept is on off until you actually want to catch a request - beginners lose more traffic to an armed intercept than they gain from it.
INSTALL AND EDITIONS
Community Edition is free and covers everything in this tutorial:
Code:
sudo apt install burpsuite Kali package
# or download the JRE bundle from portswigger.netProfessional adds intruder at full speed, session handling rules, and the scanner - the workflow below is identical on both.
STEP 1 - WIRE THE BROWSER
Burp listens on 127.0.0.1:8080 by default (Proxy -> Options to change). Point Firefox at it:
- about
references -> Network Settings -> Manual proxy: HTTP 127.0.0.1 port 8080, "also HTTPS"- Proxy -> CA Certificate -> download, then about
references -> Certificates -> Import -> trust as CABetter route: use Burp's own browser (Chromium, pre-wired, no cert dance) or FoxyProxy to toggle profiles - a browser you only ever point at Burp keeps personal traffic out of your site map.
STEP 2 - FIRST INTERCEPT
Proxy -> Intercept -> "Intercept is on", browse to the target. The raw request lands editable:
Code:
GET /vulnerable.php?id=1 HTTP/1.1
Host: target.com
Cookie: session=abc123
User-Agent: Mozilla/5.0 ...Change id=1 to id=2, Forward it, watch the response pane. The intercepted request is also your site map seed - every link you follow now appears under Target -> Site map with full request/response history.
Workflow rule: leave intercept ON for login and state-changing actions (you want to see the real POST), OFF for crawling (you want to see the pages).
STEP 3 - REPEATER, YOUR MAIN WORKBENCH
Right-click any request -> Send to Repeater (Ctrl+R). Repeater is manual request editing with history:
Code:
id=1 baseline response - 200, 412 bytes
id=2 same page - compare lengths
id=1' error text appears? note the DB type
id=1 AND 1=1 boolean baseline
id=1 AND 1=2 response changes? boolean blind confirmedThe length column is the tell: two-digit differences mean boolean blind, changed status codes mean logic, stacked-query responses mean the backend runs multiple statements. Keep a naming habit (repeater tabs labelled by parameter) - a twenty-tab mess at hour three costs more than the testing.
STEP 4 - INTRUER, WHEN IT REPEATS
Send a request to Intruder (Ctrl+I):
1. Positions -> Clear, then highlight exactly the value you fuzz (the id, the search box)
2. Payloads -> Simple list -> add your wordlist (or Pitchfork for two synchronized lists)
3. Resource pool -> set concurrent requests to 4-6 against anything with rate limiting
4. Start -> read the Status/Length columns, sort, look at outliers
Useful payload sets:
Code:
SQL chars ' " 1' ' OR '1'='1 --
XSS probe javascript-uri probes, tag-break payloads, event-handler variants
Path traversal dot-dot slash chains toward system files (URL-encoded variants)
Auth bypass admin, administrator, root, backup
API fuzzing ../, %00, unicode normalization pairsThe Sniper attack (one payload position) does parameter-by-parameter fuzzing; Battering ram throws the same payload at two positions; Pitchfork pairs two lists (username list against password list); Cluster bomb runs the full cartesian product - that last one is the credit-card-combo generator pattern, and it will wreck your request budget if you point it at rockyou.
STEP 5 - SITE MAP AND SCOPE
Target -> Scope -> add your domain (right-click -> Add to scope) with exclude rules for analytics and CDN noise - otherwise every page load drags third-party domains into the map. The site map view shows unvisited endpoints (grey) your crawl has not touched: those grey links are frequently the forgotten admin panels and debug handlers.
[CRAWL NOTE] Burp's crawl (Dashboard -> New scan, crawl-only) follows links and JS-generated routes. Keep it scoped, keep throughput modest, and review the discovered endpoints list before launching anything with Intruder attached.
STEP 6 - SESSION HANDLING - STAY LOGGED IN
Proxy -> Options -> Session Handling rules. The rule every authenticated test needs:
- Rule: "Fix cookies" - macro runs the login request, applies the fresh session cookie to all requests in scope
- Scope: your target only
Without it, a session timeout mid-Intruder run means 500 requests all bouncing to the login page - the results table fills with identical 302s and the real finding hides behind the wall. Verify with a single Repeater send after two minutes idle: if the response is still 200, the rule works.
DECODER AND EXTENSIONS
Send any selected value -> Decoder: hash it (MD5/SHA), base64, URL, hex, unicode. The tab answers "what is this blob" in one click during token analysis.
Must-install extensions (BApp Store, Extender tab):
Code:
Turbo Intruder high-speed custom-payload attacks (HTTP/2 too)
Autorize authorization testing - compares roles on every request
J2TCP / Logger++ request logging with export
Param Miner hidden parameter discovery (backend, cache, cookies)
Match and Extract custom highlight rules across trafficREPORTING
Dashboard -> Issues collects findings with evidence requests. Right-click a confirmed issue -> Report -> export the request/response pair for the client report. Community Edition exports manually; keep your own evidence log alongside - screenshot plus raw request is the report standard regardless of edition.
FAQ
Q: Why does my HTTPS browsing break when I enable the proxy?
A: Missing or distrusted CA certificate. Re-import Burp's CA and check the browser trusts it for websites; if the site uses certificate pinning (banking apps, some SPAs), test that endpoint from a normal browser outside Burp.
Q: Repeater or Intruder?
A: Repeater when you are thinking - each request is a hypothesis. Intruder when you know the shape - the position is fixed and only the payload varies. Starting an Intruder run you could answer with three Repeater sends wastes the request budget.
Q: Burp or ZAP?
A: Same workflow vocabulary (proxy, replacer, fuzzer); ZAP is free and scriptable in multiple languages, Burp has the polished session handling and extension ecosystem. The methodology transfers between them completely.
Q: What should a beginner test first through Burp?
A: Walk the authenticated app with intercept off, review the site map for unseen endpoints, then take the three most interesting parameters to Repeater and run the SQL/XSS/traversal probe sets above.
RELATED ON BLACKHAT PAKISTAN
SQLMap Tutorial for Beginners 2026 - take the injectable parameter Burp found and automate the extraction.
Advanced Web Hacking Tools - the rest of the web-tier toolkit Burp plugs into.
Kali Linux Tools List 2026 - Burp in the full attack-phase stack.
Nmap Cheat Sheet 2026 - confirming what is actually serving port 443 before you proxy it.
Code:
1. Proxy 127.0.0.1:8080 + CA cert imported
2. Scope set, analytics excluded
3. Intercept on for login POST, off for crawl
4. Site map -> review grey (unvisited) endpoints
5. Repeater baseline response saved (length noted)
6. Session handling rule: macro login + fix cookies
7. Intruder positions cleared, ONE position highlighted
8. Resource pool throttled to 4-6
