Turbo Intruder: When You Need to Send a Million Requests Without Melting Your Machine

Hook

Most HTTP libraries are optimized for typical web traffic. Turbo Intruder is optimized for the exact opposite: sending large numbers of HTTP requests to the same host for extended periods without exhausting memory. It’s built with a custom stack that can outpace asynchronous Go scripts on many targets.

Context

Standard web security testing tools hit a wall when you need sustained, high-volume attacks against a single target. Burp Intruder, the industry standard for payload-based testing, becomes impractical when you need exceptional speed, duration, or complexity—like exploiting race conditions or fuzzing across large parameter spaces. Even purpose-built tools struggle with the specific constraints of security research: maintaining state across multi-step sequences, signing requests with custom algorithms, or intentionally crafting malformed HTTP that breaks RFC compliance. Meanwhile, the rise of HTTP/2 introduced scenarios where you need lower-level protocol control—something standard libraries don’t typically expose.

PortSwigger built Turbo Intruder to fill this gap. Rather than wrapping an existing HTTP library, they wrote a custom network stack in Kotlin from the ground up, prioritizing speed and memory efficiency over broad compatibility. The tool extends Burp Suite but can also run headless via command line for long-running campaigns. It’s explicitly designed for advanced users tackling problems that standard tools can’t handle: attacks requiring exceptional speed or duration, complex authentication flows, and scenarios demanding programmatic control.

Technical Insight

Turbo Intruder’s architecture makes an unusual trade-off: it sacrifices the battle-tested reliability of standard HTTP libraries for raw speed and memory control. The core is a custom HTTP stack written in Kotlin that strips away features most applications need in favor of a lean request engine optimized for saturating a single target. This isn’t just optimization; it’s a fundamentally different approach focused on one specific use case rather than broad compatibility.

The Python scripting layer sits on top of this engine, giving you programmatic control over request generation and result processing. Unlike Burp Intruder’s GUI-based payload positions, you write actual code. This script-driven approach becomes essential for complex scenarios. Need to sign each request with HMAC based on a timestamp? Write a function. Need to maintain session state across a multi-step attack? Use Python variables. Need to send intentionally malformed HTTP that violates specifications? The custom stack is designed to handle it.

The memory management is particularly notable. Most HTTP libraries accumulate response data in memory, which becomes problematic when processing large numbers of responses. Turbo Intruder implements a diffing algorithm adapted from Backslash Powered Scanner that compares responses and filters results automatically. This enables what PortSwigger calls ‘flat memory usage,’ where memory consumption remains constant regardless of request volume. The diffing algorithm can distinguish between responses that differ only in dynamic tokens (session IDs, timestamps) versus responses with meaningful variations, automatically filtering noise from results.

For HTTP/2 research, Turbo Intruder provides capabilities for lower-level protocol manipulation. The repository includes a reference implementation for single-packet attacks in SpikeEngine.kt and SpikeConnection.kt. These files demonstrate how to bundle multiple HTTP/2 requests into a single TCP packet to exploit timing-based vulnerabilities in server-side request routing. This implementation builds on Burp Suite’s native HTTP/2 stack and provides frame-level control that general-purpose HTTP clients don’t expose. According to the README, it should be possible to create similar implementations using any HTTP/2 library that provides a frame-level interface.

This level of control—from malformed request handling to frame-level HTTP/2 manipulation—reflects the tool’s design philosophy: enabling attacks that require exceptional speed, duration, or complexity by giving researchers direct access to low-level primitives.

Gotcha

The README is refreshingly blunt: ‘the network stack isn’t as reliable and battle-tested as core Burp’s.’ This matters more than it might sound. When you’re sending malformed requests or operating at extreme speeds, you’ll hit edge cases where the custom HTTP stack behaves unexpectedly—dropped connections, parse errors, or subtle protocol violations that work against some servers but not others. Because the stack prioritizes speed over broad compatibility, you’re trading reliability for raw performance. For most standard web applications, this trade-off works. For unusual server implementations or enterprise proxies with strict compliance checking, you might find Turbo Intruder silently failing where standard tools succeed.

The learning curve is steep by design. PortSwigger explicitly states this is ‘a tool for advanced users only’ and that they will not provide personal support. You need working knowledge of Python, comfort with HTTP protocol internals, and the patience to debug scripts when things go wrong. There’s no GUI wizard stepping you through payload configuration. If you’re still learning the basics of web security testing or don’t regularly write code, Turbo Intruder will frustrate you. Additionally, it’s architected for a specific use case: many requests to one host. The README explicitly notes that if you want to send a single request to many hosts, tools like ZGrab are recommended instead. Turbo Intruder would be dramatically inefficient for that inverse problem.

Verdict

Use Turbo Intruder if you’re conducting advanced security research that requires sustained, high-volume attacks against a single target—exploiting race conditions, testing rate limiting implementations, fuzzing for parser differentials, or researching HTTP/2 vulnerabilities. It excels when you need attacks requiring exceptional speed or duration without memory exhaustion, when you need to programmatically control complex authentication flows, or when you’re intentionally sending malformed HTTP that breaks standard libraries. It’s the right choice when Burp Intruder’s speed or flexibility has become the bottleneck in your testing. Skip if you’re doing standard vulnerability scanning across multiple hosts, if you need maximum reliability over raw speed, or if you’re not comfortable debugging Python scripts and HTTP protocol details. For most common web application testing, Burp Intruder’s built-in capabilities provide better reliability and easier operation. Choose Turbo Intruder when you’ve already exhausted simpler tools and need its specific combination of speed, scriptability, and low-level protocol control for attacks targeting a single host.