Invoker – Automating Pentesting Tools in Burp Suite (Example with dosfiner)

Invoker BurpSuite Extension – What is it?

Invoker is a Burp Suite extension that automates penetration testing with external tools. It integrates popular programs such as dosfiner, sqlmap, nuclei, ffuf, and tplmap directly with the Burp interface. As a result, pentesters can launch these tools with just one click, passing data from the current HTTP request.

The extension solves the common problem of manually copying URLs, headers, or session cookies to the console – instead, it automatically builds the appropriate commands. This saves time and reduces the risk of mistakes, streamlining the tester’s workflow. Similar to “Invoke Applications” from OWASP ZAP, Invoker greatly speeds up vulnerability hunting.

During my research, I came across another extension called the-burp-extension-no-one-told-you-about. However, Invoker stands out due to its straightforward configuration and the ability to mass-generate CLI commands (with a valid session) from Burp.

InvokerConfig.json Setup

The core of Invoker’s functionality is a JSON config file named InvokerConfig.json. Each entry specifies:

• tool – the name of the tool (e.g., dosfiner, sqlmap),
• name – the label displayed in Burp’s context menu,
• template – a command pattern with placeholders (e.g. {{URL}}, {{BODY}}).

These placeholders in double curly braces are replaced automatically with data taken from the chosen HTTP request. The most common placeholders include:

• {{HOST}}, {{URL}} – host or full URL,
• {{PROTOCOL}} – returns “http” or “https” 
• {{PORT}} – returns the port number ,
• {{RAW_PATH}} – path to the saved raw request,
• {{HEADERS[-H]}} – all headers with a prefix (like -H),
• {{BODY}} – request body (e.g. for POST),
• {{FORCE_SSL}} – e.g. –force-ssl to enforce HTTPS,
• {{FFUF_URL}} – specialized URL with a FUZZ placeholder for ffuf,
• {{OUTPUT}} – output file for result,
• {{METHOD_SWITCH}} – e.g. -g for GET or -p for POST.

Hence, you can define practically any command structure. For instance, a snippet in InvokerConfig.json might look like:

[
  {
    "global_raw_folder": "/tmp/{{HOST}}"
  },
  {
    "name": "dosfiner auto GET/POST",
    "tool": "dosfiner",
    "template": "go run dosfiner.go {{METHOD_SWITCH}} -u \"{{URL}}\" -d \"{{BODY}}\" {{FORCE_SSL}} {{HEADERS[-H]}} -t 999 -proxy \"http://127.0.0.1:8080\""
  },
  {
    "name": "dosfiner raw (-r) Best for Other methods and File Uploads",
    "tool": "dosfiner",
    "template": "go run dosfiner.go -r \"{{RAW_PATH}}\" -t 500 -proxy \"http://127.0.0.1:8080\" {{FORCE_SSL}}"
  },
  {
    "name": "dosfiner raw (-r) in Bash loop (1000x)",
    "tool": "dosfiner",
    "template": "for i in {1..1000}; do\n  go run dosfiner.go -r \"{{RAW_PATH}}\" -t 9999 {{FORCE_SSL}} \n done"
  },
  {
    "name": "sqlmap auto",
    "tool": "sqlmap",
    "template": "sqlmap -u \"{{URL}}\" {{HEADERS[-H]}} --batch --level=5 --risk=3 --tables"
  },
  {
    "name": "sqlmap -r raw request",
    "tool": "sqlmap",
    "template": "sqlmap -r \"{{RAW_PATH}}\" --level 5 --risk 3 {{FORCE_SSL}} --batch --tables"
  },
  {
    "name": "FFUF fuzz",
    "tool": "ffuf",
    "template": "ffuf -u \"{{FFUF_URL}}\" -w /path/to/wordlist.txt -mc 200,403"
  },
  {
    "name": "nuclei normal",
    "tool": "nuclei",
    "template": "nuclei -target \"{{URL}}\" -o \"{{OUTPUT}}\""
  },
  {
    "name": "tplmap basic",
    "tool": "tplmap",
    "template": "tplmap -u \"{{URL}}\" --random-agent"
  },
  {
    "name": "nikto http/https",
    "tool": "nikto",
    "template": "nikto -host \"{{HOST}}\" -port \"{{PORT}}\""
  },
  {
    "name": "nmap basic",
    "tool": "nmap",
    "template": "nmap -p- -sV -sC -Pn --script vuln {{HOST}} -oA \"{{OUTPUT}}\""
  },
  {
    "name": "nikto protocol-based",
    "tool": "nikto",
    "template": "nikto -host \"{{PROTOCOL}}://{{HOST}}:{{PORT}}\""
  }
]
Code language: JSON / JSON with Comments (json)

