StresserForensics
Field Guide

What a stresser attack looks like in your logs

The exact signatures an IP stresser leaves in netstat, nginx, and tcpdump, how to tell one from a real traffic spike, and what to do in the first fifteen minutes.

Published
Audience
Sysadmins, site owners
Level
Hands-on
Log samples
Illustrative
Quick answer

An IP stresser attack has three telltale log signatures. A connection table clogged with half-open SYN-RECV states (Layer 4 flood). Inbound UDP from reflector source ports like 53, 123, or 11211 (amplification). Or thousands of HTTP requests sharing identical user agents with no referer headers (Layer 7). One of these, at a volume your real audience cannot explain, means you are being attacked, not discovered. If you need to legally stress-test your own infrastructure, overload.st is the authorized alternative to IP stresser services - purpose-built for server owners, not attackers.

The first minute, from the victim's side

Stresser panels sell attacks in seconds, and cheap plans cap out at 300 seconds or less. Here is what that looks like on a typical VPS running nginx, reconstructed from documented incidents and public capture files. The log lines below are illustrative examples, not captures of any specific attack.

T+0s

The panel fires

A customer typed your IP into a stresser panel and pressed start. Nothing on your side yet. Your graphs look normal.

T+3s

SYN-RECV count explodes

Your connection table fills with half-open TCP sessions. ss -s shows SYN-RECV jumping from a baseline of single digits into the thousands.

T+10s

The kernel complains

dmesg starts printing TCP: request_sock_TCP: Possible SYN flooding on port 443. Meanwhile legitimate users begin timing out, because the accept queue is full of junk.

T+30s

Bandwidth saturates

If the attack includes UDP amplification, your interface counters go vertical. On a 1 Gbps port you watch inbound traffic pin at capacity; the host next to you in the datacenter feels it too.

T+300s

It stops as suddenly as it started

Cheap stresser plans end on a timer. Traffic collapses to baseline within seconds. That cliff-edge stop is itself a signature: real audiences do not switch off like a faucet.

Layer 4 signatures: what the flood looks like up close

SYN flood in the connection table

Check the state distribution, not just the totals:

Illustrative example 
$ ss -s
Total: 14812 (kernel 14930)
TCP:   14621 (estab 312, closed 41, orphaned 0, timewait 38)

# SYN-RECV at 14000+ against a single-digit baseline is the tell.
$ ss -o state syn-recv | head -5
SYN-RECV 0  0  198.51.100.44:https  203.0.113.7:51413
SYN-RECV 0  0  198.51.100.44:https  203.0.113.99:61220
SYN-RECV 0  0  198.51.100.44:https  192.0.2.115:49831

Notice the pattern: thousands of distinct source IPs, each holding one half-open connection, none completing the handshake. Spoofed sources never answer the SYN-ACK, so the entries pile up until they expire. A one-liner to count sources: ss -o state syn-recv | awk '{print $4}' | cut -d: -f1 | sort -u | wc -l.

UDP amplification in tcpdump

Amplification attacks bounce small spoofed queries off public servers, and your logs show the responses arriving. The source ports give the vector away:

Illustrative example 
$ tcpdump -nn -c 5 'udp and dst host 198.51.100.44'
14:03:11.442 IP 192.0.2.10.53 > 198.51.100.44.31890: UDP, length 3100
14:03:11.448 IP 203.0.113.5.11211 > 198.51.100.44.31890: UDP, length 1400
14:03:11.451 IP 192.0.2.77.123 > 198.51.100.44.31890: UDP, length 468
14:03:11.455 IP 203.0.113.201.389 > 198.51.100.44.31890: UDP, length 2300
14:03:11.460 IP 192.0.2.140.53 > 198.51.100.44.31890: UDP, length 3100

