Running sqlmap Through Tor and Proxychains (Without Leaking)

There are exactly three reasons to run sqlmap through Tor:

1. The engagement contract explicitly requires source-IP rotation (rare).
2. You are testing your own infrastructure from an unfamiliar network and do not want to whitelist a residential IP.
3. The engagement requires you to test from a different geography to validate region-based controls.

There is exactly one reason to think you need it but actually do not: thinking that running through Tor makes the work "legal". Anonymity does not change the authorisation question. If you do not have permission to test, do not test.

Assuming a real reason, this is how to make sqlmap route through Tor without leaking, with verification at each step. Same general approach applies to other anonymity tooling (commercial residential proxies, VPN chaining) but Tor is the default and the most-confused setup.

Why this is more fragile than it looks

Three things commonly break the anonymity assumption:

1. DNS leaks. Tools that resolve hostnames locally then send the IP through the proxy reveal which targets you are looking at to whoever runs your DNS resolver (often your ISP). Tor's SOCKS5 protocol supports remote DNS resolution; SOCKS4 does not. Mixing them silently leaks.
2. WebRTC and other side channels. Not relevant for sqlmap (no browser), but relevant if you are mixing sqlmap with a manual Burp workflow in the same session.
3. Rate limiting and exit-node reuse. Tor's exit-node pool is finite. Aggressive sqlmap scans get the current exit IP blacklisted within minutes, often by the target's WAF. You then look like a Tor user to the target (worse signal than "an IP I do not recognise") and lose anonymity benefit.

We solve each of these explicitly.

Method 1: sqlmap's native --tor flag

This is the cleanest path for sqlmap specifically. It routes through Tor's SOCKS proxy and does DNS resolution remotely.

Prereq: a working Tor daemon running locally. On Debian/Ubuntu:

sudo apt install tor
sudo systemctl start tor
sudo systemctl enable tor

Tor listens on 127.0.0.1:9050 (SOCKS5) by default. Verify:

ss -ltnp | grep 9050

Run sqlmap through it:

sqlmap -r req.txt --batch \
       --tor \
       --tor-type=SOCKS5 \
       --tor-port=9050 \
       --check-tor \
       --random-agent \
       --delay=3 \
       --threads=1 \
       --timeout=60

The flags do specific work:

• --tor turns on Tor routing.
• --tor-type=SOCKS5 is critical. SOCKS5 supports remote DNS resolution; SOCKS4 leaks DNS to your local resolver. Default has been SOCKS5 in recent sqlmap but always set it explicitly.
• --tor-port=9050 is the default Tor SOCKS port. Set explicitly so you notice if a config file overrides it.
• --check-tor is the most important flag in this list. sqlmap probes https://check.torproject.org/api/ip (or a similar checker) before testing and confirms the traffic is actually exiting through Tor. Without this, a misconfigured proxy can route through your real IP and you will never know.
• --random-agent because Tor exit nodes are signatured AND sqlmap's UA is signatured. Stacking both makes you trivially identifiable.
• --delay=3 because Tor exits are slow and shared. Without delay you exhaust the circuit.
• --threads=1 because parallel requests through a single Tor circuit either fail or get the circuit rebuilt mid-scan, which can change exit IP and confuse the target's response logic.
• --timeout=60 because Tor latency is high and variable.

If --check-tor reports your traffic is NOT going through Tor, stop. The Tor daemon is not running, the SOCKS port is wrong, your firewall is intercepting, or your Tor build does not support the configuration you assumed. Do not bypass this check.

Method 2: proxychains-ng wrapper

When you want to chain through Tor (or any SOCKS/HTTP proxy) and sqlmap's native flag is not flexible enough, proxychains-ng (the maintained fork; the original proxychains is unmaintained) wraps any binary's TCP connections through a proxy chain.

Install:

sudo apt install proxychains4
# or build proxychains-ng from source for the latest

Configuration in /etc/proxychains4.conf (or per-user ~/.proxychains/proxychains.conf):

strict_chain
proxy_dns
remote_dns_subnet 224
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
socks5 127.0.0.1 9050

Critical lines:

• strict_chain means every proxy in the list must be reachable; refuses to silently fall through.
• proxy_dns causes proxychains to resolve hostnames remotely through the proxy chain instead of locally. This is the DNS-leak fix.
• remote_dns_subnet 224 reserves the 224.x.x.x range for remote-resolved hostname aliases.
• socks5 127.0.0.1 9050 is the Tor SOCKS endpoint. Use socks5 not socks4.

Run sqlmap under it:

proxychains4 -q sqlmap -r req.txt --batch \
       --random-agent \
       --delay=3 \
       --threads=1 \
       --timeout=60

