Ataques DDoS: técnicas y mitigación en infraestructuras empresariales

In May 2025 the KrebsOnSecurity site suffered a massive DDoS attack of approximately 6.3 Tbps. According to the information reported, it was a brief incident ( approximately 40 to 45 seconds) designed as a test of a new IoT botnet called Aisuru. The magnitude of the attack was unprecedented: it exceeded the 2016 Mirai attack (623 Gbps) by a factor of ten. At the time, the affected entity was under the protection of Google Project Shield (free anti-DDoS service for media), and Google confirmed that this was the largest attack its infrastructure had ever suffered. This incident is a clear example that DDoS attacks are becoming more and more powerful and can compromise even the most prepared entities, therefore, we will now provide a detailed explanation of DDoS attacks.

What's a DDoS attack?

A DDoS attack aims to saturate the resources of a system, service or network, preventing its normal operation. Unlike a conventional DoS attack, in which a single source launches the offensive, a DDoS attack is characterized by its distributed nature: multiple (often compromised) devices generate a massive volume of coordinated traffic against the victim.

These devices, which are part of networks known as botnets, are controlled remotely and simultaneously, which complicates the identification of the real origin of the attack and multiplies its effectiveness.

Classification of attacks

DDoS attacks can be classified into four broad categories:

• Network layer attacks (L3/L4): their purpose is to consume limited server resources or intermediate infrastructures (CPU, memory, firewall tables or pending TCP connections). Classic examples are SYN floods (the server receives many connection requests with the SYN flag but never completes the handshake), or attacks based on manipulated ARP or TCP packets (SYN/ACK/FIN) to generate network saturation. These exploit the TCP/IP protocol to saturate buffers and state tables of network devices. They are highly effective in overflowing routers, firewalls or load balancers.
• Application layer attacks (L7): theyaim to exhaust web application resources by making legitimate but massive HTTP (GET/POST) requests. Each request may seem “normal” (a simple click or page load), but they are multiplied hundreds or thousands of times from multiple bots, overloading CPU, databases or page generation processes. For example, an HTTP flood consists of repeatedly forwarding the same URL from many zombie clients (simulating user clicks) until the server can no longer respond. These are difficult to filter, as the traffic appears to be similar to real traffic.
• Volumetric attacks: seek to collapse the bandwidth to the victim. They send gigantic amounts of data (Tbps surges) via UDP floods, HTTP or amplification/reflection attacks (DNS, NTP, Memcached, CLDAP, SIEM, etc.), which exploit size differences between the original request and the response. The goal is to congest physical links and prevent legitimate traffic.
• Multivector attacks: A combination of several types of attack (volume, protocols, applications) simultaneously to evade antiDDoS measures. For example, launching a SYN flood, UDP flood and HTTP requests at the same time. Advanced attacks may adapt in real time, changing methods as they are mitigated. This makes it necessary to employ defenses that address all fronts: per-protocol filtering, pattern inspection and anomaly scanning.

Noteworthy DDoS historical incidents

The following are several known massive DDoS (with size, target and technique):

