I recently went through the process of wiring up Burp Suite’s MCP Server with Claude Code on Kali Linux, following an article from SecEngAI. The concept is solid: Claude Code running in your terminal with direct access to your Burp proxy history, able to generate test cases, create Repeater tabs, run SSRF checks with Collaborator, and write up findings, all via natural language prompts.

Here’s how it actually went, including the part where things went sideways in Community Edition.


What You’re Building

The architecture is straightforward:

Claude Code (terminal) ←→ mcp-proxy-all.jar ←→ Burp MCP Extension (SSE on :9876)

Claude Code speaks to a stdio proxy jar, which forwards to the Burp extension’s SSE server running locally on port 9876. From Claude’s perspective it’s just tools: get_proxy_http_history, create_repeater_tab, send_http1_request, etc.


Prerequisites

  • Kali Linux (tested on 2025.x)
  • Burp Suite (Community or Pro)
  • Node.js 18+ and npm
  • Java (JDK, not just JRE)
  • An Anthropic account (Claude.ai Pro or Console API key). Note: Claude Code requires a Claude.ai Pro subscription or Anthropic API credits.

Step 1: Install the Burp MCP Extension

In Burp Suite:

  1. Go to Extensions → BApp Store
  2. Search for MCP Server
  3. Click Install

Once loaded, click the MCP tab. You should see the server configuration. Flip the Enabled toggle on. The extension output should show:

Started MCP server on 127.0.0.1:9876

Good. Leave Burp running.


Step 2: Get the Proxy Jar — Here’s Where Community Edition Lacks

The article casually says to “extract mcp-proxy.jar via the MCP tab in Burp.” On Burp Pro, there’s an installer button in the MCP tab that does this for you. On Community Edition, that button doesn’t exist.

You might also notice a mcp-proxy.jar already sitting in your home directory — but check the file size first:

ls -lh ~/mcp-proxy.jar

If it’s 0 bytes, it’s def an empty placeholder. That’s what happened here.

The fix: build it from source.

# Install prerequisites
sudo apt install -y git default-jdk

# Clone the repo
cd ~
git clone https://github.com/PortSwigger/mcp-server.git
cd mcp-server

# Build
./gradlew embedProxyJar

After the build completes, check what was produced:

find . -name "*.jar"

You should see:

./build/libs/burp-mcp-all.jar
./gradle/wrapper/gradle-wrapper.jar
./libs/mcp-proxy-all.jar

The one you need is ./libs/mcp-proxy-all.jar. It was already in the repo, and the build just confirms everything is intact.

Note: build/libs/burp-mcp-all.jar is the Burp extension itself. If you want the freshly built version instead of the BApp Store install, you can load it manually: Extensions → Add → Java → select this jar.


Step 3: Install Claude Code

npm install -g @anthropic-ai/claude-code

Verify:

claude --version

Step 4: Create the Project Folder and Config

mkdir -p ~/burp_mcp

Create .mcp.json — this tells Claude Code how to connect to Burp:

vim ~/burp_mcp/.mcp.json
{
  "mcpServers": {
    "burp-mcp": {
      "command": "java",
      "args": [
        "-jar",
        "/home/kali/mcp-server/libs/mcp-proxy-all.jar",
        "--sse-url",
        "http://127.0.0.1:9876"
      ]
    }
  }
}

Step 5: Create CLAUDE.md

This is the project context file. Claude reads it at the start of each session to understand your scope and setup. This is a minimal example by the way, for a real engagement context project context file (calling other tools than Burp), see the end of the page.

vim ~/burp_mcp/CLAUDE.md
# Pentest Project

## Target Scope
- target.example.com

## Tools Available
- Burp Suite Community
- burp-mcp extension loaded on 127.0.0.1:9876

## Output
- Save reports to ./reports/
- Use markdown format

Customize the scope to match your actual engagement.


Step 6: Launch

Make sure Burp is open with the MCP extension enabled, then:

cd ~/burp_mcp
claude

Claude Code will pick up .mcp.json automatically and initialize the MCP connection. To confirm it’s working:

