Skip to main content

​
Overview

HTTP Flood is a volumetric Layer 7 (application layer) attack method that sends a high volume of HTTP GET and POST requests to overwhelm a target web server or application. This attack aims to exhaust server resources by flooding it with seemingly legitimate HTTP traffic.
This attack method uses random payloads and rotates between GET and POST requests to simulate realistic traffic patterns.

​
How it works

The HTTP Flood attack operates by:
  1. Request Generation: Creates HTTP requests with random payloads based on the configured packet size
  2. Method Selection: Automatically chooses between GET and POST requests
    • Packets ≤ 512 bytes: 50% chance of GET or POST
    • Packets > 512 bytes: Always POST (more efficient for large payloads)
  3. GET Requests: Appends random payload to URL path (/randomstring)
  4. POST Requests: Sends random payload in request body
  5. Connection Handling: Creates a new HTTP client for each request with 5-second timeout and 3 retries
  6. Proxy Rotation: Randomly selects from available proxies for each request
  7. User-Agent Rotation: Applies random user agents if configured

​
When to use

HTTP Flood is effective for:
  • Web application stress testing: Testing how your web server handles high traffic volumes
  • CDN bypass attempts: Since it uses legitimate HTTP traffic, some CDNs may pass it through
  • Application-layer resilience: Testing application logic under load
  • Server capacity testing: Determining maximum concurrent request handling
This attack generates high volumes of HTTP traffic. Only use against targets you own or have explicit permission to test.

​
Usage

Basic HTTP Flood attack: 
mmb attack http_flood https://example.com
With custom parameters: 
mmb attack http_flood https://example.com \
  --duration 120 \
  --delay 200 \
  --packet-size 1024 \
  --threads 8 \
  --verbose

​
Parameters

​
target
string
required
Target URL including protocol (http:// or https://)
​
--duration
int
default:"60"
Attack duration in seconds
​
--delay
int
default:"500"
Delay between packets in milliseconds per thread
​
--packet-size
int
default:"512"
Size of random payload in bytes. Affects GET/POST method selection.
​
--threads
int
default:"0"
Number of concurrent threads (0 = number of CPU cores)
​
--verbose
boolean
default:"false"
Show detailed attack logs including proxy usage per request
​
--no-proxy
boolean
default:"false"
Allow running without proxies (not recommended for production targets)

​
Expected behavior

​
Console output

Standard mode: 
Starting http_flood against https://example.com with 150 proxies
21:45:01 PPS:245 Total:245 Proxies:150
21:45:02 PPS:312 Total:557 Proxies:150
21:45:03 PPS:298 Total:855 Proxies:150
Verbose mode: 
Starting http_flood against https://example.com with 150 proxies
Verbose mode enabled - showing detailed attack logs
21:45:01 PPS:245 Total:245 Proxies:150 [SOCKS5 proxy.example.com:1080 -> https://example.com]
21:45:02 PPS:312 Total:557 Proxies:150 [HTTP proxy2.example.com:8080 -> https://example.com]

​
Network behavior

  • Connections: New TCP connection per request (no keep-alive)
  • Request distribution: ~50% GET, ~50% POST for small packets; mostly POST for large packets
  • Payload: Random alphanumeric strings
  • Timeout: 5 seconds per request
  • Retries: Up to 3 attempts per request

​
Technical implementation

Implementation details from internal/attacks/http/flood.go:20-52:
  • Uses net/http standard library for HTTP requests
  • Generates random payloads using randomString() helper
  • Discards response bodies to minimize memory usage
  • Reports success only when response is received (status code ignored)
  • Integrates with engine’s proxy rotation and statistics collection

​
Performance considerations

  • Reduce --delay for higher packets per second
  • Increase --threads to utilize more CPU cores
  • Use smaller --packet-size for faster request generation
  • Ensure sufficient proxy pool to avoid rate limiting
  • Each thread maintains a ticker for packet timing
  • HTTP clients are created per request (not pooled)
  • Memory usage scales with thread count and active connections
  • CPU usage depends on payload generation and TLS handshakes
  • More proxies = better distribution and harder to block
  • SOCKS5 proxies typically faster than HTTP proxies
  • Proxy health affects success rate
  • Configure proxies in your proxies.txt file

HTTP Bypass

Stealth HTTP attack with browser-like behavior

HTTP Slowloris

Slow HTTP attack that keeps connections open

TCP Flood

Layer 4 TCP connection flood

Build docs developers (and LLMs) love

Get started for freeTalk to us