• 2016 (Dyn, DNS) – 1.2 Tbps: A large attack against DNS provider Dyn (October 2016) that reached approximately 1.2 Tbps. It was launched with IoT botnets (mainly DVR cameras hijacked by Mirai) that saturated DNS servers using likely memcached extensions and UDP floods. The attack caused intermittent crashes on sites such as Twitter, GitHub, PayPal and Netflix.
• 2016 (Mirai a KrebsOnSecurity) – 623 Gbps: September 2016, the Mirai botnet (hundreds of thousands of compromised IoT devices) launched a 623 Gbps DDoS on KrebsOnSecurity. This packet was the largest ever recorded. Mirai used default credentials to infect more than 600,000 routers, cameras, DVRs, etc., and its attack code supported UDP flooding, HTTP and all TCP variants. The assault lasted almost 4 days, taking the blog offline until Akamai Prolexic mitigated it.
• 2018 (GitHub) – 1.35 Tbps: March 2018, GitHub suffered a DDoS of 1.35 Tbps (record until then). It was a Memcached amplification attack: thousands of open memcached servers responded to small UDP queries, sending 50-100 times more data to the victim. The attack lasted about 15-20 minutes and was stopped by filtering the memcached traffic.
• 2020 (AWS Shield) – 2.3 Tbps: In February 2020 Amazon reported that its AWS Shield service mitigated a 2.3 Tbps DDoS (up to that point the largest reported). It was a CLDAP reflection attack: stateless LDAP servers responded to UDP queries with large responses, amplifying traffic to AWS. The company did not disclose the target, but noted that CLDAP amplification (port 389) was used massively in this attack.
• 2021–2022 (Mēris) – 21.8 Mpps: The Mēris (Meris) botnet emerged by exploiting vulnerabilities in MikroTik (RouterOS) routers. In September 2021 QRator reported a Meris attack of 21.8 million requests per second (RPS), using approximately 200,000 devices. In 2022, Akamai reported that Meris reached 46 million RPS targeting Google (approximately 1.3 Tbps traffic). Meris employs SOCKS4 proxies and HTTP/UDP pipelining techniques to exploit open ports (such as port 5678) on these routers.
• April 2025 (Cloudflare) – 6.5 Tbps: A hyper-attack in April 2025 blocked by Cloudflare reached 6.5 Tbps, matching the bandwidth record ever reported. This event was described as “hyper-volumetric”: 4.8 billion packets per second and 6.5 Tbps of data. Cloudflare did not disclose the targets of the attack, but indicated that exploits of CLDAP and other UDP protocols were exploited, and that attacks on this scale are occurring with increasing frequency.
• May 2025 (KrebsOnSecurity) – 6.3 Tbps: Finally, the attack that motivated this publication, of approximately 6.3 Tbps against KrebsOnSecurity. According to analysis, Aisuru used a massive UDP flood (large packets to random ports) of about 585 million requests per second (pps), for about 40 sec. It was neutralized by Google Shield with no visible impact. These cases underline the trend: DDoS have evolved from hundreds of Gbps to several Tbps and from millions to billions of pps in a few years.

Technical analysis of the mentioned attacks

• DDoS a Dyn (2016): It is believed to be a combination of Mirai and reflection techniques. Thousands of compromised IoT (routers/CCTV) sent traffic, possibly amplified via NTP or DNS. Dyn reported peaks of 1.2 Tbps. Dyn network partially down; mitigators (Netscout/Arbor, DynAS on AWS, F5 Silverline) implemented native live defense and BPF filter updates.
• Mirai (2016): It was a multi-vector attack originating from Mirai code. The botnet scanned the Internet for IoT devices with default credentials and exploited 64 common combinations, compromising approximately 600,000 devices (IP cameras, routers, DVRs). The attack module supports multiple techniques: arbitrary UDP floods, HTTP flood attacks (GET/POST) and any type of TCP flows (SYN, ACK, RST, etc.). For the DDoS over Krebs, mainly large UDP packets were dropped to random ports. Each malicious packet carries spoofed victim IP, saturating the destination link. The flood reached 623 Gbps and lasted 96 hours. The defense relied on diverting traffic to Akamai's Prolexic service, which applied signature and behavioral filtering and synchronized distributed state tables.
• GitHub (2018): Memcached mirror attack. There was no malware: the attacker sent UDP to 11211 ports of open Memcached servers, with spoofed GitHub IP. Each small “get stats” request generated 50-100× larger responses, redirected to GitHub. The peak was 1.35 Tbps in 20 minutes. GitHub instantly used Akamai Prolexic: they changed GitHub's DNS routing to go through Akamai's scrubbing centers, which scrubbed the Memcached traffic by identifying the unique pattern of these packets.
• Amazon/AWS (2020): The 2.3 Tbps attack was a CLDAP reflection attack. The bots sent massive UDP queries to port 389 of Connectionless LDAP servers, requesting generated responses to the victim. AWS Shield enabled rules to identify the CLDAP pattern of that attack, along with BGP blackholing. The traffic was distributed in the AWS cloud and leaked at the edge, protecting cloud clients.
• Mēris (2021–22): This botnet exploited vulnerable Mikrotik routers. It used a flaw in RouterOS to take control of nearly 200,000 routers. Mēris operated at 46 million requests sent to Google and other targets, using TCP/UDP streams and internal SOCKS4 proxies for amplification. The defense involved patching Mikrotik (closing ports 5678, 8291) and filtering traffic from these devices. Cloudflare/Akamai designed specific rules for signing Mēris, reducing their impact.
• Cloudflare (april 2025): The attack was executed by a botnet not yet attributed, but with similar characteristics to Meris and Aisuru, based on IoT devices and misconfigured servers. A peak of 6.5 Tbps was reached, with more than 470 million packets per second (mpps), employing mainly unamplified UDP flood, targeting random ports of Cloudflare services. No amplification was observed via classical protocols (DNS, NTP), suggesting a direct saturation tactic from zombie devices. The duration of the attack was about 70 seconds, enough to put pressure on multiple network regions. Cloudflare's global Anycast infrastructure absorbed the traffic, distributing it across more than 120 data centers. Automatic measures such as hardware-based mitigation (XDP/eBPF), dynamic scrubbing policies, and per-IP rate-limiting and geographic traffic segmentation were activated, diverting anomalous flows to advanced mitigation centers, avoiding saturation at backbone nodes.
• Aisuru/Krebs (2025): In the most recent attack, the Aisuru botnet used compromised IoT devices (routers, DVRs). It dropped about 585 million UDP packets per second to random ports on the Krebs server. It did not use a known standard amplification service (such as DNS), but direct flooding. The brevity (45 s) complicated initial detection, but the Google service (Shield) applied aggressive filtering of unsolicited UDP traffic and scaled resources. Rate monitor (rate-limiter) and “anycast cleaning” policies directed the flow to cleaning centers in Google's global network, avoiding local crashes.