> what burp tools do you have access to?

You should see Claude list out tools like get_proxy_http_history, send_http1_request, create_repeater_tab, and so on.

From there you’re live. Try:

Get all the parameterized requests from burp history

Burp Community vs Pro

A few tools won’t work on Community Edition:

FeatureCommunityPro
Proxy history access
Repeater tab creation
Send HTTP requests
Collaborator payloads
Active Scanner
MCP tab jar installer

Core testing workflows still work fine on Community. You just won’t have OOB/SSRF detection via Collaborator.


Security Note

The article flags this and it’s worth repeating: HTTP responses from target applications can contain prompt injection attempts. A malicious target could craft a response body designed to manipulate Claude’s next action.

Mitigations already enabled in the MCP tab (as configured above):

  • ✅ Require approval for HTTP requests
  • ✅ Require approval for history access

Don’t disable these. Review what Claude proposes before approving, especially when it’s about to send requests or modify Burp state.

Here’s what a real CLAUDE.md looks like for an actual research workflow. This one is built around two custom tools: EPMMScout, a python Shodan-based honeypot filter and geographic segmenter, and IvantiSwarm, a golang high-concurrency pre-auth RCE prober for Ivanti EPMM. The tools themselves aren’t published here, the CVEs are known (CVE-2026-1281 and CVE-2026-1340), but the tooling stays private. The point is to show how you’d wire Claude Code into your own existing toolkit, whatever that looks like.”

# Ivanti EPMM Vulnerability Research
## Research Scope
- CVE-2026-1281 (Ivanti EPMM pre-auth RCE)
- CVE-2026-1340 (Ivanti EPMM pre-auth RCE)
- Authorized research and internal lab environments only

## Workflow Overview
1. EPMMScout ingests raw Shodan/Censys/FOFA JSON export
2. EPMMScout filters honeypots (<6 open ports) and segments by country → outputs ./finals/*.txt
3. IvantiSwarm consumes ./finals/ directory and probes targets in parallel
4. Results written to results.jsonl
5. Claude analyzes results and documents findings

## Tools

### EPMMScout (Python)
- **Location:** ~/tools/EPMMScout.py
- **Purpose:** Filters honeypots from Shodan exports, segments IPs by country
- **Input:** Raw Shodan JSON export (array or NDJSON format)
- **Output:** ./finals/<country_code>.txt — one IP per line, per country
- **Honeypot filter:** Drops IPs with fewer than 6 open ports
- **Usage:**

  python3 ~/tools/EPMMScout.py shodan_results.json

### IvantiSwarm (Go)
- **Location:** ~/tools/IvantiSwarm (compiled binary)
- **Purpose:** High-concurrency pre-auth RCE probe against Ivanti EPMM
- **Input:** Directory of .txt IP lists (e.g. ./finals/)
- **Output:** results.jsonl — one JSON record per target with IP, method, status, response time, error
- **Modes:**
  - `sleep5` — timing-based blind RCE check (~5s delay)
  - `wht` — outbound callback via webhook.site (confirms execution)
  - `wri` — callback with `?data=$(id)` (confirms RCE + returns user context)
- **Workers:** 200 concurrent goroutines
- **Usage:** Interactive — prompts for mode, IP folder, and webhook ID

## Exploit Chain Reference
- Entry point: `/mifs/c/appstore/fob/3/5/` — pre-auth, no session required
- Payload injected via path segment using XPath/gPath injection
- `sleep5` for blind timing confirmation

## Operational Rules
- Run EPMMScout first — never feed raw Shodan data directly to IvantiSwarm
- `sleep5` is safe for initial probing
- Flag any target with response time < 100ms on sleep5 as a likely honeypot
- Log all activity — do not delete results.jsonl between sessions

## Output
- Recon and EPMMScout output: ./recon/
- IvantiSwarm results: ./logs/results.jsonl
- Final report: ./reports/ in markdown
- Reports must include: CVE refs, affected versions, target count, confirmed RCE evidence, geographic breakdown

References