ByteBanter

AnvilSecure presents ByteBanter! ByteBanter is a Burp Suite extension that leverages Large Language Models (LLMs) to generate intelligent and context-aware payloads for Burp Intruder. By integrating AI capabilities, ByteBanter enhances automated security testing by producing diverse and adaptive payloads tailored to specific testing scenarios.

Features

• LLM-Driven Payload Generation: Utilizes LLMs to create dynamic payloads based on user-defined prompts and contexts.
• Seamless Burp Integration: Registers as a custom payload generator within Burp Intruder, allowing easy selection and use.
• Configurable Prompts: Users can define and customize prompts to guide the LLM in generating desired payloads.
• Support for Multiple LLM Providers: Burp AI is the default provider; the extension also supports Ollama, the Anthropic Messages API, any OpenAI-compatible chat/completions endpoint (e.g. OpenAI, Oobabooga, LM Studio, vLLM), and the Claude Code CLI (locally installed) for users who prefer to route prompts through their existing Anthropic subscription.
• ASCII Smuggling: optionally hide text inside the invisible Unicode Tags block (U+E0000–U+E007F) so generated payloads carry instructions that are invisible in most UIs yet decoded by many downstream LLMs (see ASCII Smuggling).
• Scriptable Response Matching: the Stateful Interaction feature has a Script mode where a small Groovy script — instead of a regex — extracts the portion of each response fed back into a stateful conversation, with a syntax-highlighted pop-up editor, a Test runner, AI script generation from an example response, and a "Send to extraction script" right-click action (see Prompt and response context).

This version of ByteBanter complies with the BApp Store standards for extensions that use third-party LLMs:

• Declares EnhancedCapability.AI_FEATURES and verifies that Burp AI is enabled before any LLM call.
• Burp AI is configured as the default provider.
• All third-party LLM requests use the Montoya API networking capabilities (api.http().sendRequest).
• All third-party LLM requests are sent with RequestOptions.withUpstreamTLSVerification() to verify the integrity of the data sent to the provider.

Installation

You can find this version of ByteBanter in the official BurpSuite BApp store. But If you prefer you can compile the code by yourself according to the following instructions.

• Clone the Repository:

git clone https://github.com/anvilsecure/bytebanter-burpai/

• Build the Extension: Navigate to the project directory and build the JAR file using your preferred build tool (e.g., Maven or Gradle).

mvn clean package

gradle build

• Load into Burp Suite:
  • Open Burp Suite.
  • Go to the Extender tab.
  • Click on Add.
  • Select the built JAR file (the uber one) to load the extension.

Usage

• Configure the engine:
  • Open the newly added ByteBanter tab in Burp Suite.
  • Pick an engine from the combo box in the top right corner (Burp AI by default; switch to Ollama, OpenAI-compatible, or Anthropic if you prefer).
  • Fill in URL / API key / model for the selected engine — see Configuration for per-engine details.
• Set Up Intruder Attack:
  • Go to the Intruder tab.
  • Configure your target and positions as usual.
• Select ByteBanter as Payload Source:
  • In the Payloads tab:
  • Set Payload type to Extension-generated.
  • Choose ByteBanter from the list of available generators.
• Define Prompts:
  • Within the ByteBanter tab, create and customize prompts that will guide the LLM in generating payloads.
  • Optionally enable Success Verification to highlight responses that meet a user-defined criterion (see Success Verification below).
• Start the Attack:
  • Run the Intruder attack.
  • ByteBanter will generate and supply payloads dynamically using the configured LLM.

Configuration

In the ByteBanter extension tab, select the engine you want to use from the combo box in the top right corner (Burp AI is the default). Each engine has its own settings; switching engines preserves the per-engine configuration.

Per-engine configuration

• Burp AI: no endpoint configuration needed. Make sure AI features are enabled in Burp settings; ByteBanter will surface a dialog if they are not.