Most commonly used amplification protocols and techniques

The most common techniques exploit poorly designed UDP protocols. The attacker sends small requests (with spoofed source IP) to obtain much larger responses, achieving a 10× to 100× amplification factor (BAF). Some key examples:

• DNS (Puertos UDP 53): A classic. The attacker issues DNS queries (ANY type) to open resolvers, asking for large records. Each small UDP request generates a much larger response. These responses are directed to the victim (by the spoofed IP) and in this way they get a server with amplified traffic.
  • Ratio: 28x
  • Mitigation: Use DNS server redundancy and traffic limiting.
• NTP (UDP 123): Using the MONLIST command (old, now replaced) an NTP server would reply with a large list of connected clients. The attacker sent a small MONLIST packet (48 bytes) with spoofed victim IP, and got a much higher response.
  • Ratio: 50-500x
  • Mitigation: Disable monlist in ntp.conf with disable monitor and apply firewall rules.
• Memcached (UDP 11211): Memory cache servers. A “stats” request of only 15 bytes can generate responses of more than 750KB. No botnet required; just spoof addresses and multiple memcached machines will respond simultaneously to the victim. These attacks set the 2018 records.
  • Ratio: 51.000x
  • Mitigation: Disable UDP in memcached, restrict its access or set firewall rules.
• CLDAP (UDP 389): Lightweight stateless directory access protocol. A single LDAP query can produce hundreds of bytes of response. Between 2019-2021 saw a boom of open CLDAP being abused in DDoS of several Tbps.
  • Ratio: 56-70x
  • Mitigation: Restrict UDP access to port 389, disable CLDAP on servers that do not require it.
• SNMP (UDP 161): Protocol used to monitor and manage network devices. Attackers send small SNMP requests like GetBulkRequest multiplying the traffic on the attacked device.
  • Ratio: 6-15x
  • Mitigation: Restrict UDP access to port 161, disable SNMP on servers that do not require it and configure SNMP to only accept connections from the internal network, use SNMPv3 with authorization.
• Others: SSDP (amplification miles), Chargen (Factor ~358×), SLP (Factor 2200×), TFTP, NTP, Portmap, QOTD, Steam, etc. CISA lists dozens of exploitable UDP services. Every new service exposed on the Internet (especially on unfiltered IoT devices) can become an amplification vector. All of them use IP spoofing: response packets reach the real target without it having sent anything.

Attacker resources

DDoS attackers have several sources of power at their disposal:

• Massive botnets: Global networks of compromised devices. The most relevant recent examples are Mirai (IP routers, cameras, DVRs with default credentials), Mēris (Mikrotik routers) and Aisuru (various IoT: routers, DVRs). These networks often grow by exploiting known vulnerabilities or weak passwords to recruit devices. An attacker can also rent a “DDoS-as-a-service” botnet for a few dollars.
• Vulnerable/open servers: Misconfigured server machines play the role of “reflectors”. Any UDP service (DNS, NTP, Memcached, CLDAP, SSDP, etc.) without authentication that responds to external requests is sought. Thousands of hosts on the Internet still do not filter traffic or close ports, and serve as traffic multipliers.
• IoT devices: All types of connected equipment (IP cameras, SOHO routers, DVR cameras, printers, IoT appliances, etc.). Many have limited hardware and no security. In practice, any router or camera with open Telnet is recruitable, as Mirai demonstrated.
• Tools and exploits: Attackers use specialized traffic generation and automation software: e.g. hping3 (inject TCP/UDP packets), LOIC/HOIC (HTTP flooding), Metasploit with DDoS modules, custom scripts in C/Python, etc. For forensic analysis they use Wireshark or tcpdump (capture and filter suspicious traffic) and network monitoring systems (Bro/Zeek, SNORT) configured with traffic anomaly rules. In the botnet propagation stage, port scanners (masscan, zmap) and IoT exploit kits are used.

