DDoS Record: 31.4 Tbps, the AISURU Botnet Shatters Every Record

On February 11, 2026, Cloudflare published the details of a DDoS attack of unprecedented scale: 31.4 terabits per second. Behind this offensive was the AISURU botnet, also known as Kimwolf, made up of millions of compromised devices. This record shatters the previous ceiling of 11.5 Tbps recorded in September 2025. For system administrators and infrastructure managers, this escalation calls for a complete rethink of defense strategies.

Anatomy of the record-breaking attack

The key figures

The attack took place in November 2025 and was made public in early February 2026 in Cloudflare's quarterly DDoS threat report. Here is what we know:

• Peak throughput: 31.4 Tbps of bandwidth, with a simultaneous peak of 200 million requests per second
• Duration: just 35 seconds, a lightning-fast attack designed to overwhelm defenses before any human can react
• Botnet size: between 1 and 4 million compromised hosts, including more than 2 million Android devices (mostly Android TVs from second-tier brands)
• Targets: Cloudflare customers, but also Cloudflare's own dashboard and infrastructure
• Mitigation: fully automated by Cloudflare's autonomous defense system, with no human intervention

To put this figure in perspective, 31.4 Tbps is roughly three times the previous record. It is the equivalent of the bandwidth needed to stream more than 6 million 4K video streams simultaneously.

The "The Night Before Christmas" campaign

The record attack was part of a broader campaign dubbed "The Night Before Christmas," launched on December 19, 2025. The timing was no accident: security teams run on skeleton crews during the holidays, response times are longer, and the pressure on online services (e-commerce, streaming, cloud services) is at its peak.

This timing strategy has become a classic move for sophisticated attacker groups. In fact, 2025 saw a 121% increase in DDoS attacks compared to 2024, with an average of 5,376 attacks mitigated per hour at Cloudflare alone.

The AISURU botnet: an army of connected objects

Botnet composition

AISURU/Kimwolf makes heavy use of vulnerable IoT devices. The majority of the botnet's nodes are Android TVs from little-known brands, often sold cheaply and rarely updated. These devices combine several weaknesses:

• Firmware never updated after the sale
• Network services exposed by default (ADB, Telnet)
• Factory passwords left unchanged
• No secure automatic update mechanism
• Permanent Internet connection over high-speed residential networks

This profile is ideal for a botnet: substantial bandwidth, 24/7 availability, and owners who have absolutely no idea their device is taking part in attacks.

Check your IoT exposure

Here is how to scan your network to detect potentially compromised devices:

# Scan the local network for commonly exploited services
nmap -sV -p 5555,23,80,8080,8443 192.168.1.0/24

# Check whether ADB (Android Debug Bridge) is exposed
nmap -p 5555 --open 192.168.1.0/24

# List suspicious outbound connections on a Linux/Android device
ss -tunp | grep -E ':(80|443|8080|53)' | grep -v LISTEN

If you find a device with ADB open (port 5555) or Telnet active (port 23), isolate it from the network immediately and apply a firmware update if one is available.

Why 35 seconds is enough to break everything

The extremely short duration of the attack is not a sign of weakness. It is a tactical evolution. Modern DDoS attacks favor ultra-intense bursts for several reasons:

• Instant saturation: 31.4 Tbps for 35 seconds is enough to take down any server not protected by a large-scale CDN
• Evading detection systems: some mitigation systems need 30 to 60 seconds to detect and respond to a volumetric attack
• Minimal cost for the attacker: mobilizing a botnet of millions of nodes for 35 seconds consumes few resources
• Repeated attacks: the attacker can launch dozens of successive bursts, probing the limits of the defense

The lesson is clear: if your infrastructure relies on human intervention to respond to a DDoS attack, you are already vulnerable. Mitigation must be automated and instantaneous.

Protecting your infrastructure: concrete strategies

Level 1: the local firewall with UFW

Even though a local firewall cannot stop a 31 Tbps attack, it remains the first line of defense against scans, brute-force attempts, and small-scale attacks. Configure UFW restrictively:

# Default policy: block everything inbound
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow only the necessary services
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Rate-limit SSH (6 connections in 30 seconds)
sudo ufw limit 22/tcp

# Enable the firewall
sudo ufw enable

# Check the active rules
sudo ufw status verbose

To go further with advanced iptables rules, you can add anti-SYN-flood protections:

# SYN flood protection via iptables
sudo iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
sudo iptables -A INPUT -p tcp --syn -j DROP

# Limit simultaneous connections per IP
sudo iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j REJECT
sudo iptables -A INPUT -p tcp --dport 443 -m connlimit --connlimit-above 50 -j REJECT

# Drop invalid packets
sudo iptables -A INPUT -m state --state INVALID -j DROP

Level 2: Nginx as an application-layer shield

Your Nginx server can absorb part of layer 7 attacks (HTTP flood) with a suitable configuration:

# /etc/nginx/conf.d/rate-limiting.conf

# Limiting zone: 10 requests/second per IP
limit_req_zone $binary_remote_addr zone=global:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    listen 443 ssl;
    server_name example.com;

    # Apply rate limiting
    limit_req zone=global burst=20 nodelay;
    limit_conn addr 30;

    # Limit request size
    client_max_body_size 10m;
    client_body_timeout 10s;
    client_header_timeout 10s;

    # Close slow connections
    keepalive_timeout 15s;
    send_timeout 10s;
}

