The Aisuru Botnet: what we know about
2025-2026's biggest DDoS threat

Back to Blog

From Mirai Fork to Record-Breaker

In late 2024, security researchers began tracking a new botnet family that stood out from the dozens of Mirai variants that had circulated since the original source code leak in 2016. Initially cataloged under the names Aisuru, Kimwolf, and Airashi by different threat intelligence teams, this botnet was built on the Mirai codebase but had diverged significantly enough in its command-and-control architecture, exploit integration, and evasion techniques to warrant treatment as a distinct threat.

The botnet first drew widespread attention in Q4 2024 when Cloudflare disclosed that it had mitigated a record-setting 5.6 Tbps DDoS attack. According to Cloudflare's report, the attack originated from approximately 13,000 IoT devices and lasted only 80 seconds. Cloudflare attributed the attack infrastructure to a Mirai-variant botnet that researchers subsequently linked to the Aisuru/Airashi family. The attack targeted an unnamed internet service provider in Eastern Asia, and Cloudflare's autonomous DDoS protection systems detected and mitigated it without human intervention.

That 5.6 Tbps figure was already staggering, more than double the previous publicly documented record. But it was only a preview of what was coming.

The 6.5 Tbps Barrier and Beyond

Throughout the first half of 2025, Cloudflare reported a sustained increase in hyper-volumetric DDoS attacks. Their Q1 2025 DDoS threat report documented a 358% year-over-year increase in DDoS attacks, with a notable concentration of attacks exceeding 1 Tbps. Cloudflare reported mitigating the largest attack ever recorded at that time: 6.5 Tbps. The attack characteristics were consistent with the same botnet infrastructure responsible for the 5.6 Tbps event months earlier.

By Q3 and Q4 2025, the escalation continued. Cloudflare's reports documented hyper-volumetric attacks becoming routine rather than exceptional, with multiple events exceeding 5 Tbps during the reporting period. The attacks were predominantly UDP-based, high-PPS floods sourced from large populations of compromised IoT devices. The botnet infrastructure powering these attacks had grown in both scale and sophistication.

The shift from gigabit-scale to multi-terabit-scale DDoS happened faster than most defenders anticipated. Aisuru-linked infrastructure has been connected to multiple attacks exceeding 5 Tbps in 2025, a threshold that was considered theoretical just two years prior.

How Aisuru Evolved Beyond Mirai

While Aisuru shares DNA with the original Mirai source code, it has diverged in several important ways that make it a more capable and resilient threat. Based on published analysis from Cloudflare, QiAnXin XLab, and other threat intelligence sources, the key differences include:

Encrypted C2 Communications

The original Mirai used trivial XOR encryption for its command-and-control traffic. Security researchers reversed the encryption within hours of the source code release, enabling passive monitoring of C2 channels. Aisuru has moved beyond this. Researchers at QiAnXin XLab documented that the Airashi variant employs HMAC-SHA256 and CHACHA20-based authentication and encryption for its C2 protocol. This makes passive interception and analysis of C2 traffic significantly harder and complicates efforts to monitor botnet commands or enumerate the bot population by observing C2 registration traffic.

Broader Exploit Integration