A few words about the Dosfiner tool

Dosfiner – a tool for DoS testing

Dosfiner is a tool designed to help identify Denial of Service vulnerabilities by automating various DoS attack techniques. It enables a tester to simulate different kinds of DoS conditions and observe how the target application behaves under stress or malicious input. Dosfiner can perform both volumetric attacks (high-volume traffic floods) and application-layer attacks that exploit specific weaknesses. Here are some types of tests Dosfiner can execute:

Flooding

This is the classic DoS approach – overwhelming the server with a huge number of requests in a short time. Dosfiner can generate hundreds or thousands of HTTP requests per second (GET or POST) to a target endpoint, simulating an HTTP Flood attack.

The goal is to see if the server becomes unresponsive, significantly slow, or starts dropping requests under heavy load. If the application lacks proper throttling or scaling, a flood test might lead to increased response times or even a crash. Dosfiner can report metrics like how many requests were successful versus how many timed out or failed, indicating when the service becomes saturated.

Targeting slow endpoints

Certain functionalities in a web app are often inherently slow (e.g., generating a complex report or performing heavy database queries). Exploiting these slow operations can achieve a DoS. Dosfiner can identify endpoints that usually respond slowly and launch concurrent requests to them to amplify the effect.

The idea is that if one request takes 5 seconds of server time, firing 10 or 20 of them simultaneously might exhaust the server’s thread pool or CPU. This is a resource exhaustion attack using legitimate actions.

File upload abuse

A common vector for DoS is uploading large or many files in succession. Dosfiner can automate sending a sequence of file uploads to see how the system handles it. For instance, it could repeatedly try uploading a file just below any apparent size limit to fill up storage or memory. If the application does not enforce size or rate limits on uploads, this could quickly consume server resources.

The tool can also attempt to upload a file slightly above expected limits to see if proper error responses (like HTTP 413 Payload Too Large) are returned. By automating this, Dosfiner can uncover missing safeguards (e.g., if a 1GB file upload attempt causes a 500 error instead of a clean rejection, that is a finding).

Spamming heavy actions (email sending, expensive operations)

Some endpoints trigger external actions or high workload tasks – for example, an API that sends an email or generates a PDF report. If not rate-limited, an attacker could repeatedly call these endpoints to overwhelm the web server and external systems (mail server, file generation service, etc.). Dosfiner can simulate this by rapidly calling such an API dozens or hundreds of times.

The tester would observe if the application continues to return normal responses (indicating it attempted all actions) or if it starts failing (e.g., returning 429 Too Many Requests or slowing down). This test can reveal whether there are application-level protections like quotas (e.g., “no more than five emails per user per minute”) or if an attacker could potentially overload background processes by sheer repetition.

Dosfiner Major flags

• -g / -p – GET or POST mode,
• -u <URL> – the target,
• -t <threads> – concurrency,
• -r <file> – raw request from a file,
• -proxy <host:port> – run traffic through a proxy,
• -d <data> – body for POST,
• –force-ssl – forcibly use HTTPS even if the original request was HTTP.

Considering the above, using Dosfiner involves selecting appropriate flags depending on the testing scenario. For example, to simulate a DoS attack with a GET request on a public endpoint, it is enough to use the -g flag, the -u parameter to set the target URL, and a high number of threads via the -t flag.

To test the resilience of POST endpoints, you would use the -p flag, include the request body with the -d parameter and similarly increase the number of threads with -t. In both cases, the Invoker extension significantly simplifies this process. After selecting a specific HTTP request in Burp (e.g., from the Proxy history or Repeater tab) and invoking Invoker → Dosfiner, the tool automatically fills in all necessary flags and values.

Thus, a pentester can quickly verify if a particular endpoint might cause server overload or application crashes under heavy load.