Level 3: Fail2ban for dynamic blocking

Fail2ban remains indispensable for automatically blocking abusive IPs. However, as I explain in the article Fail2ban Is Not Enough, it is only one building block among several. Here is a basic anti-DDoS configuration:

# /etc/fail2ban/jail.d/nginx-ddos.conf
[nginx-limit-req]
enabled = true
filter = nginx-limit-req
action = iptables-multiport[name=nginx-limit-req, port="80,443", protocol=tcp]
logpath = /var/log/nginx/error.log
findtime = 60
bantime = 3600
maxretry = 10

[nginx-botsearch]
enabled = true
filter = nginx-botsearch
action = iptables-multiport[name=nginx-botsearch, port="80,443", protocol=tcp]
logpath = /var/log/nginx/access.log
findtime = 120
bantime = 86400
maxretry = 5

Level 4: CDN and external DDoS protection

Facing terabit-scale attacks, no self-hosted infrastructure can hold out on its own. Cloudflare mitigated this 31.4 Tbps attack autonomously thanks to a network spread across more than 300 datacenters. The options:

• Cloudflare (free to enterprise): DDoS protection included even on the free plan, "Under Attack" mode enabled in one click
• OVH Anti-DDoS: included with dedicated servers, automatic mitigation up to several Tbps
• AWS Shield: built-in protection for AWS services, Advanced version for sophisticated attacks

Check that your real IP is hidden

# Check the historical DNS records of your domain
# (from an external machine)
dig +short example.com
dig +short www.example.com

# Test whether the IP responds directly (it should not)
curl -sk --connect-timeout 5 https://YOUR_SERVER_IP

# Make sure only Cloudflare IPs can reach Nginx
# /etc/nginx/conf.d/cloudflare-only.conf
# allow 173.245.48.0/20;
# allow 103.21.244.0/22;
# allow 103.22.200.0/22;
# allow 104.16.0.0/13;
# allow 108.162.192.0/18;
# deny all;

Anti-DDoS security checklist

Check out the complete Linux server security checklist for an overview. As a complement, here are the DDoS-specific points:

#!/bin/bash
# Quick anti-DDoS audit script

echo "=== Anti-DDoS Audit ==="

# 1. Check that the firewall is active
echo "[1] UFW status:"
sudo ufw status | head -5

# 2. Check kernel connection limits
echo "[2] Kernel parameters:"
sysctl net.ipv4.tcp_syncookies
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.core.somaxconn

# 3. Check Fail2ban
echo "[3] Active Fail2ban jails:"
sudo fail2ban-client status | grep "Jail list"

# 4. Check Nginx rate limiting
echo "[4] Nginx rate limiting:"
grep -r "limit_req_zone" /etc/nginx/ 2>/dev/null

# 5. Active connections
echo "[5] Active connections by state:"
ss -s

Tuning kernel parameters

The Linux kernel offers several parameters that harden resistance to network attacks. Add these lines to /etc/sysctl.conf:

# /etc/sysctl.conf - Anti-DDoS parameters

# Enable SYN cookies (SYN flood protection)
net.ipv4.tcp_syncookies = 1

# Increase the SYN backlog
net.ipv4.tcp_max_syn_backlog = 65535

# Reduce SYN-ACK retries
net.ipv4.tcp_synack_retries = 2

# Increase the maximum number of connections
net.core.somaxconn = 65535

# Ignore ICMP broadcasts (anti-smurf)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Ignore bogus ICMP responses
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Enable reverse path filtering
net.ipv4.conf.all.rp_filter = 1

# Disable ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Apply immediately
# sudo sysctl -p

What this attack changes for sysadmins

The 31.4 Tbps record marks a turning point. Here are the takeaways:

1. Automated mitigation is no longer optional. With a 35-second attack, human reaction time is not enough. Your defense systems must be able to react in milliseconds.
2. IoT is the weak link. Millions of vulnerable connected devices provide attackers with colossal firepower. Every unsecured device on your network is a potential soldier in the enemy army.
3. Defense in depth is imperative. Local firewall, application-layer rate limiting, Fail2ban, CDN: each layer filters out part of the malicious traffic. No single layer is enough on its own.
4. Holiday periods are attack windows. Plan your on-call rotations and alerting systems accordingly.
5. The cost of a DDoS attack keeps dropping. With the 121% increase in attacks in 2025, the question is no longer whether you will be targeted, but when.

Conclusion

The 31.4 Tbps DDoS attack orchestrated by the AISURU botnet is a wake-up call for the entire industry. It demonstrates that IoT botnets have reached a maturity and firepower that exceed the defensive capabilities of most individual infrastructures. The response lies in a combination of rigorous local measures (firewall, rate limiting, kernel hardening) and external mitigation services capable of absorbing traffic volumes of several tens of terabits.

Start by auditing your infrastructure with the script provided in this article, apply the recommended configurations, and make sure your IoT devices are not unwittingly taking part in the next record-breaking attack.