Phases of the attack

A well-coordinated DDoS attack is usually deployed in several phases:

1. Reconnaissance: The attacker identifies the exposed services, their architecture and possible weak points, such as servers with limited protection or default configurations.
2. Device compromise: Multiple computers are infected to form the botnet. These can include anything from personal computers to poorly secured IoT devices.
3. Command & Control (C2): A communication channel is established between the compromised devices and the control server, from which the attack is orchestrated.
4. Execution: The offensive is launched at the most critical moment, often coinciding with key events or during specific campaigns, in order to maximize the impact.
5. Adaptation: Some attacks monitor the victim's defensive responses in real time and adjust their traffic pattern to evade mitigation measures.

Advanced evasion techniques

Attackers have refined methods to make detection and response more difficult:

• Spoofing IP addresses to mask the real origin of traffic.
• Rotation of attack vectors (e.g., combining UDP flood with HTTP GET attacks) to confuse defense tools.
• Use of encrypted traffic, which forces the target system to decrypt each packet before validating it, increasing the computational load.
• Low-and-slow techniques, which consume resources progressively and silently, avoiding sudden spikes that alert monitoring systems.

Most effective defensive equipment and architectures

Professional DDoS mitigation relies on specialized architectures:

• Scrubbing centers: Dedicated global networks. Companies such as Netscout/Arbor have some 16 global centers with more than 15 Tbps of combined capacity. When an attack is detected, client traffic is “scrubbed” (via BGP or proxy) to these centers, where it is filtered (separate legitimate/malicious traffic) before being redirected to the destination. Other major providers include Akamai/Prolexic, Cloudflare, Radware (DefensePro), Imperva Incapsula and AWS Shield.
• On-premise appliances: specialized hardware installed at the enterprise or ISP. Examples: Arbor TMS/Netscout APS, Radware DefensePro, FortiDDoS, F5 Silverline, etc. These detect and mitigate volumetric attacks up to a certain limit. They are often used in combination with scrubbing in the cloud (hybrid deployment.
• CDNs/Anycast: Content delivery networks (Cloudflare, Akamai, Fastly, Google Cloud CDN). By having distributed infrastructure (Anycast) each node shares the traffic load. If a DDoS attacks a CDN-protected domain name, the malicious traffic is dispersed globally and gradually attenuated. In addition, these services often include built-in anti-DDoS rules (connection limiting, WAF, etc.). Google Shield, for example, applies these techniques behind the scenes.
• Firewalls and WAFs: Network firewalls (Cisco ASA, Palo Alto, iptables on Linux) can be configured with limiting policies (blacklists, packet rate) for common attacks. WAFs (Web Application Firewalls) such as Cloudflare WAF, ModSecurity or AWS WAF filter malicious HTTP traffic (SQLi, Layer7 botnets). Although they do not stop a volumetric attack at the network level, they help mitigate application-targeted attacks.
• Detection and monitoring systems: Tools such as Zeek (Bro), Snort/Suricata or NetFlow/IPS systems are used to detect anomalous patterns in real time (connection spikes, known attack signatures, anomalous rates). Early visibility is key to triggering defenses (e.g., enabling scrubbing or IP blocking).

These solutions are often combined: a typical deployment may include a local firewall that in case of DDoS triggers BGP routes to a dedicated scrubbing center, or redirects traffic to a global CDN. The key is to have a redundant defensive layer (on-premise + cloud). For critical cases, there are agreements with ISPs to intercept and filter traffic at the backbone level.

Specific mitigation techniques

Defense against DDoS attacks requires a combination of proactive and reactive measures:

• Perimeter-level traffic filtering using advanced firewalls and IP blacklists.
• Anomaly detection and analysis systems capable of identifying unusual traffic patterns.
• Use of external mitigation services, such as scrubbing centers or specialized cloud services.
• Network segmentation and infrastructure redundancy, to limit the exposure surface and ensure operational continuity.
• Specific response plans, including rapid action protocols and containment tools.
• Rate limiting: At the network or application layers, the number of connections or requests per IP can be restricted. Tools such as iptables (Linux Netfilter) implement hashlimit or SYNPROXY modules.  Similarly, HTTP proxies (Nginx, HAProxy) can limit GET requests per second.
• Packet filtering and blocking: ACLs in routers and firewalls, or high-performance BPF filters, block malicious traffic based on IP/port/flags. For example, UDP packets directed to ports not used by the application can be discarded, or recognized patterns (payload size or signature) can be blocked. Filtering can operate in hardware (switch ASICs) or on the server CPU itself. The challenge is to configure it without interrupting legitimate traffic.
• Desafíos o autenticación: A nivel web, métodos como CAPTCHA o JavaScript challenges (verificación de navegador) diferencian bots de usuarios reales, frenando ataques de capa 7. En TCP, los SYN cookies (del kernel) evitan almacenar estado de conexiones pendientes, por lo que inundaciones SYN sólo generan cookies hasta llenar la ventana. Algunas soluciones de red de nueva generación aplican puzzles criptográficos para cada conexión sospechosa.
• BGP Blackholing: Consists of advertising the target network as a “hollow” route to a collaborating ISP, so that the traffic is discarded on its way into the attacking network. Imperva explains that using the BGP BLACKHOLE community allows DDoS traffic to be diverted away from the server. It is effective for extreme volumetric attacks, although it involves rendering the service inaccessible for the duration (it is a last resort).
• Anycast and Load Balancing: Anycast providers (Cloudflare, Google) broadcast multiple server instances under the same IP. DDoS is automatically distributed among them, avoiding a single point of congestion. This works because BGP routes to the “closest” node in latency, spreading the overall load.
• Scrubbing in the cloud: Managed services (Akamai, Cloudflare, AWS Shield, Google Shield) offer mitigation in the cloud: they forward all traffic to their scrubbing centers, where it is scrubbed with custom rules. Google Shield protected KrebsOnSecurity using this approach. AWS Shield Advanced, for example, enabled protections against CLDAP for AWS. These platforms use machine learning and experts to automatically filter.
• Automated rules: Many modern DDoS use known signatures (e.g., Memcached amplification patterns or specific SYN floods). IDS/IPS systems can load pre-designed signatures or adapt based on previous detections to quickly block the identified vector. Some WAF/Capa7s act automatically under high volume (typically at 5xx with autoscaling).

Conclusions, lessons learned and recommendations

The May 2025 incident confirms several critical trends: DDoS attacks have become hyper-volumetric (Tbps) and extremely high packet rate (billions of pps). In Q1 2025 Cloudflare detected more than 700 “hyper-volumetric” attacks (>1 Tbps or >1 Bpps) never seen before. This requires increasingly robust and automated defenses.

Key lesson: securing IoT devices is critical. Most of these botnets come from routers/cameras with default or unpatched credentials. It is recommended to close them to the public and update firmware. Insecure “reflections” should also be eliminated: disable unnecessary UDP services, filter DNS/NTP/Memcached on the internal network and configure firewalls to not respond to unsolicited queries.

Impact and consequences: The impact of a DDoS attack can be devastating, not only technically, but also economically and reputationally. Interrupted services, loss of customers, performance degradation, increased operating costs and response team overload are just some of the immediate consequences. In critical infrastructure or industrial environments, a well-targeted attack can even disrupt physical processes or cause operational insecurity.

Future trends: Attackers are increasingly expected to exploit new protocols (e.g. new P2P services or stateless IoT) for amplification. Therefore, a defense-in-depth strategy and inter-organizational cooperation (intelligence sharing between companies and vendors) is crucial.

Practical recommendations: organizations should implement early detection (netflow, IPS, SIEM) to trigger automatic responses. It is essential to enable SYN cookies on all servers, limit unusual packet rates (iptables hashlimit, SYNPROXY), and use cache or CDN systems to absorb sudden peaks. For web environments, employ up-to-date WAF and CAPTCHAs where feasible. Also, keep systems up to date and shut down unnecessary services. Finally, it is highly recommended to have a contingency plan (runbook) and agreements with cloud mitigation providers or ISPs (for BGP blackholing/Anycast) in place before an attack occurs. In summary, only a combination of layers of defense, continuous monitoring and good network practices can withstand the rising tide of massive DDoS attacks.

Sources: analysis and figures based on technical reports by Brian Krebs, vendor reports (Cloudflare, AWS/TheVerge) and cybersecurity authorities (CISA, INCIBE), among others. Each technical statement cited here is supported by such reports or specialized documents.