Automating Out-of-Band Vulnerability Detection in Burp Suite with Python

Hook

Most security scanners miss the vulnerabilities that matter most: the blind ones that exfiltrate data silently without leaving traces in HTTP responses. This Burp extension turns out-of-band detection from a manual chore into an automated workflow.

Context

Traditional web vulnerability scanners excel at finding issues with immediate feedback—SQL injection that throws database errors, reflected XSS that appears in the response, or path traversal that returns /etc/passwd. But the most dangerous vulnerabilities often operate blindly: stored XSS that fires in an admin panel you can't access, SSRF that queries internal services, or XXE that exfiltrates files through DNS queries. These require out-of-band (OOB) validation—you inject a payload containing a unique callback URL, then wait for your server to receive the request.

Burp Suite's active scanner automates testing for inline vulnerabilities, but adding OOB checks traditionally meant manual work: crafting payloads in Intruder, tracking unique identifiers, and correlating callbacks with specific requests. While Burp Collaborator eventually addressed this gap, earlier versions lacked robust OOB capabilities. The Burp-Scanner-OOB-Checks extension bridges this automation gap by letting you configure OOB payloads once and have them automatically injected during every active scan, with results tracked systematically alongside Burp's native findings.

Technical Insight

The extension leverages Burp's Extender API through Python (via Jython), implementing the IScannerCheck interface to hook into the active scanning pipeline. When Burp's scanner processes an insertion point—a parameter, header, or any injectable location—the extension's doActiveScan method is invoked, allowing custom payload injection alongside Burp's built-in checks.

The architecture centers on a custom tab interface where you configure payloads with placeholder tokens. For example, a blind XSS payload might look like <script src="https://xsshunter.example.com/IDENTIFIER"></script>, where IDENTIFIER gets replaced with a unique value per injection. The extension maintains a mapping between these identifiers and the specific requests that generated them, enabling correlation when callbacks arrive.

Here's a simplified example of how the scanner check integration works:

class CustomScannerCheck(IScannerCheck):
    def doActiveScan(self, baseRequestResponse, insertionPoint):
        # Generate unique identifier for this test
        identifier = self._generate_unique_id()
        
        # Get configured payloads from the extension tab
        payloads = self._config.get_oob_payloads()
        
        issues = []
        for payload_template in payloads:
            # Replace placeholder with unique identifier
            payload = payload_template.replace("{{ID}}", identifier)
            
            # Build and send the request with OOB payload
            attack_request = insertionPoint.buildRequest(payload)
            attack_response = self._callbacks.makeHttpRequest(
                baseRequestResponse.getHttpService(),
                attack_request
            )
            
            # Store correlation data for later verification
            self._store_scan_context(identifier, {
                'request': attack_request,
                'insertion_point': insertionPoint.getInsertionPointName(),
                'payload': payload,
                'timestamp': time.time()
            })
            
            # Check if we've received OOB callback for this identifier
            if self._check_callback_received(identifier):
                issues.append(self._create_issue(
                    baseRequestResponse,
                    attack_request,
                    insertionPoint
                ))
        
        return issues if issues else None

The real power comes from integration with callback services. When paired with XSSHunter, for instance, the extension can inject payloads containing your XSSHunter domain. When the XSS fires (perhaps hours later in an admin panel), XSSHunter receives the callback and logs it. The extension can poll XSSHunter's API or manually check its dashboard to correlate callbacks with scan data.

For SSRF and XXE detection, the workflow is similar but the payloads differ. An SSRF payload might be http://burpcollaborator.net/{{ID}} injected into parameters that accept URLs, while XXE payloads could use external entity definitions that trigger DNS lookups to your OOB server. The extension's payload management interface supports multiple payload types simultaneously, letting you test for diverse vulnerability classes in a single scan pass.

The extension also handles Burp's insertion point types intelligently. It respects content-type boundaries—XML payloads go to XML parameters, JavaScript payloads target script contexts, and URL payloads focus on parameters that expect URLs. This context-aware injection reduces noise and improves detection accuracy compared to blind payload spraying.

Gotcha

The extension's Achilles heel is its dependency on Jython 2.7, which is effectively frozen in time. Modern Python libraries that security testers rely on—like requests for HTTP operations or asyncio for concurrent callback handling—simply don't work in Jython's limited ecosystem. This means any sophisticated callback correlation logic needs to be implemented using Java libraries through Jython's Java interop, which is clunky and poorly documented.

The bigger limitation is timing. OOB vulnerabilities are asynchronous by nature—a stored XSS might not fire until an admin logs in days later. The extension stores scan context for correlation, but there's no elegant way to retroactively match callbacks to Burp issues if the callback arrives after you've closed Burp. You end up maintaining external spreadsheets or databases to track long-running tests, defeating the automation purpose. Additionally, with only 20 GitHub stars and no recent commit activity visible in the metrics, there's a real risk this extension hasn't been tested against recent Burp Suite versions. Burp's Extender API evolves, and unmaintained extensions can break silently or conflict with built-in features. Modern Burp Professional includes Collaborator with polling and automatic issue creation, potentially rendering this extension redundant depending on your workflow.

Verdict

Use if: You're running Burp Suite versions before robust Collaborator integration existed, or you need to integrate with specific OOB platforms beyond Collaborator (like a self-hosted XSSHunter instance or custom callback infrastructure). It's particularly valuable if you're doing extensive blind XSS hunting where you want payloads automatically tested across every scan without manual Intruder sessions. The extension shines when you've already invested in building OOB infrastructure and want to plug it into Burp's scanner workflow. Skip if: You have access to Burp Professional with Collaborator, which provides native OOB detection without extension overhead, or if you're uncomfortable with Jython's limitations and potential compatibility issues. Modern alternatives like Nuclei with Interactsh offer more maintainable, actively developed solutions for OOB testing outside the Burp ecosystem. Also skip if you need production-grade reliability—the low maintenance signals mean you're likely on your own for troubleshooting and updates.