When using Dosfiner, it is essential to proceed cautiously—ideally in a non-production, controlled environment. The generated traffic can be intense and potentially result in a real denial-of-service scenario. However, in a controlled environment (e.g., a test environment approved by the application owner), Dosfiner becomes a valuable tool for discovering performance bottlenecks and potential DoS vulnerabilities.

Why Go/Rust Applications Execute Requests Faster Than Turbo Intruder

Although Turbo Intruder is implemented in Kotlin, which runs on the JVM (Java Virtual Machine), applications written in Go or Rust still offer performance advantages in sending HTTP requests. Below are the key reasons why dosfiner.go (written in Go), or a Rust-based alternative would be faster than Turbo Intruder for high-speed HTTP request execution.

Native Compilation vs. JVM Overhead

• Go and Rust are compiled directly to native machine code, eliminating the need for a runtime interpreter.
• Turbo Intruder (Kotlin on JVM) runs inside the Java Virtual Machine, which introduces:
  • Additional memory overhead.
  • Garbage Collection (GC) pauses, causing unpredictable execution slowdowns.
  • JIT compilation overhead (though it improves execution over time, it adds delays in startup and warm-up phases).

Go/Rust applications execute instantly and optimize CPU usage more efficiently than JVM-based applications.

Concurrency & Parallelism

• Go natively supports goroutines, allowing thousands of concurrent requests with minimal system overhead.
• Rust uses async/await with highly optimized event loops and memory-safe threading.
• Turbo Intruder (JVM-based) has multithreading support, but:
  • Context switching overhead is higher compared to Go/Rust.
  • Garbage Collection stalls can pause execution at unpredictable moments.

Go/Rust applications handle parallel connections more efficiently, making them ideal for high-speed HTTP flooding or brute-force attacks.

Memory & Resource Efficiency

• Go’s goroutines require only a few KB of memory per thread, whereas JVM threads consume much more RAM per thread.
• Rust does not have a garbage collector, making memory usage even more predictable.
• Turbo Intruder (JVM-based) needs significantly more memory to manage high request concurrency.

Lower memory usage = More requests sent simultaneously without performance drops.

Low-Level Network Optimizations

• Go’s built-in net/http library is optimized for high-performance networking, with direct system calls to the OS.
• Rust’s hyperlibrary is one of the fastest HTTP clients available.
• Turbo Intruder relies on JVM’s networking stack, which introduces extra layers of abstraction.

Go and Rust tools communicate with the OS more efficiently, allowing for lower-latency HTTP requests.

Protective mechanisms against DoS attacks

Rate Limiting

One of the simplest and most widespread DoS protections is to limit the rate of incoming requests. By capping how many requests a single client can make in a given timeframe, the server can prevent a single source from flooding it. For example, an API might allow 100 requests per minute per IP address – beyond that. It will start rejecting requests with HTTP 429 Too Many Requests.

This technique is very effective against basic flood attacks. It is often implemented at the web server or load balancer level (for instance, Nginx’s limit_req_zone directive can enforce a limit and even delay or drop excess requests ). Proper rate limiting mimics human behavior thresholds, so legitimate users typically will not hit the limit, while automated floods will.

From a tester’s perspective, if you notice responses like 429 or see headers like Retry-After, it is a sign the system has throttling in place. That means a blunt-force flooding will be quickly neutralized. To test DoS under these conditions, you might need to use multiple source IPs (simulating a distributed attack DDoS). Rate limiting is a good thing to highlight in reports as a defense; if absent, call that out as a risk.

Web Application Firewalls (WAFs)

A WAF operates at the application layer (HTTP/HTTPS), analyzing traffic for malicious patterns. In the context of DoS, advanced WAFs can detect and block known DoS attack behaviors. For instance, a WAF might notice a client making an abnormal number of requests or trying to keep connections open and preemptively block that client.

WAFs often come with rules or modules to mitigate DoS – for example, mod_security (an open-source WAF) has rules to detect Slowloris attacks by monitoring for incomplete HTTP headers. Cloud-based WAF services (like Cloudflare and AWS WAF) allow you to set rate-based rules (e.g., no more than X requests from an IP in Y seconds) and identify and challenge bots. Some WAFs use reputation and behavioral analytics, comparing traffic patterns to known-good baselines.

