How to Report a DDoS Attack to Your ISP: Evidence, Templates, and Escalation Steps

A DDoS (Distributed Denial-of-Service) attack floods your server or network with traffic from many sources simultaneously, overwhelming your infrastructure until legitimate users can no longer reach your services. When an attack is underway, reporting it to the responsible ISPs is one of the most effective ways to get malicious traffic shut down at the source. For a complete overview of the abuse reporting process, see my complete guide to reporting IP abuse.

In this guide, I walk through exactly how to identify a DDoS attack in your logs, collect the evidence an ISP abuse desk needs to act, and file a report that gets results rather than getting ignored.

How to Identify a DDoS Attack

Before you report anything, you need to confirm that what you are experiencing is actually a DDoS attack and not a traffic spike from legitimate users, a misconfigured monitoring bot, or a single-source DoS. Here are the indicators and commands I use to make that determination.

One important check first: if the heavy traffic is coming from a single IP or a small number of IPs, check the User-Agent string in your access logs before jumping to a DDoS conclusion. Aggressive web crawlers — SEO audit tools like Screaming Frog, or AI training bots like GPTBot and ClaudeBot — can generate thousands of requests per minute and look a lot like a denial-of-service attack. Look up the source IP with the IP Location tool to see if it belongs to a known crawling service. If it does, the fix is robots.txt or rate limiting, not an abuse report. See my guide to identifying and managing web crawlers for the full rundown.

Bandwidth and Connection Indicators

The first sign of a DDoS attack is usually one of these:

• Sudden bandwidth saturation — your network utilization jumps from normal levels to near-maximum capacity
• Connection table exhaustion — your firewall or load balancer runs out of connection tracking entries
• Service degradation without CPU cause — your application is unresponsive but CPU and memory are normal, indicating the bottleneck is network-level
• Massive spike in connections from diverse IPs — unlike a single-source DoS, DDoS traffic comes from hundreds or thousands of distinct source addresses

CLI Commands for Live Investigation

Use these commands to get a real-time picture of what is hitting your server:

# Count connections per source IP, sorted by volume
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Watch bandwidth per interface in real time
iftop -i eth0 -n

# Capture 60 seconds of traffic on port 80 for later analysis
tcpdump -i eth0 -w /tmp/ddos-capture-$(date +%Y%m%d-%H%M%S).pcap -c 100000 port 80

# Check SYN flood (half-open connections)
netstat -n | grep SYN_RECV | wc -l

# Monitor UDP traffic volume
tcpdump -i eth0 -n udp -c 1000 | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

Log Patterns That Confirm a DDoS

SYN flood (protocol attack) — thousands of half-open connections from spoofed or diverse IPs:

$ netstat -n | grep SYN_RECV | wc -l
14832

HTTP flood (application layer) — repetitive requests hitting the same endpoint:

203.0.113.45 - - [09/Apr/2025:14:22:01 +0000] "GET /api/search?q=test HTTP/1.1" 200 4521
198.51.100.78 - - [09/Apr/2025:14:22:01 +0000] "GET /api/search?q=test HTTP/1.1" 200 4521
192.0.2.201 - - [09/Apr/2025:14:22:01 +0000] "GET /api/search?q=test HTTP/1.1" 200 4521
# Thousands of identical requests from different IPs within the same second

UDP flood — massive volume of UDP packets from random ports:

$ tcpdump -i eth0 -n udp -c 10
14:22:03.445123 IP 203.0.113.12.41923 > 10.0.1.5.80: UDP, length 512
14:22:03.445124 IP 198.51.100.33.29471 > 10.0.1.5.80: UDP, length 512
14:22:03.445125 IP 192.0.2.88.55102 > 10.0.1.5.80: UDP, length 512
14:22:03.445126 IP 203.0.113.201.38291 > 10.0.1.5.80: UDP, length 512

If you see traffic coming from DNS resolvers on port 53, you may be the target of a DNS amplification attack, which exploits open resolvers to multiply attack traffic by 50-70x.

Evidence Gathering Checklist

ISP abuse desks receive hundreds of reports daily. The ones that get acted on quickly are the ones with clean, specific evidence. Before you write your report, gather the following:

