Encoding Your Best Pentester Into Every Scan

Scope - What This Guide Covers

This guide shows you how to use custom scan checks in Burp Suite to automate security expertise across your application portfolio. You'll learn to:

• Build checks that respond to emerging vulnerabilities quickly
• Encode organization-specific security requirements into reusable tests
• Scale expert-level security analysis without adding headcount
• Integrate custom checks into your existing DAST workflows

This applies whether you're running Burp Suite Professional for manual testing or Burp Suite Enterprise for continuous scanning. The same scan engine powers both, so your custom checks work everywhere.

Key Concepts and Definitions

Custom scan checks are user-defined test routines that extend Burp Suite's detection capabilities. Unlike passive extensions that observe traffic, these checks actively probe for specific vulnerabilities during automated scans.

Scan engine refers to Burp's core testing framework. Since 18,000+ security teams trust Burp Suite, the shared engine between Professional and DAST means your custom checks automatically scale from manual pentests to CI/CD pipelines.

Expert logic means the decision trees, edge cases, and context-aware tests that experienced practitioners apply during manual assessments. Custom checks encode this reasoning into repeatable automation.

Requirements Breakdown

When You Need Custom Checks

Standard DAST tools cover OWASP Top 10 categories well. You need custom checks when:

1. Zero-day response - A new CVE drops (like React2Shell) and you need detection across 50+ applications before vendors ship signatures.
2. Framework-specific tests - Your team uses GraphQL, gRPC, or custom authentication that generic scanners miss.
3. Compliance-specific validation - PCI DSS Requirement 6.4.3 mandates script integrity checks that standard tools don't validate.
4. Environment constraints - Your staging environment uses different authentication flows than production.

What Custom Checks Can Detect

You can build checks for:

• Input validation gaps - Test for business logic flaws specific to your domain (e.g., negative quantity orders, privilege escalation through parameter tampering).
• Configuration weaknesses - Detect exposed debug endpoints, overly permissive CORS policies, or API versioning issues.
• Authentication bypasses - Probe for session fixation, JWT manipulation, or OAuth misconfigurations unique to your implementation.
• Injection variants - Test for NoSQL injection, LDAP injection, or template injection in custom frameworks.

Implementation Guidance

Building Your First Check

Start with a recent finding from manual testing. Ask: "Could I have detected this automatically?"

Step 1: Define the detection logic

• What request triggers the vulnerability?
• What response indicates success?
• What false positive scenarios exist?

Step 2: Write the check Burp Suite uses Java-based extensions. Your check needs:

• Request generation logic (modify parameters, headers, payloads)
• Response analysis (status codes, response bodies, timing)
• Confidence scoring (how certain are you this is a real issue?)

Step 3: Test against known-good and known-bad cases Run your check against:

• An application you know is vulnerable
• An application you know is patched
• An application with similar but non-vulnerable patterns

Step 4: Deploy across your scan configurations Add the check to scan profiles in Burp Suite DAST. It runs automatically on every scan.

Rapid Threat Response Pattern

When a new vulnerability drops:

1. Hour 0-2: Analyze the vulnerability mechanics. What makes exploitation possible?
2. Hour 2-6: Write a detection check. Focus on accuracy over elegance.
3. Hour 6-8: Test against a representative sample (3-5 applications).
4. Hour 8+: Deploy to all active scan configurations.

React2Shell demonstrates this pattern. Within 24 hours of public disclosure, teams with custom check capabilities had detection running across their entire application portfolio.

Institutionalizing Expert Knowledge

Your senior pentester notices that your authentication API accepts JWT tokens with "alg":"none". She finds this across three applications during manual testing.

Instead of filing three separate reports, she writes a custom check that:

• Intercepts JWT authentication requests
• Modifies the algorithm header to "none"
• Removes the signature
• Flags successful authentication as a critical finding

Now every scan tests for this issue. When your team ships a new microservice, it gets checked automatically. When she leaves for another role, her expertise remains.

Common Pitfalls

False Positive Floods

Problem: Your check triggers on every response containing "error" in the JSON.

Solution: Add context. Check for specific error codes, validate the request actually modified protected resources, and use confidence levels (Low/Medium/High) appropriately.

Overly Specific Checks

Problem: Your check only works against one application because it hardcodes endpoints or session tokens.

Solution: Parameterize your checks. Use Burp's insertion point API to test all relevant parameters, not just the one you found manually.

Performance Degradation

Problem: Your custom checks add 45 minutes to every scan.

Solution: Optimize request patterns. If you're testing 20 JWT manipulation variants, start with the most likely to succeed. Use early-exit logic when you get a definitive result.

Maintenance Neglect

Problem: Your checks break when the application framework updates.

Solution: Version your checks alongside application releases. Review custom check effectiveness quarterly. Retire checks that produce zero findings for 6+ months.

Quick Reference Table

Use Case	Check Type	Typical Response Time	Compliance Mapping
Zero-day detection	Signature-based probe	1-24 hours from disclosure	NIST CSF PR.IP-12
Business logic flaws	Multi-step validation	2-5 days (requires analysis)	OWASP ASVS v4.0.3 §13
Framework-specific auth	Token manipulation	4-8 hours	PCI DSS v4.0.1 Req 6.4.3
API versioning issues	Endpoint enumeration	2-4 hours	ISO 27001 A.8.3
Custom header validation	Request modification	1-2 hours	SOC 2 Type II CC6.1

Check Performance Benchmarks

• Simple parameter injection: 5-15 seconds per endpoint
• Multi-step authentication bypass: 30-90 seconds per flow
• Complex business logic validation: 2-5 minutes per workflow

Integration Points

• CI/CD pipelines: Trigger scans with custom checks on every merge to main
• Vulnerability management: Export findings to Jira, ServiceNow, or DefectDojo with custom severity mappings
• Threat intelligence: Subscribe to CVE feeds and auto-deploy checks for relevant vulnerabilities

Your custom checks become your institutional memory. They ensure that every lesson learned during manual testing becomes permanent protection.