Classic Mirai relied almost entirely on brute-forcing default Telnet credentials. While effective, this limited the botnet to devices with open Telnet services and unchanged passwords. Aisuru integrates actual CVE exploits alongside credential brute-forcing. Security researchers have documented the botnet targeting vulnerabilities in specific device families, including ASUS routers (noted in Cloudflare's reporting on the 5.6 Tbps attack), AVTECH IP cameras, and various SOHO router platforms. This hybrid approach of combining credential stuffing with exploit-based infection significantly expands the pool of vulnerable devices.

Faster Device Recruitment

The combination of credential brute-forcing and exploit-based infection means Aisuru can compromise devices that would be immune to one technique alone. A router with a changed Telnet password but an unpatched firmware vulnerability is still a valid target. A camera with patched firmware but default credentials is still a valid target. This dual-path approach accelerates the rate at which the botnet recruits new devices and rebuilds its population after takedown attempts.

More Resilient Infrastructure

Published reporting indicates that Aisuru's operators have invested in making the botnet's command infrastructure more resistant to disruption. While the specifics of the C2 architecture are not fully public, the botnet's ability to rapidly reconstitute after individual C2 nodes are taken down suggests a distributed or redundant control plane, a significant step up from the single-server C2 model in the original Mirai.

Attack Capabilities

Based on observed attack traffic attributed to Aisuru-linked infrastructure, the botnet supports a broad range of DDoS attack vectors. This multi-vector capability makes it particularly dangerous because it can adapt its attack profile to target the weakest point in a victim's defenses:

• UDP floods: High-bandwidth volumetric attacks using randomized UDP payloads. This is the primary vector behind the multi-terabit attacks documented by Cloudflare. The sheer number of compromised devices allows the botnet to generate aggregate bandwidth that saturates even well-provisioned upstream links.
• SYN floods: TCP SYN floods targeting connection state tables on firewalls, load balancers, and servers. High PPS rates from distributed sources make these floods difficult to filter without stateless mitigation (SYN cookies, SYN proxying).
• GRE floods: GRE-encapsulated packet floods that can bypass certain DDoS mitigation systems that only inspect outer IP headers. GRE floods are particularly effective against targets using GRE tunnels for traffic engineering or VPN connectivity.
• DNS water torture: Random-prefix DNS queries (also known as PRSD or NXDOMAIN attacks) targeting authoritative DNS infrastructure. Each query is unique, making response-rate limiting ineffective. The queries exhaust resolver resources and can cascade into DNS outages affecting all domains hosted on the targeted nameservers.
• HTTP/2 floods: Application-layer attacks leveraging HTTP/2 multiplexing to generate enormous request volumes over relatively few TCP connections. These attacks target web application infrastructure directly and can exhaust origin server resources even when fronted by CDN or reverse proxy layers.

# Observed Aisuru attack profile (typical multi-vector event):
#
# Phase 1 (0-10s):    UDP flood ramp-up, 2+ Tbps aggregate
#                     13,000+ source IPs, randomized payloads
#                     Packet sizes: 512-1400 bytes
#
# Phase 2 (10-30s):   SYN flood overlay, 200M+ PPS
#                     Targets exposed TCP services (80, 443)
#                     Distributed across full bot population
#
# Phase 3 (30-80s):   Sustained multi-vector pressure
#                     UDP + SYN + GRE concurrent floods
#                     Attack duration: typically 60-120 seconds
#
# Key characteristic: SHORT DURATION, EXTREME INTENSITY
# Many Aisuru-linked attacks last under 2 minutes
# This is a deliberate strategy to evade manual response

The short attack duration is a notable tactical choice. Many DDoS mitigation workflows assume that attacks last long enough for a human operator to assess, decide, and engage mitigation. An 80-second attack at 5+ Tbps can cause significant damage before anyone has time to react manually. This puts a premium on automated, always-on detection and mitigation.

Scale: How Big Is the Aisuru Botnet?

Precise bot counts are difficult to determine from the outside, and published estimates vary. Cloudflare's report on the 5.6 Tbps attack noted approximately 13,000 source IPs participating in that specific event. However, this likely represents only a fraction of the total botnet population. Botnet operators typically deploy only a subset of their available bots for any given attack, holding the rest in reserve or using them for other operations.

The compromised device population is believed to consist primarily of IoT devices: home routers, IP cameras, DVRs, and network-attached storage devices. ASUS routers have been specifically mentioned in reporting as a targeted device category, likely due to specific firmware vulnerabilities that enable remote compromise. The geographic distribution follows the pattern typical of IoT botnets: heavy concentration in regions with high consumer IoT deployment and lower rates of firmware patching, including Southeast Asia, South America, and parts of the Middle East.

The aggregate bandwidth capacity of the botnet is clearly in the multi-terabit range, given the observed attack volumes. For context, generating 5.6 Tbps of UDP traffic from 13,000 devices requires each device to contribute an average of approximately 430 Mbps. This is consistent with compromised devices connected via fiber or high-speed cable, which is increasingly common as broadband speeds improve globally.

What Aisuru Traffic Looks Like on the Receiving End

If your infrastructure is targeted by an Aisuru-powered attack, the traffic profile on the receiving end has several distinguishing characteristics:

• Extreme PPS from diverse source IPs: You will see packets from thousands of unique source IPs simultaneously. The IPs will be predominantly residential and small-business ranges from dozens of countries. This is distinct from reflection/amplification attacks, where source IPs belong to legitimate servers (DNS resolvers, NTP servers).
• Multi-vector patterns: Rather than a single protocol flood, Aisuru attacks often combine UDP, SYN, and GRE floods in rapid succession or simultaneously. Your monitoring will show concurrent spikes across multiple protocol counters.
• Short burst duration: Many Aisuru-linked attacks last under two minutes. If your monitoring polls at 5-minute intervals, you may see a single elevated data point that dramatically understates the peak intensity. Per-second monitoring is essential to capture the true attack profile.
• Rapid ramp-up: The time from zero to peak attack volume is typically under 10 seconds. There is no gradual increase. All participating bots begin transmitting within seconds of receiving the C2 command.
• Randomized payloads: UDP flood packets contain random data with no consistent payload signature. Packet sizes vary between 512 and 1400 bytes. Source ports are randomized across the full ephemeral range.

# Identifying Aisuru-style attack traffic in flow data:
#
# 1. Source IP count: 5,000+ unique sources in a 10-second window
# 2. Source geo diversity: 30+ countries represented
# 3. Source IP type: 90%+ residential/consumer ISP ranges
# 4. Protocol mix: UDP dominant, with SYN and/or GRE overlay
# 5. Duration: under 120 seconds for the full attack
# 6. PPS profile: near-instantaneous ramp to peak (no warm-up)
# 7. Packet sizes: variable (512-1400 bytes), no clustering
#
# Compare with reflection/amplification:
# - Fewer source IPs (thousands vs. hundreds of thousands)
# - Source IPs are servers (DNS, NTP, CLDAP resolvers)
# - Consistent packet sizes (e.g., ~4800 bytes for CLDAP)
# - Clustered source ports (53, 123, 389, 11211)

How to Defend Against Aisuru-Scale Attacks

Defending against multi-terabit DDoS attacks requires a layered approach. No single mitigation technique is sufficient at this scale. The following strategies address different layers of the defense stack:

Per-Second PPS Monitoring

The short burst nature of Aisuru attacks means that 5-minute SNMP polling will miss the attack entirely or reduce a 5 Tbps spike to an unremarkable blip in your traffic graphs. Per-second PPS and bandwidth monitoring is the foundation of effective detection. Flowtriq provides this out of the box, tracking packets per second, bits per second, and flow counts at one-second granularity on every monitored node. When a PPS spike exceeds your configured threshold or deviates significantly from the established baseline, an incident is triggered within seconds.

Multi-Layer Mitigation

At multi-terabit scale, on-premise mitigation appliances are insufficient. Your upstream bandwidth will be saturated before your scrubbing hardware sees a single packet. Effective defense requires mitigation at multiple layers:

• Upstream BGP FlowSpec: Push filtering rules to your upstream transit providers to drop attack traffic before it enters your network. FlowSpec rules can match on source/destination IP, protocol, port, packet size, and other fields.
• Cloud-based scrubbing: Services like Cloudflare Magic Transit, Akamai Prolexic, or NTT/GTT scrubbing centers absorb volumetric attacks in their globally distributed infrastructure. Traffic is cleaned and forwarded to your origin over GRE tunnels or direct interconnects.
• RTBH (Remotely Triggered Black Hole): As a last resort, advertising a /32 blackhole route for the targeted IP drops all traffic to that destination at your upstream provider. This stops the attack but also drops legitimate traffic. Useful when a single IP is targeted and you need to protect the rest of your infrastructure.

Automated Response

With attack durations under two minutes, there is no time for manual response. Your detection system needs to trigger mitigation automatically. This means pre-configuring FlowSpec rules, scrubbing service activation, and notification channels so that the entire detect-to-mitigate pipeline executes without human intervention. Flowtriq's auto-mitigation rules can trigger FlowSpec announcements, webhook-based scrubbing activation, and multi-channel alerting within seconds of incident detection.

The Broader Trend: Why This Matters

Aisuru is not an isolated phenomenon. It represents a broader trend in botnet evolution that defenders need to understand. The trajectory from 2016 to 2026 tells a clear story:

• 2016: Mirai reaches 620 Gbps (KrebsOnSecurity) and 1.2 Tbps (Dyn DNS). These were considered extraordinary at the time.
• 2018-2020: Reflection/amplification attacks using memcached, CLDAP, and DNS reach 2+ Tbps (AWS Shield reported a 2.3 Tbps CLDAP reflection attack in February 2020).
• 2024: Aisuru-linked botnet hits 5.6 Tbps using direct IoT bot traffic, not reflection.
• 2025: Multiple attacks exceeding 5 Tbps are documented. Hyper-volumetric attacks become routine.

The important shift is the return to direct botnet attacks at volumes that previously required reflection/amplification. Reflection attacks are inherently limited by the availability and response ratio of reflector services. Direct botnet attacks scale with the number of compromised devices and their aggregate bandwidth. As global broadband speeds increase and IoT device counts grow, the ceiling for direct botnet attacks rises proportionally.

This means defenders cannot rely on the assumption that the largest attacks will always be reflection-based. The filtering heuristics that work for reflection traffic (blocking specific source ports, rate-limiting specific protocols) do not apply to direct botnet floods with randomized source ports and payloads. Detection must focus on traffic volume anomalies, source IP diversity analysis, and per-second monitoring rather than protocol-specific signatures.

The most important lesson from Aisuru is about speed. When attacks last 80 seconds and reach 5+ Tbps, the difference between detecting in 2 seconds and detecting in 5 minutes is the difference between automated mitigation and a post-mortem. Per-second visibility is no longer optional for any network that could be targeted.

Back to Blog

Related Articles