You're facing a potential insecure deserialization vulnerability in a web application. Crafting a proof-of-concept (PoC) usually involves tedious documentation review and payload crafting. What if you could delegate this task to an AI and get a functional PoC in under a minute?
Pentester Julen Garrido Estévez explored this scenario with Burp AI, assessing how different prompt structures affect speed and cost. His conclusion: free-form prompts based on official documentation resolved vulnerabilities with fewer requests and lower costs than other methods. For the insecure deserialization test, a well-crafted prompt required only 6 requests at approximately €0.34.
This template provides the prompt structure that worked, plus customization guidance for your testing scenarios.
Purpose of the Template
This prompt template helps you generate functional PoC exploits using Burp AI or similar AI-assisted pentesting tools. Use it when you:
- Need to validate a suspected vulnerability quickly
- Want to explore attack vectors without crafting payloads from scratch
- Are working through multiple similar vulnerabilities and need consistency
- Need to document exploitation steps for remediation teams
The template follows a free-form structure that provides context without over-constraining the AI's reasoning process. It's designed to balance token cost against accuracy.
Prerequisites
Before using this template:
- Access to Burp Suite Professional with AI features enabled - The AI assistant must access your HTTP request/response history
- Target environment configured - Your Burp proxy should capture traffic from the application you're testing
- Baseline understanding of the vulnerability class - You should know what you're looking for (e.g., "insecure deserialization")
- Official vulnerability documentation - Have the OWASP or CWE reference handy for the vulnerability type
- Permission to test - Ensure you have authorization for active exploitation attempts
The Prompt Template
I'm testing for [VULNERABILITY_TYPE] in [APPLICATION_CONTEXT].
Background:
- The application uses [TECHNOLOGY_STACK]
- I've identified [SPECIFIC_INDICATOR] in [LOCATION]
- According to [OFFICIAL_DOCUMENTATION_REFERENCE], this vulnerability occurs when [BRIEF_MECHANISM]
Current state:
[PASTE_RELEVANT_REQUEST_OR_RESPONSE]
Task:
Generate a proof-of-concept that demonstrates [SPECIFIC_IMPACT]. The PoC should:
1. [REQUIRED_BEHAVIOR_1]
2. [REQUIRED_BEHAVIOR_2]
3. Be verifiable through [OBSERVABLE_OUTCOME]
Constraints:
- [ANY_TECHNICAL_LIMITATIONS]
- [ENVIRONMENTAL_FACTORS]
Start with the most direct exploitation path.
Example: Insecure Deserialization
I'm testing for insecure deserialization in a Java web application.
Background:
- The application uses Java with a custom session management implementation
- I've identified a Base64-encoded serialized object in the session cookie
- According to OWASP, insecure deserialization occurs when untrusted data is used to reconstruct objects, allowing attackers to execute arbitrary code or manipulate application logic
Current state:
GET /dashboard HTTP/1.1
Host: target.example.com
Cookie: session=rO0ABXNyABdqYXZhLnV0aWwuSGFzaE1hcAAA...
Task:
Generate a proof-of-concept that demonstrates remote code execution. The PoC should:
1. Create a malicious serialized object that executes a system command
2. Properly encode it for the session cookie
3. Be verifiable through a DNS callback or HTTP request to my controlled server
Constraints:
- The application runs on Linux
- Common Java deserialization gadgets (CommonsCollections, etc.) are likely available
Start with the most direct exploitation path.
Customizing the Template
For Different Vulnerability Types
SQL Injection:
- Replace vulnerability type and mechanism
- Include database error messages or behavior patterns you've observed
- Specify whether you need data extraction, authentication bypass, or other impact
- Reference OWASP Testing Guide v4 section 4.8 for SQL injection
Cross-Site Scripting (XSS):
- Describe the injection context (attribute, script block, HTML body)
- Include any filtering or encoding you've observed
- Specify required payload behavior (cookie theft, DOM manipulation, etc.)
- Note Content Security Policy restrictions if present
Authentication Bypass:
- Detail the authentication mechanism
- Include any error messages or behavioral differences you've noticed
- Specify what "successful bypass" looks like in this context
Adjusting Specificity
More Specific (when you know exactly what you need):
- Add technical constraints: "The payload must not contain quotes"
- Specify exact success criteria: "Should return admin user data in JSON response"
- Include failed attempts: "I tried X and Y, both were blocked by Z"
Less Specific (when exploring):
- Remove numbered requirements, use: "Demonstrate the security impact"
- Replace constraints with: "Work within typical production environment limitations"
- Let the AI suggest multiple approaches: "Provide 2-3 exploitation paths"
Cost Optimization
Based on Garrido Estévez's testing, free-form prompts cost less than structured ones while maintaining accuracy. To keep costs down:
- Front-load the context in a single prompt rather than iterating
- Include relevant HTTP traffic in the initial prompt
- Reference official documentation by name (the AI can access common security resources)
- Avoid: "What should I try next?" Follow-ups cost more than comprehensive initial prompts
Validation Steps
1. Review the Generated PoC Before Execution
Don't blindly run AI-generated exploits. Check:
- Does the payload target the correct parameter/location?
- Are there any destructive operations (file deletion, database drops)?
- Does it match your understanding of the vulnerability?
2. Test in a Controlled Environment First
If you have a staging environment with similar configuration:
- Run the PoC there before production testing
- Verify the exploit mechanism, not just the outcome
- Document any environmental differences that affect reliability
3. Verify the Actual Security Impact
The AI might generate a working exploit that doesn't prove the business risk:
- Confirm the impact matches your threat model
- Document what an attacker could achieve
- Capture evidence for your remediation report
4. Document Token Usage and Cost
Track your prompts' efficiency:
- Count the number of requests needed for a working PoC
- Note approximate cost (Burp AI shows token usage)
- Refine your template based on what works for your common vulnerability types
5. Validate Against False Positives
AI-generated exploits can appear to work without actually exploiting the vulnerability:
- Verify the mechanism, not just the outcome
- Test with both malicious and benign inputs
- Confirm the vulnerability exists in the code, not just the behavior
This template structure resolved Garrido Estévez's test case in 6 requests. Your mileage will vary based on application complexity and vulnerability type, but the free-form approach consistently outperformed more rigid prompt structures in both cost and accuracy. Start here, track what works for your testing patterns, and adjust the template as you learn which context your AI assistant needs most.
