sqlmap "connection timed out" during time-based blind test on authorized target

TL;DR

Time-based tests are slow on purpose; timeouts mean your --timeout is shorter than the sleep payload or the app kills slow queries. Raise --timeout, lower --time-sec, drop to one thread, and confirm boolean injectability first so you are not timing out on a dead parameter.

connection timed out

Use this when

• Sqlmap times out specifically during time-based blind testing.
• The target answers normal requests fine.
• The parameter showed boolean-based differences before you switched techniques.

Not for this skill when

• The first request times out. That is a connectivity problem.
• Every technique times out. The target or network is the problem, not the timing.
• The engagement forbids slow, noisy tests. Respect that and use boolean techniques.

Steps

1. Confirm boolean injectability first: sqlmap -u ... --technique=B. Verify: boolean payloads show content differences.
2. Raise the ceiling: --timeout=30 --time-sec=5 so sleep payloads fit inside the wait window. Verify: requests stop timing out.
3. Drop to a single thread: --threads=1. Concurrent time-based requests skew each other's timing. Verify: sleep timings become consistent.
4. If the app or WAF kills slow queries outright, stop forcing time-based and document the attempt. Verify: the notes record that time-based was attempted and blocked.
5. Rerun the time-based extraction with the tuned settings. Verify: character extraction progresses without timeouts.

Variant phrasings

sqlmap time based blind timeout

Compact phrasing.

sqlmap SLEEP payload times out

Payload-level phrasing.

sqlmap --time-sec timeout

Flag-oriented search.

Compatibility: sqlmap 1.x. --time-sec default is 5; --timeout default is 30 in recent builds but was lower historically.

Why it happens

A SLEEP(5) payload needs the full 5 seconds plus network overhead. If --timeout is 10 and the network adds 6, the client gives up before the answer arrives. Parallel threads make it worse by queueing the slow requests behind each other.

Edge cases / pitfalls

• Setting --time-sec too low (1-2s) creates false positives on jittery networks. Keep it at 5 unless the network is very clean.
• Some WAFs detect SLEEP/WAITFOR keywords and drop the connection. That looks like a timeout but is a block; check for it before tuning timers.
• Time-based extraction is the slowest technique. On a big table it can take hours; confirm the engagement window allows it.
• Never run time-based tests against production without explicit written approval. The load is real.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SwBmM2AG0pftGryI0xYpLA