-q is quiet mode (no proxychains debug output mixed into sqlmap's output). Drop it the first time you run to verify each connection is taking the expected path.

Note: when using proxychains, do not also pass --tor to sqlmap. The two routings will fight: sqlmap will try to wrap Tor over a connection proxychains is already trying to wrap, and you get either a broken connection or a circuit-of-circuits that leaks in unpredictable ways.

Verification: confirm your traffic is anonymised

Before any testing, verify. Do not skip this. The verification step has caught misconfiguration in something like a third of the times I have set this up on a new machine.

Run a curl probe through the same routing sqlmap will use:

# Through Tor's SOCKS proxy directly:
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

# Through proxychains:
proxychains4 -q curl https://api.ipify.org

For Tor, expect a JSON response with "IsTor": true and an IP that is not your real one. Cross-reference the IP against the Tor exit-node list (e.g., https://check.torproject.org/torbulkexitlist) to confirm it is a known exit.

For proxychains, expect an IP that is not your real one. To cross-verify DNS:

proxychains4 -q curl https://dnsleaktest.com/

The IPs reported as your DNS resolvers should be Tor-related (or your proxy provider's), not your ISP's. If they are your ISP's, proxy_dns is not effective; recheck the config.

If verification fails, stop and fix. Running a scan and discovering afterwards that you were on your real IP is the second-worst outcome (worst is being on your real IP and realising mid-scan because you ignored the verification step).

Rate-limit reality

Tor exits are slow. A scan that takes ten minutes from your home connection can take an hour through Tor, sometimes longer. The realistic settings:

• --threads=1. Higher concurrency through a single circuit usually fails.
• --delay=3 to --delay=10. Higher delays trade scan time for circuit longevity.
• --timeout=60 to --timeout=120. Tor latency spikes are normal.

Boolean-blind extractions are particularly painful through Tor. A four-thousand-byte dump through binary-search is sixteen thousand requests, each one delayed and routed through three hops. Plan accordingly.

If sqlmap reports many timeouts or connection errors, the circuit has aged out or the exit is blacklisted. Force a new circuit:

# With Tor's control port enabled (configure in /etc/tor/torrc):
echo -e 'AUTHENTICATE\nSIGNAL NEWNYM\nQUIT' | nc 127.0.0.1 9051

This rotates the exit IP. Restart sqlmap with --fresh-queries and continue.

Adding a VPN layer

Some engagements require traffic to look like a specific geography or to add an extra layer between you and the Tor entry guard. The setup is:

sqlmap → SOCKS5 (Tor) → entry guard → middle → exit → target

or

sqlmap → VPN tunnel → SOCKS5 (Tor) → entry guard → middle → exit → target

The VPN-then-Tor order matters. VPN first means your ISP sees only VPN traffic (good). Tor entry guard sees the VPN exit (not your home IP, also good). The target sees the Tor exit (no change). The VPN provider sees your real IP and that you are using Tor (trust trade-off).

The reverse order (Tor first, then VPN at the exit) reintroduces the VPN provider as a single point of identifiability and is usually wrong. Some commercial providers market "Tor over VPN" and "VPN over Tor"; what they mean is rarely well-documented. Read the specifics before adopting either.

When not to use Tor with sqlmap

Several common cases where Tor is the wrong tool:

• Testing a target that blocks Tor exits. Many sites have hard blocks on Tor exits (Cloudflare's default for high-risk paths, AWS WAF rules, target-specific block lists). Your scan will return uniformly 403 and you will think the target is hardened when in fact you are not reaching it.
• Testing a target you have whitelisted yourself from. If your engagement has a source-IP allow-list, running through Tor defeats it. Use your own IP.
• Out-of-band exploitation paths. The OOB listener (Burp Collaborator, a DNS server you control) needs to receive callbacks. Tor exits cannot initiate inbound; the target's database connecting back to you cannot reach a Tor hidden service in any practical way.
• Engagements with explicit "test from this IP" requirements in the scope document. Tor breaks the audit trail.

Use Tor when the threat model includes anonymity from the target itself (rare in pentests; common in red team and adversary simulation) or when source-IP rotation is genuinely required. Otherwise, scan from a known, agreed source.

A practical checklist

Before you run a scan through Tor, walk this list:

1. Tor daemon is running and the SOCKS port is bound (ss -ltnp | grep 9050).
2. curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip returns IsTor: true.
3. The exit IP shown by the check is not blacklisted by the target. Quick check: curl --socks5-hostname 127.0.0.1:9050 https://target.example/ returns a non-403.
4. sqlmap command includes --check-tor, --random-agent, --delay, --threads=1, --timeout=60.
5. If using proxychains: proxy_dns is set and verified leak-free against dnsleaktest.
6. Engagement scope allows source-IP rotation.

If any one is no, fix or do not run.

Where to go next

• The sqlmap cheat sheet for the full flag reference.
• The sqlmap evasion and anti-detection guide for the WAF-bypass side of opsec (often more useful than Tor for the actual scan).
• The sqlmap tutorial against a vulnerable app for the baseline workflow without anonymisation.
• The SQL injection deep dive for the underlying mechanics.