Optimize sqlmap Scan Performance with Threads

Introduction

sqlmap is a powerful open-source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws. By default, sqlmap performs its tests sequentially, sending one request at a time. While this is reliable, it can be slow, especially on complex web applications or when performing time-based blind injection tests.

In this lab, you will learn how to significantly speed up your sqlmap scans by using the --threads option. This flag allows sqlmap to perform multiple HTTP requests concurrently, drastically reducing the overall time required to complete a scan. You will perform a series of scans with different thread counts and compare the results to see the performance improvement firsthand.

Perform a Baseline Scan with a Single Thread

In this step, you will perform a basic sqlmap scan using the default setting of a single thread. This will serve as our baseline to measure performance improvements against in the later steps. We will use the time command to accurately measure the duration of the scan.

First, execute the following command in your terminal. This command tells sqlmap to scan the provided URL (-u), enumerate the databases (--dbs), and run in non-interactive mode (--batch). We will redirect the output to a log file and also use the time command to measure the execution time.

(time sqlmap -u "http://testphp.vulnweb.com/listproducts.php?cat=1" --dbs --batch) 2>&1 | tee baseline_scan.log

After the scan completes, you will see a lot of output from sqlmap, followed by the time measurement at the very end. It will look something like this:

... (sqlmap output) ...

[22:30:00] [INFO] fetching database names
[22:30:00] [INFO] the SQL query used returns 2 entries
[22:30:00] [INFO] retrieved: information_schema
[22:30:00] [INFO] retrieved: acuart
[22:30:00] [INFO] available databases [2]:
[*] acuart
[*] information_schema

[22:30:00] [INFO] fetched data logged to text files under '/home/labex/.sqlmap/output/testphp.vulnweb.com'

[*] ending @ 22:30:00 /2023-10-27/


real    0m45.123s
user    0m5.456s
sys     0m0.789s

The most important value for us is real, which represents the total wall-clock time taken. Now, let's save this result to our comparison file, scan_times.log.

echo "Baseline (1 Thread): $(grep real baseline_scan.log | awk '{print $2}')" >> scan_times.log

Finally, view the contents of the log file to confirm the baseline time has been recorded.

cat scan_times.log

Your output should show the recorded time:

Baseline (1 Thread): 0m45.123s

Understand the Purpose of the `--threads` Flag

In this step, we will take a moment to understand the key feature of this lab: the --threads flag in sqlmap. There are no commands to execute in this step; the goal is to understand the concept before applying it.

The --threads option is used to set the number of concurrent HTTP(s) requests that sqlmap will perform during a scan. The default value is 1.

How it works: Instead of sending one request and waiting for a response before sending the next, sqlmap can open multiple "threads" to send several requests at the same time. This parallelism is especially effective for tasks that involve many requests, such as:

Fuzzing for vulnerabilities.
Brute-forcing characters in a database name (blind SQL injection).
Extracting large amounts of data.

Benefits:

Speed: The primary benefit is a significant reduction in scan time.
Efficiency: It makes better use of your network connection and system resources.

Considerations:

Resource Usage: Increasing threads will use more of your CPU and memory.
Target Stability: A very high number of threads could overwhelm a fragile or poorly configured web server, potentially causing a denial of service.
Detection: Aggressive multi-threaded scanning is more likely to be detected and blocked by Web Application Firewalls (WAFs) or Intrusion Detection/Prevention Systems (IDS/IPS).

sqlmap allows you to set the number of threads from 1 to a maximum of 10. In the next steps, you will see how adjusting this value impacts scan performance.

Re-run the Scan with an Increased Thread Count (`--threads=5`)

In this step, you will apply your knowledge of the --threads flag. Let's re-run the same scan as before, but this time we will increase the number of concurrent requests to 5.

Execute the following command in your terminal. It's identical to the first command, with the addition of --threads=5.

(time sqlmap -u "http://testphp.vulnweb.com/listproducts.php?cat=1" --dbs --batch --threads=5) 2>&1 | tee 5_threads_scan.log

Once the scan is complete, you should notice that the real time is significantly lower than the baseline scan.

Now, let's append this new result to our scan_times.log file for comparison.

echo "5 Threads: $(grep real 5_threads_scan.log | awk '{print $2}')" >> scan_times.log

Let's check the contents of the log file again to see both results.

cat scan_times.log

The output will now show both the baseline and the 5-thread scan times.

Baseline (1 Thread): 0m45.123s
5 Threads: 0m15.456s

(Note: Your times will vary, but you should see a noticeable decrease.)

Re-run the Scan with the Maximum Thread Count (`--threads=10`)

In this step, you will push the performance to the limit by using the maximum number of threads allowed by sqlmap, which is 10. This will demonstrate the peak performance gain you can achieve with this option under normal conditions.

Execute the scan command one last time, setting the thread count to 10.

(time sqlmap -u "http://testphp.vulnweb.com/listproducts.php?cat=1" --dbs --batch --threads=10) 2>&1 | tee 10_threads_scan.log

This scan should be even faster than the previous one. After it finishes, record the result in our log file.

echo "10 Threads: $(grep real 10_threads_scan.log | awk '{print $2}')" >> scan_times.log

Now, view the scan_times.log file to see all three results compiled.

cat scan_times.log

The output will now contain all three entries, making it easy to compare them in the next step.

Baseline (1 Thread): 0m45.123s
5 Threads: 0m15.456s
10 Threads: 0m9.789s

(Note: Your times will vary.)

Compare the Scan Durations and Note Performance Changes

In this final step, you will analyze the data you've collected to draw a conclusion about the effectiveness of multi-threading in sqlmap.

Let's display the final results stored in scan_times.log.

cat scan_times.log

You will see an output similar to this, clearly showing the duration of each scan:

Baseline (1 Thread): 0m45.123s
5 Threads: 0m15.456s
10 Threads: 0m9.789s

(Note: The exact times will differ based on network conditions and system load, but the trend should be clear.)

Analysis: As you can see from the results, there is a dramatic decrease in scan time as we increase the number of threads.

The jump from 1 to 5 threads likely produced the most significant performance gain.
The jump from 5 to 10 threads still shows an improvement, but it might be less pronounced. This is because factors other than the number of threads—such as network latency or the server's ability to handle concurrent requests—start to become the bottleneck.

This experiment clearly demonstrates that using the --threads flag is a simple yet highly effective way to optimize your sqlmap scans.

Summary

Congratulations on completing this lab! You have successfully learned how to optimize sqlmap scan performance using concurrent requests.

In this lab, you:

Performed a baseline scan with a single thread to establish a performance benchmark.
Learned the purpose of the --threads flag and its benefits and considerations.
Executed scans with 5 and 10 threads to observe the impact on scan duration.
Compared the results and confirmed that increasing the thread count significantly reduces scan time.

Mastering options like --threads is crucial for conducting efficient and timely penetration tests. Remember to use this power responsibly, as aggressive scanning can negatively impact the target system.

Optimize Scan Performance with Threads in sqlmap