In 2023, attackers exploited a blind SQL injection flaw in MOVEit Transfer (CVE-2023-34362) that a proper authenticated scan would have caught before deployment. Burp Suite Pro is the tool most professionals reach for in exactly that scenario — but most teams only scratch the surface of what it can do. This post shows you three techniques that separate a real assessment from a checkbox scan.
\n\n
Turbocharge Active Scanning With Audit Configurations
\n\n
Out-of-the-box active scanning is noisy and slow. Before you point Burp at https://app.corp-internal.com, build a custom audit configuration that targets the vulnerability classes that actually matter for your target.
\n\n
Go to Settings → Scan → Audit Optimization. Set Audit speed to Thorough, enable Follow redirections, and under Issues Reported deselect low-signal noise like “Password submitted over HTTP” if your scope is already HTTPS-only. Save the config as corp-thorough.json.
\n\n
Then launch a scan against a single authenticated endpoint first — the login-protected dashboard at https://app.corp-internal.com/api/v2/users/192. Burp will return output in the Issue Activity panel. Here is a trimmed real-world-style result:
\n\n
Issue: SQL injection\nSeverity: High\nConfidence: Certain\nEndpoint: GET /api/v2/users/192?filter=active\nParameter: filter\nEvidence:\n Original request: filter=active\n Injected payload: filter=active' AND 1=1--\n Response diff: 200 OK — full user list returned\n Injected payload: filter=active' AND 1=2--\n Response diff: 200 OK — empty result set\nRemediation: Use parameterized queries.\n\n
The boolean-based response difference is the tell. Burp confirmed the injection is certain — not just suspected — because two logical opposites produced two distinct responses. From here, export the request to sqlmap via right-click → Copy as curl command, then run:
\n\n
sqlmap -u \"https://app.corp-internal.com/api/v2/users/192?filter=active\" \\\n --cookie=\"session=eyJhbGciOiJIUzI1NiJ9...\" \\\n --level=3 --risk=2 --batch --dbs\n\n
That hands the confirmed injectable parameter directly to sqlmap for deeper enumeration — no guessing, no wasted time.
\n\n
Credential Stuffing Simulation With Intruder (Cluster Bomb)
\n\n
Burp Intruder is often used only for simple fuzzing. The Cluster Bomb attack type is far more powerful — it lets you test all combinations of two payload lists simultaneously. This mirrors exactly how credential stuffing works in the wild.
\n\n
Capture the login POST to https://app.corp-internal.com/auth/login and send it to Intruder. Mark your positions like this:
\n\n
POST /auth/login HTTP/2\nHost: app.corp-internal.com\nContent-Type: application/json\n\n{\"username\":\"§user§\",\"password\":\"§pass§\"}\n\n
Set attack type to Cluster Bomb. Load usernames.txt into payload set 1 and a password list (top-100 leaked passwords) into payload set 2. Add a Grep → Match rule on the string \"token\" — that string only appears in a successful login response.
\n\n
After the attack runs, sort by the token grep column. Any row with a tick found a valid credential pair. Example output:
\n\n
Request Username Password Status Length token
-------- --------------- ------------ ------- ------- -----
47 j.morrison Summer2024! 200 843 ✓
112 admin admin123 401 210
198 r.patel Summer2024! 401 210\n\n
Request 47 is the hit. j.morrison / Summer2024! authenticated successfully. The 200 status combined with the longer response body and the token match makes it unambiguous. Next step: replay that session in Burp Repeater and map what j.morrison can access — roles, admin panels, other users’ data.
\n\n
Intercepting and Tampering JWTs in Proxy
\n\n
JWTs are everywhere, and weak implementations — none-algorithm attacks, missing signature validation — are still common in 2026. Burp Pro’s JSON Web Tokens tab (built into the message editor) makes this trivial to test.
\n\n
Intercept any authenticated request carrying a JWT in the Authorization header. Burp automatically decodes it in the JSON Web Token tab. You’ll see something like:
\n\n
Header: { \"alg\": \"HS256\", \"typ\": \"JWT\" }\nPayload: { \"sub\": \"1042\", \"role\": \"user\", \"exp\": 1790000000 }\nSignature: [verified]\n\n
Change \"role\": \"user\" to \"role\": \"admin\" directly in the payload editor. Then switch the algorithm to none in the header and delete the signature. Click Forward. If the server accepts it, you have a critical privilege escalation — the app is trusting the token without validating the signature.
\n\n
If none fails, try the alg confusion attack: grab the server’s RSA public key from https://app.corp-internal.com/.well-known/jwks.json, sign the modified JWT with that public key using the HS256 algorithm, and forward it. Many libraries that handle both RS256 and HS256 will verify the HS256 token using the public key as the HMAC secret — a well-documented class of vulnerability.
\n\n
What To Do Now
\n\n
Open Burp Suite Pro right now and navigate to Settings → Sessions → Session Handling Rules. If you have zero rules configured, you are running every scan unauthenticated by default — meaning you are missing the entire authenticated attack surface. Add a rule that grabs a fresh session token before each scan using a macro. It takes ten minutes to set up and instantly doubles the coverage of every future assessment you run.