If an attack is distributed, WAFs might also use techniques like JavaScript challenges or CAPTCHAs to ensure the traffic comes from real browsers (which automated tools typically will not solve). For a pentester, encountering a WAF means your automated tests might suddenly fail or get blocked.

It is common to see WAF block pages (like a Cloudflare challenge page) instead of the intended application response when you push too hard. How to deal with WAFs? If it is in scope, you might try to find ways around it (for example, some WAFs can be bypassed by certain parameter obfuscation or splitting the attack across multiple sessions).

However, since DoS testing is not about sneaking one malicious request past (as in an XSS or SQLi) but volume, typically, the strategy is to inform the client that the WAF is activated and perhaps test its effectiveness rather than bypass it.

Sometimes, clients disable or whitelist the tester’s IP on the WAF to allow full-load testing. Otherwise, any findings will likely note that “WAF blocked our high-rate tests, indicating the presence of protection.”

Traffic Monitoring and Anomaly Detection

Even without a sophisticated WAF, many organizations monitor their servers and network for unusual activity. Intrusion Detection/Prevention Systems (IDS/IPS) might pick up on DoS patterns (like a spike in ICMP traffic for a network DoS or a flood of HTTP hits).

System administrators often have dashboards showing requests per minute, error rates, etc. A sudden surge in 5xx errors or latency can trigger alerts. Log analysis tools can flag an IP hitting an endpoint far more than usual.

Some setups might have automated responses – for instance, an IPS that adds a temporary firewall block for an IP that makes too many connections quickly. As a tester, you might observe this as the server suddenly becoming completely unresponsive to your requests (because you got firewalled) rather than just returning 429 or similar.

If you suspect such measures, you can test from a different IP or wait to see if the ban lifts after a while. A well-monitored system might also have humans in the loop – e.g., admins seeing your attack in real-time and manually intervening (by restarting services or blocking IPs). It is important in a real engagement to coordinate DoS testing carefully to avoid panic; ideally, the defenders know it is coming or at least can quickly be informed if they see it in logs.

In terms of bypassing logging – you generally cannot avoid leaving a trace with DoS; by its very nature, it is noisy. But you might attempt to send traffic patterns that do not look like an attack at first glance. For example, instead of one IP sending 1000 requests, 10 IPs should be sent 100 requests each (which might appear normal if those IPs match typical user geographies). This veers into Red Team territory (trying to evade notice), but it is good to be aware of.

Application-level Constraints

Many applications implement their own safeguards: e.g., only allow one intensive operation at a time per user, or require a valid CSRF token for certain actions which might slow down an automated attack. Captchas on forms (like login or signup) are also a protection against scripted abuse that can double as DoS mitigation (it is hard to flood signups if each requires solving a captcha).

Another mechanism is to offload heavy tasks to background jobs – for example, instead of making the user wait while an email is sent, the app quickly queues the email and immediately responds. This can make a direct DoS harder, because spamming the request just piles up jobs which might be processed at a controlled rate by a worker system. That worker system might have its own overflow controls (drop jobs if too many, etc.).