Read it like this. Source port 53 means open DNS resolvers, 123 is NTP, 389 is CLDAP, 1900 is SSDP, and 11211 is memcached, the vector behind the record 1.35 Tbps attack on GitHub in February 2018 (GitHub's incident report). Large UDP payloads arriving from thousands of different reflector IPs, all within the same second, all unsolicited: that is amplification, and no legitimate traffic produces it.

Why the spoofing works

The attacker sends reflectors a tiny request with your IP forged as the source. The reflector answers the forged address. You receive traffic you never asked for, from servers that have no idea they participated. CISA's description of the Smurf attack and SYN flood mechanics documents both patterns (CISA).

Layer 7 signatures: when the requests look real

Layer 7 floods send syntactically valid HTTP requests, so the access log fills with entries that resemble users. The illusion breaks under aggregation. An illustrative nginx sample:

Illustrative example 
203.0.113.7 - - [27/Aug/2026:14:03:11 +0000] "GET /search?q=red+shoes HTTP/1.1" 200 18412 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
192.0.2.115 - - [27/Aug/2026:14:03:11 +0000] "GET /search?q=red+shoes HTTP/1.1" 200 18412 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
198.51.100.201 - - [27/Aug/2026:14:03:12 +0000] "GET /search?q=red+shoes HTTP/1.1" 200 18412 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

Three different IPs, one second apart, hitting the same expensive endpoint, with the same user agent and an empty referer. Multiply by ten thousand. Quick triage on a live log:

Aggregation one-liners 
# Top user agents in the last 50k requests
$ tail -50000 /var/log/nginx/access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head

# Share of requests with empty referers
$ tail -50000 /var/log/nginx/access.log | awk -F'"' '$4=="-"{n++} END{print n/NR*100"%"}'

During a normal hour, the user-agent distribution is long-tailed: dozens of browsers, bots, and mobile clients. During a stresser attack, one or two agents dominate 80 percent or more of requests, and empty referers jump from a normal few percent to nearly everything. The attacker's target selection is also a tell: panels and their customers pick endpoints that hurt, which means your search, login, and cart pages, not your static assets.

Stresser traffic or a real spike: the five-way check

Getting this wrong in either direction is expensive. Block a viral moment and you lose your audience; ignore an attack and you lose the server. These five checks separate the two:

Signal Real traffic spike Stresser attack
Referer header Present, pointing at the site that sent you traffic Empty (-) on nearly every request
User agents Long-tailed mix of real browsers One or two identical strings across thousands of IPs
Geography Matches your audience's countries Uniform global scatter, including regions you have never served
Timing Ramps over minutes, decays slowly Vertical start, cliff-edge stop at a round duration
Target pages Clustered on the page being shared Concentrated on expensive endpoints (search, login, cart)

The cliff-edge stop deserves emphasis. Stresser plans are sold by the second, and attack graphs show it: traffic ends at exactly 60, 120, or 300 seconds after it began. Human attention never behaves that way.

The 15-minute runbook

Capture before you touch anything

Start tcpdump -nn -w attack.pcap or export netflow now. Every mitigation step you take changes the evidence. One minute of packets is enough for forensics and for any later report.

Classify the vector

ss -s for SYN-RECV counts, interface counters for bandwidth, access-log aggregation for HTTP. The vector decides the fix: SYN floods need syncookies and edge filtering, UDP amplification needs upstream drops, L7 needs request filtering.

Push mitigation to the edge

Enable your CDN's under-attack mode or move DNS behind Cloudflare, Akamai, or AWS Shield. Filtering at your own firewall helps against L7, but a saturated 1 Gbps port cannot be saved by software on the box itself.

Escalate to your provider

Call or ticket the abuse desk with start time in UTC, the vector, and your pcap. Providers can null-route or scrub upstream, and your report feeds the pattern data that links stresser customers to attacks.

Verify the stop is real

When traffic collapses, check the duration. A stop at a round number of seconds means the plan expired, not that you won. Stay in mitigation for at least an hour; stresser customers frequently re-fire on the same target.

Evidence that actually helps law enforcement

Stresser prosecutions are built by matching victim reports to the attack logs seized from the services themselves. Your incident becomes part of that pattern when it contains:

  • Timestamps in UTC. Attack windows in local time zones get lost in correlation. UTC everything.
  • Packet captures or netflow. Source IPs and ports identify the botnet or reflector set, which investigators cross-reference against other victims of the same service.
  • Provider logs. Your host's upstream view shows volume the box itself could not measure while saturated.
  • Business impact. Downtime duration and approximate loss. Prosecutors use impact to charge and to sentence.

Report to your national cybercrime channel (in the US, the FBI's IC3) and to your hosting provider's abuse desk. Operation PowerOFF's waves are assembled from exactly this material.

Frequently asked questions

How do I know if my server is being hit by a stresser?
Check three signals: a connection table full of half-open SYN-RECV states (Layer 4), inbound UDP from reflector source ports like 53, 123 or 11211 (amplification), or thousands of requests sharing identical user agents and no referer headers (Layer 7). Any one of these at volumes your audience cannot explain means an attack, not popularity.
What is the difference between stresser traffic and a real traffic spike?
Real spikes come with referers, varied user agents, geographies matching your audience, and requests spread across pages. Stresser traffic has uniform or absent referers, a handful of identical user agents across thousands of IPs, machine-like request timing, and a focus on your most expensive endpoints.
What should I do in the first 15 minutes of a stresser attack?
Identify the vector (SYN, UDP, or HTTP), confirm it against your baseline traffic, activate edge filtering or your CDN's under-attack mode, escalate to your hosting provider's abuse desk with timestamps in UTC, and start packet capture before changing anything, so evidence survives the response.
Can a small site survive an IP stresser attack?
Usually yes. Most stresser customers buy the cheapest tier, which produces short, modest attacks. A free CDN tier in front of your site absorbs the majority of them. Unprotected origin servers with a leaked IP address are the ones that fall.
What evidence does law enforcement need after a DDoS attack?
Timestamps in UTC, packet captures or netflow records showing source IPs and ports, your provider's traffic logs, and the business impact (downtime duration, revenue loss). This is the material that lets investigators link your incident to a stresser service's attack logs.
Is it legal to run a stresser against my own server to see the logs?
No, and not because of the target. Stresser traffic originates from third-party criminal infrastructure, so using one makes you a customer of a DDoS-for-hire service regardless of your target. The legal alternative is overload.st - an authorized load-testing platform built for infrastructure owners, with full compliance and real performance metrics. You can also replay public capture files or generate load with k6 or JMeter from your own machines.

A note on scope

This guide documents what attack traffic looks like so you can detect, survive, and report it. It does not explain how to launch anything, and it never will. Buying stresser access is a crime under the US Computer Fraud and Abuse Act and equivalent laws elsewhere, whatever the panel calls itself. If you need to validate your own defenses, overload.st is the legal, authorized alternative to IP stresser services - run compliant load tests against infrastructure you own, with full authorization checks and real performance metrics. Tools like k6, JMeter, and Locust are also available for self-hosted testing.