• Packet captures (pcap files) — capture at least 60 seconds of attack traffic with tcpdump. This is the single most important piece of evidence because it contains source IPs, packet sizes, protocols, and timing.
• Firewall and access logs — export the relevant time window from your firewall (iptables, pf, or cloud security group logs) and web server (nginx/Apache access logs).
• NetFlow or sFlow data — if your router supports it, NetFlow records provide aggregate traffic statistics without the overhead of full packet captures.
• Bandwidth graphs — screenshots or exports from your monitoring tool (Grafana, PRTG, Cacti) showing the traffic spike with clear timestamps.
• Timestamps in UTC — normalize all timestamps to UTC. ISPs operate across time zones, and ambiguous timestamps delay investigations.
• Top source IPs — extract and list the top 20-50 source IP addresses by packet or byte count from your captures.
• Target IP and port — your public IP address and the port(s) being targeted. Use What's My IP Address if you need to confirm your public-facing IP.
• Attack duration — start time, end time (or "ongoing"), and any intermittent patterns.

Save everything with UTC timestamps in the filenames. For example: ddos-capture-20250409-142200Z.pcap.

Finding the Abuse Contact for Attacking IPs

Once you have your list of top source IPs, you need to find out which ISPs or hosting providers own them. The fastest way to do this is with the IP Location tool on this site — paste any IP address and it returns the ASN, organization, ISP name, and abuse contact information.

For bulk lookups, use the whois command:

# Look up a single IP
whois 203.0.113.45 | grep -i abuse

# Batch lookup for top offending IPs
for ip in 203.0.113.45 198.51.100.78 192.0.2.201; do
  echo "=== $ip ==="
  whois $ip | grep -iE 'abuse|orgname|netname'
done

Most WHOIS records include an OrgAbuseEmail or abuse-mailbox field. You can also check the RIPE, ARIN, APNIC, LACNIC, or AFRINIC databases directly depending on the IP range.

Group the attacking IPs by ISP. If 200 of your top source IPs belong to the same hosting provider, send one consolidated report to that provider with all 200 IPs listed. This is far more effective than sending 200 individual reports.

You can also use the Port Scanner to check if the attacking source IPs have common open ports that suggest they are compromised machines (e.g., open management ports or known-vulnerable services).

DDoS Abuse Report Email Template

Here is a template I use for reporting DDoS attacks to ISP abuse desks. Copy it, fill in the placeholders, and attach your evidence files.

Subject: DDoS Attack Report — [ATTACK_TYPE] from your network [YOUR_ASN_REFERENCE]

Dear Abuse Team,

I am reporting a DDoS attack originating from IP addresses within your
network (AS[ATTACKER_ASN] / [ISP_NAME]).

ATTACK SUMMARY
- Target IP:        [YOUR_SERVER_IP]
- Target port(s):   [TARGET_PORTS]
- Attack type:      [ATTACK_TYPE: e.g., UDP flood / SYN flood / HTTP flood]
- Start time:       [START_TIME_UTC] UTC
- End time:         [END_TIME_UTC or "Ongoing"]
- Peak bandwidth:   [PEAK_BPS, e.g., 12 Gbps]
- Peak packet rate: [PEAK_PPS, e.g., 8.5 Mpps]

SOURCE IPs FROM YOUR NETWORK
[IP_1] — [PACKET_COUNT] packets / [BYTE_COUNT] bytes
[IP_2] — [PACKET_COUNT] packets / [BYTE_COUNT] bytes
[IP_3] — [PACKET_COUNT] packets / [BYTE_COUNT] bytes
(Full list attached in CSV format)

EVIDENCE ATTACHED
1. Packet capture: ddos-capture-[TIMESTAMP].pcap (60-second sample)
2. Source IP list:  attacking-ips-[ASN].csv
3. Bandwidth graph: bandwidth-spike-[TIMESTAMP].png

The attack is causing service disruption to our infrastructure. I
request that you investigate the listed source IPs and take appropriate
action to stop the malicious traffic.

Please confirm receipt of this report and provide a reference number
for tracking.

Regards,
[YOUR_NAME]
[YOUR_ORGANIZATION]
[YOUR_EMAIL]
[YOUR_PHONE — optional]

Tips for making the template effective:

• Include hard numbers (Gbps, Mpps, packet counts). ISPs prioritize reports with quantified impact.
• Attach evidence as files rather than pasting raw logs into the email body. Pcap files are the gold standard.
• Mention your own IP and ASN so the abuse team can verify you are the actual victim.
• Keep the tone factual and professional. Angry emails get deprioritized.

Where to Report a DDoS Attack

DDoS attacks warrant reporting to multiple parties depending on severity and duration. Here is where to send your reports, in priority order:

For botnet-driven DDoS attacks where the source IPs appear to be compromised home routers or IoT devices, also see my guide on reporting malware and botnet C2 traffic.

Sub-Scenarios: Reporting by Attack Type

Different DDoS attack types require slightly different evidence and reporting approaches. Here is what to focus on for each.

Volumetric Attacks (UDP/ICMP Flood)

Volumetric attacks overwhelm your bandwidth with sheer traffic volume, typically using UDP or ICMP packets.

