GourdScanV2: Building a Passive Vulnerability Scanner with Redis-Backed Traffic Interception

Hook

Most vulnerability scanners pummel your application with thousands of requests. GourdScanV2 takes the opposite approach: it sits quietly on your network, intercepts traffic you're already generating, and tests each request for vulnerabilities as it passes through—turning your normal browsing into a continuous security audit.

Context

Active web vulnerability scanners face a fundamental problem: they're loud, slow, and disruptive. Tools like Burp Suite's active scanner or OWASP ZAP crawl your application, generating thousands of requests with attack payloads, which can trigger rate limits, fill logs with noise, and even crash unstable endpoints. In production environments or bug bounty programs with strict rules of engagement, this aggressive approach often isn't viable.

GourdScanV2, developed by the Yunjia Security Research team, addresses this by implementing a passive scanning architecture. Instead of generating new traffic, it intercepts HTTP/HTTPS requests you're already making—whether from manual testing, automated functional tests, or real user traffic—and replays each request with vulnerability payloads. This approach is particularly valuable for internal corporate security audits where you control the network infrastructure but can't risk disrupting services, or for penetration testers who want to ensure they haven't missed injection points during manual testing. The system captures packets, queues them in Redis, and distributes scanning work across multiple workers, creating a pipeline that transforms ordinary traffic into continuous vulnerability detection.

Technical Insight

GourdScanV2's architecture revolves around three decoupled components connected through Redis queues. The traffic capture layer offers three modes: proxy_io.py (a Tornado-based HTTP proxy), mix_proxy (combining proxy with Scapy packet capture), and pure Scapy network interface sniffing. Each captured request gets base64-encoded and pushed into Redis with a structure like this:

# Simplified packet structure stored in Redis
packet_data = {
    'url': 'https://example.com/api/search?q=test',
    'method': 'GET',
    'headers': base64.b64encode(header_string),
    'body': base64.b64encode(post_data),
    'cookies': base64.b64encode(cookie_string),
    'timestamp': 1640000000
}
redis_client.lpush('waiting_queue', json.dumps(packet_data))

The scanning workers pull from this waiting_queue and iterate through XML-based detection rules. For SQL injection, GourdScanV2 implements a multi-stage verification strategy to reduce false positives. Time-based blind SQL injection tests inject payloads like ' AND SLEEP(5)-- and measure response time, then verify with a 10-second delay. If both tests exceed expected thresholds, it flags a vulnerability:

# Conceptual time-based SQL injection detection logic
def test_time_based_sqli(original_request, injection_point):
    baseline_time = measure_response_time(original_request)
    
    # First verification with 5-second delay
    payload_5s = inject_payload(original_request, "' AND SLEEP(5)--", injection_point)
    response_time_5s = measure_response_time(payload_5s)
    
    if response_time_5s < baseline_time + 4.5:  # Allow 0.5s tolerance
        return False
    
    # Second verification with 10-second delay
    payload_10s = inject_payload(original_request, "' AND SLEEP(10)--", injection_point)
    response_time_10s = measure_response_time(payload_10s)
    
    if response_time_10s < baseline_time + 9.5:
        return False
    
    # Mark as vulnerable if both tests pass
    redis_client.lpush('vulnerable_queue', create_vuln_report(original_request, injection_point))
    return True

For boolean-based SQL injection, the system injects payloads designed to return true and false conditions (like ' AND 1=1-- versus ' AND 1=2--), comparing response content to detect conditional behavior. Reflection-based detection looks for injected syntax characters appearing in responses.

The rule system uses XML files organized by vulnerability type, with each rule specifying scan level (1-10), payload templates, and response validation logic. This modularity means you can extend detection by dropping new XML files into the rules directory without modifying core code. The scan level system lets users balance depth versus false positives—level 1 might test only the most common SQL injection vectors, while level 10 includes dozens of database-specific variations.

GourdScanV2 also integrates with SQLMap API for comprehensive SQL injection testing. When a potential SQL injection is detected by the basic rules, the system can optionally forward the request to a running SQLMap API instance, which performs deeper exploitation attempts. This creates a two-tier detection system: fast, lightweight initial screening followed by intensive verification for promising candidates.

The web dashboard, built with a lightweight Python framework, provides real-time monitoring of the four Redis queues (waiting, running, finished, vulnerable) and allows operators to start/stop scanning threads, adjust scan levels, and export vulnerability reports. Thread management is explicit rather than automatic—you manually configure how many worker threads scan each vulnerability type, giving you control over resource usage but requiring more operational overhead.

Gotcha

The HTTPS interception architecture reveals GourdScanV2's age and its focus on controlled internal environments rather than modern web applications. To intercept HTTPS traffic, you must install GourdScanV2's root certificate and configure your browser to trust it. However, this trust must be established for every domain and subdomain separately in practice, which becomes painful when testing applications that use multiple CDN domains, third-party APIs, or microservice architectures. The documentation mentions Chrome certificate workarounds, but these feel fragile and break with browser updates. Modern applications with aggressive certificate pinning simply won't work.

Thread stability issues are acknowledged directly in the documentation. Scanning workers can crash due to network timeouts, malformed responses, or edge cases in payload injection, requiring manual intervention through the web interface to reset threads. The SQLMap integration cannot run simultaneously with Scapy packet capture mode because SQLMap's recursive scanning creates feedback loops—it generates new requests that get captured, queued, and scanned again, creating infinite loops. The fact that proxy_io.py cannot be cleanly stopped in multi-threaded mode suggests the codebase has concurrency management issues. Most critically, the open-source release deliberately ships with minimal detection rules and includes explicit warnings against unauthorized use, citing Chinese cybersecurity law. The authors clearly positioned this as an educational tool or framework rather than a turnkey solution, expecting users to develop their own comprehensive rulesets. For organizations wanting immediate value without rule development, this is a non-starter.

Verdict

Use GourdScanV2 if you're conducting authorized security testing of internal web applications where you control the network infrastructure and can tolerate HTTPS certificate friction, or if you're a security researcher who wants to study passive scanning architectures and build custom detection rules for specific vulnerability classes. It's particularly valuable when you need to monitor traffic from automated testing pipelines or want to ensure manual penetration testing hasn't missed injection points, and you have the Python skills to extend the rule system and fix stability issues. Skip it if you need comprehensive out-of-the-box vulnerability detection (the open-source rules are deliberately limited), if you're testing modern SaaS applications with complex HTTPS/microservice architectures (certificate management becomes impossible), if you want production-ready stability (thread crashes and architectural quirks require constant babysitting), or if you need active documentation and community support in English (the project is Chinese-language focused and updates have slowed). For most developers, OWASP ZAP's passive scanner provides similar passive detection with far better stability and rule coverage, while Nuclei offers more flexible template-based scanning if you're willing to move to active testing.