The Attack That Looked Like Noise Until It Wasn't
In early June 2025, a mid-sized European financial services firm absorbed what initially appeared to be routine elevated traffic across its public-facing API gateway. Packet volumes were elevated but not catastrophically so. Alerts fired at the perimeter, were acknowledged, and were categorized as organic load spikes tied to a promotional campaign. Six hours later, the API gateway collapsed under 40 Gbps of sustained UDP flood traffic, and the underlying origin tracing revealed a P2P botnet that had been staging its amplification nodes incrementally across three separate autonomous systems before concentrating fire.
This scenario reflects a pattern that threat intelligence teams are now documenting at increasing frequency. The recent publication of research into P2P botnet architecture, including continuous monitoring efforts tracking how these networks refresh their node pools and rotate command infrastructure, confirms that modern DDoS operations no longer announce themselves with an immediate volumetric spike. They probe, stage, and then surge. The defenders who caught them early shared one characteristic: they were correlating low-rate anomalies across multiple telemetry sources before the volumetric phase began.
This article breaks down how modern DDoS attacks are structured, what telemetry actually reveals during each phase, and how cybersecurity teams can build mitigation strategies that hold up when the assumptions behind most deployment guides turn out to be wrong.
How Modern DDoS Attacks Are Actually Structured
The term DDoS covers a wide range of techniques, and conflating them leads to protection strategies that fail against the specific attack a team is facing. At the technical level, attacks fall into three broad categories: volumetric attacks that exhaust bandwidth, protocol attacks that consume connection state on network devices and servers, and application-layer attacks that target resource exhaustion at Layer 7.
What has changed significantly in the past 24 months is the operational model behind these attacks. P2P botnet research has shown that modern botnets used for DDoS campaigns maintain their node pools without centralized command-and-control infrastructure, making them significantly harder to disrupt by seizing or sinkholing C2 servers. The Netherlands law enforcement action in June 2025, which resulted in the seizure of 800 servers and arrests of two individuals for aiding cyberattacks, illustrates both the scale of infrastructure that supports these operations and the reality that even significant enforcement actions leave distributed P2P mesh networks largely intact.
The staging pattern observed in sophisticated campaigns typically unfolds in three phases. The reconnaissance phase involves low-rate probing to identify which services are externally reachable, what response latency looks like, and where rate limiting or filtering controls are positioned. The staging phase involves marshaling botnet nodes into attack positions, which in P2P architectures means distributing tasking across the mesh rather than issuing commands from a central server. The execution phase involves concentrating traffic in ways designed to overwhelm specific choke points that the reconnaissance phase identified as under-protected.
Reading the Telemetry Before the Flood Starts
The most consequential defensive window is the reconnaissance and staging phase, and most teams miss it entirely because they are filtering for volumetric signatures rather than behavioral ones. Understanding what telemetry to collect and how to query it during this window is the difference between absorbing an attack and deflecting it.
What Traffic Anomalies Actually Signal During Staging
During the staging phase, several telemetry signals appear consistently across documented attack cases. Source IP diversity increases measurably. In normal traffic, a service sees repeat visitors, known crawlers, and session-bearing clients. During botnet staging, the ratio of single-request source IPs rises, and those IPs tend to cluster into ASN ranges associated with residential ISPs, cloud hosting providers, or previously flagged abuse sources. A 20-30% increase in single-request source IP ratio over a two-hour window is a meaningful signal even when absolute volume appears normal.
Protocol distribution shifts. Legitimate application traffic has a characteristic ratio of TCP to UDP, and of SYN packets to established session traffic. Staging traffic, particularly for UDP amplification preparation, introduces protocol ratios that deviate from baseline without producing alert-threshold violations on any individual metric. NetFlow data analyzed at five-minute intervals against a rolling 72-hour baseline will surface these deviations. Most teams analyze NetFlow in longer windows or only query it reactively after an incident, which eliminates this detection opportunity.
Response size distribution changes. When attackers probe for amplification vectors, they send small requests that produce large responses. DNS ANY queries, NTP monlist requests, and SSDP queries all have this characteristic. Monitoring the ratio of inbound packet bytes to outbound response bytes at the resolver or service level, rather than just at the perimeter, will show amplification factor anomalies that flag reflector targeting before the amplification is redirected at a victim.
Log Sources That Matter Most
Effective DDoS early warning requires correlating across at least four log sources simultaneously: perimeter firewall session logs, DNS resolver query logs, BGP route advertisement logs, and upstream transit provider flow data if accessible through a peering relationship or scrubbing service portal. Teams that rely exclusively on perimeter firewall logs see only the traffic that has already arrived at their edge. By the time volumetric attack traffic reaches the firewall, the window for graceful mitigation has typically closed.
BGP route advertisement logs deserve particular attention. One of the more sophisticated DDoS-adjacent techniques involves BGP hijacking or route manipulation to redirect traffic flows, redirect scrubbing, or interfere with blackhole routing announcements. Monitoring for unexpected route origin changes involving your own prefixes, using RPKI validation and route origin authorization (ROA) checks, provides an early signal that something is interfering with how your network is seen by the global routing table.
Mitigation Architecture That Holds Under Real Attack Conditions
Most DDoS mitigation architecture guidance focuses on what to deploy. The operational reality is that the configuration of those controls, and the runbooks that govern how teams use them under pressure, determine whether the architecture holds.
Upstream Scrubbing vs. On-Premises Mitigation
The fundamental question in DDoS mitigation architecture is where to absorb attack traffic. On-premises mitigation appliances, whether dedicated DDoS mitigation platforms or IPS devices with DDoS profiles enabled, can handle protocol and application-layer attacks effectively when traffic volumes remain within the bandwidth capacity of the upstream transit link. The moment a volumetric attack saturates the transit link, on-premises mitigation becomes irrelevant because legitimate traffic cannot reach the network regardless of what the appliance does.
Upstream scrubbing services, whether provided by a transit provider, a CDN with scrubbing capability, or a dedicated scrubbing provider, address the transit saturation problem by filtering traffic before it traverses the last-mile link to the target network. The tradeoff is latency introduced by traffic redirection to scrubbing centers, potential false positives during the first minutes of a new attack signature being established, and dependency on the scrubbing provider's own capacity and detection accuracy.
For organizations without access to upstream scrubbing, BGP blackhole routing (RTBH) provides a blunt but effective tool for protecting the surrounding network infrastructure during a volumetric attack against a specific IP. The tradeoff is that the targeted IP becomes unreachable, effectively accomplishing the attacker's availability goal. Selective blackhole routing and more-specific prefix announcement techniques allow for more surgical traffic redirection, but they require coordination with transit providers and pre-established relationships that cannot be set up during an active incident.
Anycast Architecture for Distributed Absorption
Organizations operating at sufficient scale, or using CDN providers that offer DDoS mitigation, benefit from anycast routing, where the same IP prefix is announced from multiple geographically distributed points of presence. Volumetric attack traffic is distributed across those PoPs rather than concentrated at a single network edge. The absorptive capacity of the aggregate infrastructure exceeds what most attackers can marshal against any single origin.
The practical limitation of anycast-based mitigation for most enterprises is that it primarily protects services sitting behind a CDN or anycast-capable reverse proxy layer. Origin infrastructure that is directly reachable, whether because of misconfigured DNS that exposes origin IPs, direct connections required for business reasons, or legacy services that predate CDN adoption, remains vulnerable to direct-path attacks that bypass the anycast layer entirely. Origin IP exposure is one of the most consistently overlooked gaps in CDN-based DDoS protection. Auditing DNS history, certificate transparency logs, and email headers for origin IP leakage is a necessary step before treating CDN placement as comprehensive protection.
Rate Limiting and Connection Controls That Actually Deflect Application-Layer Attacks
Application-layer DDoS attacks, sometimes called Layer 7 floods or HTTP floods, use apparently legitimate requests to exhaust server resources. Because individual requests look valid, volumetric filtering does not catch them. Effective mitigation requires controls that distinguish between human browsing behavior and automated flood behavior.
Challenge-response mechanisms, including JavaScript challenges, CAPTCHA gates, and cryptographic proof-of-work puzzles, force clients to demonstrate computational investment before receiving a full response. These controls are effective against simple HTTP flood tools but are defeated by botnet nodes running full browser environments or headless browsers. The evolution toward more sophisticated bot infrastructure, which mirrors legitimate browser behavior including TLS fingerprints, HTTP/2 framing, and JavaScript execution, means that challenge-response alone is insufficient for determined application-layer attacks.
Behavioral rate limiting based on request pattern analysis provides a more robust control. Rather than rate limiting by source IP, which is defeated by distributing requests across large numbers of botnet nodes each generating sub-threshold volumes, behavioral rate limiting identifies patterns across request timing, endpoint targeting, user agent clustering, and session characteristics. A request that arrives at 200ms intervals from an IP with a common residential ISP ASN but a TLS fingerprint inconsistent with the declared user agent is flagging something that source-IP rate limiting would miss entirely.
Connection table exhaustion attacks targeting stateful firewalls and load balancers require controls at a different layer. SYN cookies for TCP SYN flood protection, connection rate limits per source with configurable decay windows, and TCP state table size tuning are infrastructure-level controls that prevent protocol-layer attacks from consuming device state tables. Most network devices support these controls natively, but default configurations are often insufficient for the connection rates that modern SYN floods generate.
Operationalizing the Response: What the Runbook Needs to Say
Technical controls only produce outcomes if the operational processes that govern their use under pressure are defined clearly before an incident. DDoS incidents create time pressure and alert fatigue simultaneously, which is a condition under which ad hoc decision-making produces poor outcomes consistently.
Tiered Response Thresholds
An effective DDoS response runbook defines response actions at multiple traffic thresholds with pre-authorized execution authority at each tier. A workable structure establishes three tiers: an observation tier where anomaly signals have appeared but volumetric thresholds have not been breached, an active mitigation tier where automated controls are engaged and the on-call security team is notified, and a crisis tier where upstream scrubbing is activated, executive stakeholders are notified, and a declared incident process begins.
The observation tier is where most teams have the largest gap. The signals are present and the tooling can surface them, but there is no defined process for what to do with an observation-tier alert. Someone sees the anomaly, is uncertain whether it warrants escalation, decides it looks like noise, and closes the alert. Formalizing observation-tier response as a defined workflow with a named responsible role and a decision checklist closes this gap.
Pre-authorization matters enormously. During an active volumetric attack, waiting for approval to activate BGP blackholing or trigger a scrubbing service diversion costs minutes that the network cannot afford. Pre-authorizing specific actions for specific threshold crossings, documented in the runbook and confirmed with management before an incident, removes the approval bottleneck from the critical path.
Communication Flows Under Attack Conditions
DDoS incidents affect multiple stakeholders simultaneously. Network operations needs to know what controls are being applied. Application teams need to understand which services are affected and what the expected timeline for restoration looks like. Customer-facing support teams need enough information to respond to user complaints accurately. Executive stakeholders need a business impact framing, not a technical one.
A single communication template covering each of these audiences, pre-built and reviewed before any incident occurs, allows whoever is managing the incident to send accurate status updates without drafting communications from scratch under pressure. The template should include placeholder sections for attack type, affected services, current mitigation status, and estimated restoration timeline. It should not require technical knowledge to fill in accurately.
Post-Incident Analysis That Actually Improves Posture
Post-incident analysis for DDoS events frequently focuses on what traffic volumes were observed and how long the outage lasted. More useful analysis focuses on which telemetry signals were present during the staging phase that were not actioned, which specific configuration decisions or runbook gaps contributed to delayed or ineffective response, and what the attack revealed about origin IP exposure, amplification vector availability, or scrubbing service limitations.
Documenting these findings in a format that drives specific configuration changes and runbook updates, with owners and deadlines assigned, converts incident analysis from a reporting exercise into an improvement cycle. Tracking whether those changes were implemented and retesting the specific weakness the attack exposed closes the loop.
Infrastructure Targeting and the Intelligence Layer
Modern DDoS campaigns are frequently coordinated with other attack activity rather than executed as standalone operations. Threat intelligence research, including work by organizations with proprietary collection engines that aggregate signals across dark web forums, abuse reporting networks, and active network scanning, has documented cases where DDoS activity was used as a distraction during simultaneous data exfiltration attempts or as a pressure mechanism during ransomware negotiations.
The connection between DDoS capability and ransomware operations is well-documented. Groups that operate ransomware affiliate programs also sell or lease DDoS capacity as a separate revenue stream, and some ransomware groups explicitly threaten DDoS attacks against victim organizations as additional pressure during negotiations. Understanding that the DDoS attack hitting your network may be coordinated with other malicious activity occurring simultaneously against your environment, rather than treating it as an isolated availability event, shapes the incident response approach significantly. An incident response team focused exclusively on restoring availability during a DDoS event may miss credential theft or lateral movement occurring while defensive attention is concentrated on the flood.
The maritime sector has faced a version of this coordination problem in the context of sanctions evasion operations, where cyber operations including DDoS and network intrusion have been used to disrupt vessel tracking and reporting systems as part of coordinated sanctions evasion logistics. The technique of using availability attacks to blind monitoring systems while other malicious activity proceeds is not sector-specific. Any organization with monitoring or logging infrastructure that is itself Internet-reachable should consider the possibility that a DDoS event targeting those systems is designed to create a visibility gap rather than cause direct harm.
Specific Controls to Implement Before the Next Attack
The following actions represent concrete hardening steps that close the most common gaps between documented DDoS mitigation architecture and real-world resilience.
- Conduct an origin IP audit. Query certificate transparency logs, passive DNS databases, and historical DNS records for all domains your organization controls. Identify any records that expose origin infrastructure IPs directly rather than routing through CDN or scrubbing infrastructure. Rotate exposed IPs and update DNS to eliminate direct-path attack vectors.
- Establish BGP blackhole routing capability with your transit providers. If you do not have a pre-negotiated RTBH arrangement with your upstream transit providers, establish one. The negotiation and configuration process cannot be completed during an active attack. Document the community strings, the ASNs involved, and the authorization process required to trigger blackholing for specific prefixes.
- Configure NetFlow analysis with short-window baselines. Set up NetFlow or IPFIX collection with a five-minute analysis window and alert thresholds based on deviations from a 72-hour rolling baseline. Anomaly-based thresholds catch staging-phase signals that fixed volumetric thresholds miss entirely.
- Audit amplification vector exposure. Scan your own IP ranges for open DNS resolvers, NTP servers with monlist enabled, SSDP-enabled devices, and other common amplification sources. Attackers routinely scan for these before staging attacks. Finding and remediating them before attackers use them as reflectors removes amplification leverage from the attack surface.
- Test scrubbing service activation under non-incident conditions. If you have contracted with a scrubbing service, conduct a tabletop exercise that walks through the diversion activation process from start to finish, including the BGP announcement changes required, the monitoring adjustments needed during scrubbing, and the deactivation process when the attack subsides. Discovering process gaps during an actual attack is significantly more costly than discovering them during a planned exercise.
- Implement SYN cookie protection and connection rate limits on perimeter devices. Review default configurations on stateful firewalls and load balancers for SYN flood protection. Enable SYN cookies where supported and configure connection rate limits with per-source decay windows appropriate for your normal traffic patterns.
- Segment DDoS incident response from general security incident response. Create a separate runbook specifically for DDoS events with pre-authorized action thresholds, named roles, pre-built communication templates, and documented escalation paths. Integrate it with your general incident response process but maintain its own escalation criteria and response authority structure.
What Continuous Monitoring Actually Requires
DDoS protection is frequently treated as a set of controls to deploy rather than a continuous monitoring discipline. The P2P botnet research landscape makes clear that the threat infrastructure itself is in continuous operation, with node pools refreshing, attack capabilities evolving, and targeting decisions being made based on observed defender weaknesses. A scrubbing service contracted three years ago with configuration reviewed once at deployment is not the same protection posture as a continuously monitored and tested mitigation architecture.
Continuous monitoring for DDoS resilience means reviewing traffic baselines quarterly and updating alert thresholds when traffic patterns change significantly, testing runbook processes at least twice per year including actual BGP and scrubbing service activation steps, tracking published vulnerability research for amplification vectors and newly discovered reflection techniques, and maintaining awareness of botnet activity targeting your sector through threat intelligence subscriptions that cover DDoS-for-hire services and botnets known to be active against your industry vertical.
The organizations that absorbed major DDoS events in 2024 and 2025 with minimal disruption shared a common characteristic. Their mitigation architecture was not substantially more sophisticated than peers who suffered significant outages. Their operational processes, their continuous monitoring practices, and their response runbooks were significantly more mature. Technical controls create the ceiling of possible resilience. Operational maturity determines how close to that ceiling a team actually performs when the attack arrives.