Key evidence: Bandwidth graphs showing the spike, pcap showing UDP/ICMP packets from diverse sources, NetFlow data showing aggregate traffic volume. Mention the peak Gbps figure prominently — this is the metric ISPs care about for volumetric attacks.

Reporting note: Many source IPs in volumetric attacks are spoofed, meaning the real attacker is forging the source address. If the majority of source IPs come from a single ASN, they may not be the attacker but rather the network lacking egress filtering (BCP38). Mention this in your report — ISPs are more receptive when you frame it as "your network may be allowing spoofed traffic" rather than "your customers are attacking me."

Protocol Attacks (SYN Flood, Ping of Death)

Protocol attacks exploit weaknesses in network protocols to exhaust connection state tables on firewalls, load balancers, and servers.

Key evidence: Connection table counts (netstat -n | grep SYN_RECV | wc -l), firewall logs showing dropped SYN packets, pcap filtered to show TCP SYN without corresponding ACKs. Report the rate of half-open connections per second.

Reporting note: SYN floods frequently use spoofed source IPs. Include this caveat in your report and request that the ISP investigate whether their network is implementing BCP38 source-address validation.

Application Layer Attacks (HTTP Flood, Slowloris)

Application layer attacks target your web server with requests that appear legitimate but are designed to exhaust server resources.

Key evidence: Web server access logs showing the request pattern (identical URLs, unusual User-Agent strings, abnormal request rates per IP), HTTP status code distribution. These attacks are harder to prove because each individual request looks normal.

Reporting note: Application layer attacks often come from real compromised machines (botnets), not spoofed IPs. This means the source IPs in your logs are accurate, and the ISP can actually identify and notify the compromised customers. Mention specific request patterns — ISPs can correlate these across multiple abuse reports.

If you are seeing reconnaissance activity like port scanning before the DDoS, include that evidence too. Pre-attack scanning strengthens your report.

DNS Amplification

DNS amplification uses open resolvers to reflect and amplify traffic toward your server. The source IPs you see are the resolvers, not the attacker.

Key evidence: Pcap showing DNS response packets from port 53 that you never queried, the query names and types used, and the list of resolver IPs. For a full breakdown of this mechanism, see my DNS amplification attack guide.

Reporting note: Report to two parties: (1) the operators of the open resolvers being abused (so they can restrict recursive queries) and (2) the network allowing the spoofed queries to originate (if identifiable via NetFlow backtracking). Tools like the IP Location lookup can help you identify the organizations running the exploited resolvers.

What to Expect After Reporting

ISP abuse desks handle a high volume of reports, and response times vary widely. Here is a realistic timeline based on my experience:

Follow-up cadence I recommend:

1. After 24 hours — reply to the ticket asking for a status update. Reattach the original evidence.
2. After 72 hours with no response — escalate to the upstream transit provider. Include proof that you reported to the source ISP first.
3. After 7 days — file with your national CERT/CSIRT and, for serious attacks, law enforcement.
4. For ongoing attacks — update your original ticket every 24 hours with fresh evidence (new pcap captures, updated bandwidth graphs). This demonstrates the attack is continuing and raises the priority.

Some ISPs, particularly those in jurisdictions with weak abuse enforcement, may never respond. In those cases, the most practical solution is to block the entire ASN at your firewall or work with your DDoS mitigation provider to filter it.

Prevention and Mitigation Tips

While reporting is important for stopping active attacks and holding attackers accountable, you should also invest in proactive DDoS protection:

• DDoS mitigation services — Cloudflare, AWS Shield, Akamai Prolexic, and similar services can absorb volumetric attacks before they reach your infrastructure. Even the free tiers offer significant protection.
• Rate limiting — implement rate limiting at your web server, API gateway, and firewall levels. This blunts application-layer attacks.
• Anycast routing — if you operate your own network, anycast distributes incoming traffic across multiple points of presence, making it much harder for an attacker to saturate a single location.
• Connection limits — configure your firewall to limit the number of concurrent connections per source IP and the rate of new connections per second.
• SYN cookies — enable SYN cookies (net.ipv4.tcp_syncookies = 1 on Linux) to handle SYN floods without exhausting your connection table.
• Blackhole routing — work with your ISP in advance to set up remote-triggered blackhole (RTBH) routing, which lets you quickly null-route traffic to a targeted IP during an attack.
• Incident response plan — document your DDoS response runbook before an attack happens. Know who to call, what evidence to capture, and where to report. Having this ready cuts your response time from hours to minutes.

This article is part of the IP Abuse Reporting Guide. See also: Report Malware and Botnet C2 Traffic, Report Port Scanning and Network Reconnaissance.