• Ollama: set the base URL (default http://localhost:11434/). The model dropdown auto-populates by querying /api/tags on the configured URL as soon as it becomes reachable.

• OpenAI-compatible (Chat Completions): set the URL of any /v1/chat/completions endpoint (OpenAI itself, Oobabooga, LM Studio, vLLM, etc.) and add an Authorization: Bearer <token> header in the headers field if the provider requires it.

• Anthropic: keep the default URL https://api.anthropic.com/v1/messages. There is no dedicated field for the API key — paste it in the Headers field of the engine configuration:

  x-api-key: YOUR_ANTHROPIC_API_KEY
  

  ByteBanter automatically adds the required anthropic-version and Content-Type headers, so x-api-key is the only one you need to enter. Pick a model from the editable dropdown (you can also type a custom model ID).

  When the URL points to the official Anthropic API (api.anthropic.com), the engine refuses to send the request if x-api-key is missing from the Headers field. If you point the URL at a proxy or a mock server that does not require this header, the check is skipped.

Multiple headers — the Headers field accepts one header per line. Use a literal newline as separator. Example for Anthropic with an extra custom header:

x-api-key: YOUR_ANTHROPIC_API_KEY
x-custom-trace: my-trace-id

The same applies to the OpenAI-compatible engine if the provider needs both an Authorization and additional headers. Empty lines are ignored.

• Claude Code (CLI): routes prompts through the Claude Code command-line agent installed on the same machine as Burp. Useful when you want to use your existing Anthropic subscription (Claude Pro / Max) without provisioning a separate API key, or when you have Bedrock/Vertex auth already configured for Claude Code.

  Configuration:

  • Claude Code binary — defaults to claude. Override with an absolute path if the CLI is not on the user's PATH (e.g. /Users/you/.local/bin/claude).
  • Model — leave empty to use whatever model Claude Code is configured for, or pick / type a Claude model ID such as claude-sonnet-4-6, claude-opus-4-7, etc.

  How it works internally:

  • ByteBanter spawns claude -p --output-format text and pipes the conversation into the process via stdin.
  • The system role from the conversation is forwarded with --system-prompt (which replaces Claude Code's default coding-agent system prompt), together with --exclude-dynamic-system-prompt-sections, so the engine acts as a pure generator instead of inheriting the agent persona and tone.
  • Authentication is handled entirely by Claude Code itself (whatever you configured: API key, OAuth via claude.ai, AWS Bedrock, Google Vertex).

  Note on refusals: even with the default prompt replaced, driving Claude Code under a Claude.ai subscription (OAuth) applies the stricter consumer safety tier and may still refuse to emit raw offensive payloads. For payload generation, the Anthropic engine (direct Messages API with an API key) is the appropriate channel.

  Caveats:

  • Requires the Claude Code CLI to be installed on the host running Burp.
  • Each LLM call spawns a subprocess (≈ 1–3 seconds of overhead). With Success Verification enabled this adds up quickly, so use a small requestsLimit.
  • Note: this engine bypasses the Montoya networking API — the subprocess makes its own HTTP calls, and authentication/transport are handled entirely by the locally installed Claude Code CLI.

Prompt and response context

Write your prompt to instruct the model on the kind of payloads to generate. Use the Optimize! button to rewrite your prompt while preserving the attack goal and your concrete details (target names, parameter names, secrets, regex patterns). Toggle Stateful Interaction to keep the conversation across payloads and extract the relevant portion of each target response back into the conversation.

The Stateful Interaction panel (enabled with its Enable checkbox) offers two Extraction modes:

• Regex (default): capture group 1 of the regex, matched against the response body, is fed back as the next turn. Optionally Base64-decode it.

• Script (Groovy): write a small Groovy script that returns the string to feed back (or null to skip this response). The following variables are in scope:

  • body — the response body (String)
  • status — the HTTP status code (int)
  • headers — response headers as a Map<String, String>
  • request — the full initiating request (String)
  • response — the full response (String)

  Example:

  // Return the answer field, or null to skip
  def m = (body =~ /"answer":"([^"]*)"/)
  m ? m[0][1] : null

  Scripts are compiled once and cached; any compilation or runtime error is logged to Burp's error log and treated as "no match" so an attack is never interrupted. The script runs locally in Burp's JVM as user-provided Groovy code — only use scripts you trust.

  Script editor (Edit / Test script…). The button opens a pop-up editor with Groovy syntax highlighting and a paste-in Sample response pane (or Load response from file… for a saved response). Two actions help you build the script against a real example:

  • Test — parses the sample response (raw HTTP response, or plain body as a fallback) into the body/status/headers bindings, runs the current script, and shows the extracted value (or the error / "nothing extracted"). This is exactly the code path used at attack time.
  • Generate from response (AI) — sends the sample response (plus your payload-generation prompt as context) to the configured engine and asks it to write a Groovy extraction script, which is dropped into the editor for you to review and Test.

  Click OK to copy the script back into the Script field; Cancel discards changes.

  Send to extraction script (right-click). Anywhere Burp shows a response (Proxy history, Repeater, message editors, etc.), right-click and choose Extensions → ByteBanter → Send to extraction script. ByteBanter switches to stateful Script mode and opens the editor with that response pre-loaded as the sample, ready to Test or to generate a script from.

ASCII Smuggling

The ASCII Smuggling panel transforms the generated payload just before it reaches Intruder, hiding text in the invisible Unicode Tags block (U+E0000–U+E007F). The raw model output is what stays in the stateful conversation history — only the payload emitted to Intruder is transformed. The feature is off by default. Three modes:

• Encode entire payload: the whole generated payload is rendered invisible.
• Append hidden text to payload: the payload stays visible and a user-supplied hidden text is appended in invisible characters (classic prompt-injection carrier).
• Prepend hidden text to payload: as above, but prepended.

The hidden-text field is used only by the append/prepend modes. Because the output is visually empty, verify it with a decoder (e.g. the round-trip helper AsciiSmuggler.decode) before relying on it.

Sensitive Data persistence

The "Persist API key and custom headers across sessions" checkbox controls whether sensitive fields are written to Burp's extension data. It is off by default: API keys and custom headers live only in memory and must be re-entered each session. When checked, those fields are persisted to Burp's extension data file in plaintext on disk — only enable it on machines you trust. The checkbox state itself is always remembered.

Success Verification

After each Intruder response, the selected LLM can judge whether the attack succeeded according to a user-defined criterion. The feature is off by default.

• Enable the checkbox in the Success Verification panel and write your success criterion in the textarea, or click Generate from prompt! to derive a starting criterion from your payload-generation prompt.
• The third widget in the panel changes shape based on the Stateful Interaction panel's Enable checkbox:
  • Stateless (checkbox unchecked): the spinner is "Truncate request/response (chars)". The verifier receives the raw HTTP request and response of the single payload being judged, capped at the configured number of characters per side. Default 4000.
  • Stateful (checkbox checked): the spinner becomes "Conversation history depth (turns)". The verifier receives the last N (ByteBanter payload, regex-extracted target response) turns from the running conversation, so it can detect successes that emerge across multiple exchanges (e.g. a password reconstructed letter-by-letter). Default 1 = only the most recent turn.
  • Both values are persisted independently — toggling Stateful Interaction does not lose the value you set in the other mode.
• When a response matches the criterion, the Intruder result row is highlighted red and a banner-formatted entry is written to Burp's Event Log under the header [ByteBanter] SUCCESSFUL ATTACK DETECTED, including URL, status code, and a short English summary of the winning strategy.
• Only Intruder responses are evaluated; Repeater, Proxy, and other tools are unaffected.
• Each verification triggers one extra LLM call per Intruder response — factor that into your usage and any provider rate limits.

Settings are automatically saved by the extension and persisted in Burp's extension data (subject to the Sensitive Data opt-in above).

Development

Prerequisites

• Java Development Kit (JDK) 17 or higher
• Build tool (Maven or Gradle)
• Burp Suite (Community or Professional Edition)

Contributing

Contributions are welcome!

License

This project is licensed under the MIT License.

Acknowledgments

• PortSwigger for Burp Suite and its extensibility.
• OpenAI, Anthropic, Ollama, and Oobabooga for providing powerful LLM APIs.