From the tester’s perspective, if you see things like captchas or notice background job behavior (like responses come back fast, but the action happens with a delay), note these design elements. They often indicate that conscious design is needed to reduce DoS impact. To “bypass” those, one would have to solve captchas either (not realistic to do at scale without AI/ML help) or overwhelm the background queue (which might require a different approach, like consuming all available job slots.

Other Mechanisms

In addition to the above, numerous other techniques exist to protect against DoS attacks. These include application-level restrictions (such as limiting the number of operations per user per minute or limiting request size—rejecting requests with payloads like 50 MB without processing them), as well as mechanisms within operating systems and servers (such as TCP backlog limits, where servers accept only a certain number of half-open connections simultaneously, making Slowloris attacks difficult).

Additionally, distributed architectures provide strong defenses. Large-scale internet services (like Google or Amazon) often use global traffic distribution networks (Anycast), which disperse attacks across many edge servers before reaching the main infrastructure. An attacker would need to overwhelm an entire global network, which is exceedingly challenging.

Moreover, there are dedicated traffic-scrubbing centers—services offered by DDoS protection companies like Cloudflare and Akamai—that intercept client traffic during an attack, filter it externally, and forward only clean traffic. Such mechanisms can neutralize attacks reaching millions of requests per second. For example, in 2022, Google Cloud Armor mitigated the largest recorded application-layer attack, peaking at 46 million HTTP requests per second. This demonstrates that the biggest players have enormous defensive capabilities. In contrast, a typical unprotected HTTP server may struggle with just a few hundred requests per second and certainly with several thousand.

Using Invoker in Burp Suite

Repeater (single request)

• In Repeater, pick the request → Right-click → Invoker Extension → choose a tool (like “dosfiner auto GET/POST” or custom one).
• Invoker automatically fills out the placeholders ({{URL}}, {{BODY}}, etc.).
• The generated command is copied to the clipboard, so you can paste it into your terminal.

Generated command copied to the clipboard:

go run dosfiner.go -g -u "http://myhost:80/cities" -d ""  -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=mySessionCookie" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -t 999 -proxy "http://127.0.0.1:8080"Code language: JavaScript (javascript)

Targets (bulk generation)

• In the Target tab, select multiple requests → Right-click → Invoker → choose a tool (e.g. “nuclei normal”).
• Invoker then creates a .sh file with one command line per selected request.
• The path to the .sh file is copied to the clipboard. You can run that script to sequentially run all generated commands.

Content of created .sh file:

Set as Authenticated Request

• Mark one request (e.g., from Repeater or Proxy History) as “authenticated,” capturing its session cookies or tokens.
• All subsequently generated commands will incorporate those headers, enabling authenticated scanning with other tools.

This will create a .sh file in your global_raw_directory with the following content. Note that cookies and headers have been replaced with those included in the authenticated request.

ffuf -u "http://myhost:80//FUZZ" -w /path/to/wordlist.txt -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=MyNewSuperSecretSession" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -mc 200,403 
ffuf -u "http://myhost:80/FUZZ" -w /path/to/wordlist.txt -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=MyNewSuperSecretSession" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -mc 200,403 
ffuf -u "http://myhost:80/afine/FUZZ" -w /path/to/wordlist.txt -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=MyNewSuperSecretSession" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -mc 200,403 
ffuf -u "http://myhost:80/folder/FUZZ" -w /path/to/wordlist.txt -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=MyNewSuperSecretSession" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -mc 200,403 
ffuf -u "http://myhost:80/js/FUZZ" -w /path/to/wordlist.txt -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=MyNewSuperSecretSession" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -mc 200,403 
ffuf -u "http://myhost:80/test/FUZZ" -w /path/to/wordlist.txt -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=MyNewSuperSecretSession" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -mc 200,403 Code language: JavaScript (javascript)

Troubleshooting

Invoker’s default configuration is designed for Linux and macOS systems. If you are using Windows, you must update the global_raw_folder path in your InvokerConfig.json to a writable directory. Additionally, remember that running external pentesting tools may require specifying the full executable paths, including extensions—for example

C:\\tools\\nuclei.exeCode language: CSS (css)

Conclusion

The Invoker Burp Extension is a powerful addition to a pentester’s arsenal, integrating Burp Suite seamlessly with numerous external offensive security tools. It saves valuable time during testing—rather than manually copying parameters into the console. It generates accurate commands with a single click. This allows pentesters to focus more on interpreting results and creatively discovering vulnerabilities, rather than performing repetitive manual tasks. The extension excels both in individual, complex cases (such as SQL injection tests requiring multiple headers and cookies) and in bulk scanning multiple endpoints simultaneously.

Invoker’s configuration, based on a JSON file, is transparent and easily customizable—new tools can be added, and the syntax of flags can be adjusted to personal preferences. The placeholders offer great flexibility in passing HTTP request elements to external tools. This article focused on Dosfiner, sqlmap, and Nuclei, but nothing prevents Invoker from supporting any other CLI-based tool useful in pentesting (including custom scripts, nmap, nikto, wfuzz, etc.).

In summary, Invoker automates tedious tasks and integrates various stages of penetration testing under the unified interface of Burp Suite. The conclusions drawn from using this extension are unequivocally positive: it increases work efficiency, reduces the risk of errors (such as missing headers or typos in URLs), and encourages more frequent use of specialized tools by significantly simplifying their execution. For security professionals regularly performing advanced penetration tests, Invoker can quickly become an indispensable element of the Burp Suite environment. It’s worth trying out in your next pentesting project—you’ll likely find it difficult to revert to the manual approach after your first few uses.