A mixed flood (or multi-vector DDoS attack) is a denial-of-service technique that combines two or more distinct attack vectors — for example a volumetric UDP flood, a protocol-level SYN flood, and an application-layer HTTP flood — launched simultaneously or in sequence against the same target. Because each vector stresses a different layer and resource (bandwidth, connection tables, application compute), combining them defeats defenses tuned to detect and mitigate only one attack type at a time, and forces defenders to correlate signals across layers instead of relying on a single threshold.
TL;DR: Multi-vector DDoS attacks blend volumetric floods (UDP, ICMP, amplification), protocol/state-exhaustion floods (SYN, FIN, RESET, ACK-PSH), and application-layer attacks (HTTP flood, Slowloris) into one coordinated campaign. Each vector targets a different resource, so a defense tuned only to stop one vector — bandwidth scrubbing, SYN cookies, or a WAF rule — leaves the others unmitigated, and the combination often causes more damage than the sum of the vectors run individually. Detection requires correlating telemetry across network, transport, and application layers rather than trusting any single-vector threshold. Mitigation requires layered, defense-in-depth architecture spanning scrubbing, protocol-state protection, and application-layer controls, ideally applied at a distributed network edge before traffic reaches the origin.
Last updated: 2026-08-27
How a Mixed Flood Works
Why attackers combine vectors
A single-vector attack is comparatively easy to defend against once identified: a volumetric flood is absorbed by scrubbing capacity, a SYN flood is neutralized by SYN cookies, an HTTP flood is throttled by a WAF rate-limiting rule. Combining vectors changes the economics of defense in three ways:
- Resource diversification — bandwidth, kernel/firewall state tables, and application compute are each finite and independently exhaustible. Attacking all three at once forces the defender to hold capacity in reserve across every layer simultaneously, not just the one under the heaviest visible load.
- Detection dilution — security teams and automated systems often triage the most visible or highest-volume vector first. A large UDP flood can draw attention and mitigation effort while a lower-volume, harder-to-detect application-layer attack against a login or checkout endpoint proceeds underneath it.
- Mitigation sequencing gaps — some defenses are more effective when applied in a specific order (for example, absorbing volumetric traffic before protocol-level state gets a chance to build). Attackers who shift the mix of vectors over the course of an attack can force defenders to re-tune multiple systems repeatedly.
Example multi-vector attack timeline
Multi-vector DDoS attack timeline (illustrative):
T+0:00 UDP Flood begins → random-port UDP packets saturate inbound bandwidth → Layer 3/4, targets network capacity See: What Is a UDP Flood Attack?
T+0:05 ICMP Flood added → high-rate ICMP echo requests add to bandwidth pressure → also consumes router/firewall CPU processing ICMP See: What Is an ICMP Flood Attack?
T+0:10 SYN Flood begins concurrently → spoofed SYN packets target the TCP connection table → exploits capacity freed by volumetric absorption tuning See: What Is a SYN Flood Attack?
T+0:20 Defenders mitigate UDP/ICMP volume at the network edge → visible bandwidth graphs normalize → SYN flood continues, now less visible amid "resolved" alert
T+0:25 HTTP Flood launched against a specific API endpoint → low-volume, legitimate-looking requests → blends into residual traffic, evades volume-based alerting See: DDoS Attack Types (application-layer attacks)
T+0:40 TCP RESET Flood added against load balancer connection table → churns conntrack state while HTTP flood continues underneath See: What Is a TCP RESET Flood Attack?
Result: No single layer's defenses were sufficient alone; the attack's real, sustained impact came from the least-monitored vector (HTTP flood) that persisted after "the DDoS" appeared mitigatedThis is illustrative rather than a fixed template — real multi-vector campaigns vary widely in sequencing, vector selection, and duration, and some launch all vectors simultaneously rather than in stages.
Common Multi-Vector Combinations
| Combination | Layers targeted | Observed compounding effect |
|---|---|---|
| UDP Flood + SYN Flood | L3/4 bandwidth + L4 connection table | Volumetric absorption tuning can leave connection-table capacity relatively under-monitored, letting SYN flood build state undetected |
| ICMP Flood + UDP Flood | L3/4 bandwidth, router/firewall CPU | Both consume bandwidth and inline device CPU simultaneously, accelerating saturation of on-path network gear |
| Amplification (DNS/NTP) + HTTP Flood | L3/4 bandwidth + L7 application compute | Massive volumetric noise draws mitigation focus while a comparatively small, targeted HTTP flood degrades a specific application function |
| SYN Flood + TCP RESET/FIN Flood | L4 connection establishment + L4 connection teardown | Simultaneously stresses both ends of the TCP state machine, doubling the state-table churn defenders must track |
| TCP ACK-PSH Flood + HTTP Flood | L4 CPU/buffer processing + L7 application compute | Elevated baseline CPU load from ACK-PSH processing reduces headroom available to absorb the application-layer request surge |
| Volumetric + Protocol + Application (all three) | L3/4 bandwidth + L4 state tables + L7 compute | Maximum resource diversification; requires coordinated, cross-layer defense to fully mitigate |
Detection: Why Single-Vector Thresholds Fail
Traditional DDoS detection is often built around per-vector thresholds: alert if UDP traffic exceeds X Gbps, alert if SYN rate exceeds Y packets/second, alert if HTTP request rate exceeds Z requests/second per endpoint. Multi-vector attacks are specifically structured to keep each individual vector below, or only briefly above, its own threshold while the combined effect on shared infrastructure — bandwidth links, firewall CPU, load balancer connection tables, application server thread pools — exceeds capacity.
# Per-protocol packet and byte counters (useful but incomplete alone)nstat -az
# TCP state summary — correlate with UDP/ICMP volume from the same windowss -s
# Netfilter conntrack table state — shared resource across protocolsconntrack -L | wc -lcat /proc/sys/net/netfilter/nf_conntrack_count
# NetFlow/sFlow export for cross-protocol correlation at scale# (example: nfcapd/nfdump-based flow analysis)nfdump -R /flows -o extended 'proto udp or proto icmp or proto tcp' \ -s srcip/bytes -n 20
# Correlate flow records across protocols within the same time window to# detect simultaneous vector activity that no single counter reveals aloneEffective multi-vector detection depends on correlating telemetry across the network layer (NetFlow/sFlow, interface counters), transport layer (TCP state tables, conntrack), and application layer (WAF logs, request rate per endpoint) within the same time window, rather than evaluating each in isolation.
| Indicator | Single-vector view | Multi-vector correlated view |
|---|---|---|
| UDP/ICMP volume | Spikes, easily flagged | Correlated with simultaneous TCP state-table growth |
| SYN rate | May stay near threshold if volumetric noise draws mitigation focus | Rises in the same window as unrelated-looking HTTP request growth |
| HTTP request rate per endpoint | May appear within normal range in aggregate | Anomalous when isolated to a single endpoint during a volumetric event |
| Conntrack table growth | Attributed to whichever protocol is most visible | Attributable to combined SYN + FIN/RST + ACK-PSH activity when broken down by flag/protocol |
| Number of concurrent distinct vectors | Not tracked by single-vector systems | Directly tracked; itself a strong anomaly signal when it exceeds historical baseline |
Mitigation: Defense in Depth
Why layered architecture is required
No single mitigation technique addresses every vector in a mixed flood. Scrubbing and Anycast distribution absorb volumetric traffic but do nothing for a well-formed, low-volume application-layer request. SYN cookies neutralize SYN floods but have no effect on FIN, RESET, or ACK-PSH floods, let alone HTTP floods. A WAF rate-limiting rule protects specific endpoints but cannot absorb a multi-gigabit UDP flood. Effective mitigation requires each layer to run its own appropriate defense concurrently:
| Layer | Vectors addressed | Mitigation approach |
|---|---|---|
| Network (L3/4 volumetric) | UDP flood, ICMP flood, amplification | Traffic scrubbing, Anycast distribution, rate limiting at network edge |
| Transport (L4 protocol/state) | SYN, FIN, RESET, ACK-PSH floods | SYN cookies, stateful flag validation, sequence number checks, edge TCP termination |
| Application (L7) | HTTP flood, Slowloris, targeted API abuse | WAF rules, per-endpoint rate limiting, bot detection, connection timeout tuning |
| Cross-layer correlation | Combined/blended campaigns | NetFlow/sFlow correlation, SIEM integration, anomaly detection spanning all layers |
Building correlated multi-layer detection
Because the defining characteristic of a mixed flood is that no single layer’s data tells the whole story, detection architecture should:
- Aggregate telemetry from network flow records, transport-layer state counters, and application logs into a common time-series view.
- Track the number of concurrent anomalous vectors as its own metric — a rise from one to three simultaneously active anomalies is itself a stronger signal than any single vector’s magnitude.
- Avoid auto-resolving alerts the moment the most visible vector (usually the highest-bandwidth one) is mitigated; verify that transport and application-layer metrics have also returned to baseline.
- Correlate DDoS telemetry with broader security telemetry (SIEM, EDR, identity logs), since multi-vector DDoS campaigns are sometimes used as a distraction alongside other intrusion activity.
Common Mistakes
| Mistake | Impact | Correct approach |
|---|---|---|
| Declaring an attack “mitigated” once the largest vector is absorbed | Lower-volume vectors (HTTP flood, protocol floods) continue causing damage undetected | Verify all layers — network, transport, application — have returned to baseline before closing an incident |
| Tuning defenses for the historically most common vector only | Leaves other simultaneous vectors unmitigated | Maintain concurrent, layer-appropriate defenses for volumetric, protocol, and application attacks |
| Treating each protocol’s telemetry in isolation | Misses the correlated pattern that defines a multi-vector campaign | Correlate NetFlow/sFlow, TCP state, and application logs within the same time window |
| Assuming scrubbing alone is sufficient | Scrubbing addresses volumetric traffic but not protocol-state or application-layer vectors | Combine scrubbing with protocol-state protection and application-layer controls |
| Under-resourcing application-layer monitoring during a visible network-layer attack | Attackers exploit the distraction to run a targeted HTTP flood or credential-stuffing campaign | Maintain full-stack monitoring regardless of which vector is currently most visible |
How to Implement on Azion
Mixed floods require defense at every layer they touch, ideally applied before traffic reaches the origin:
- DDoS Protection provides always-on, automated detection and mitigation across volumetric and protocol-level vectors at Azion’s distributed network edge.
- Network Shield applies programmable network-layer rules using IP, CIDR, ASN, and Azion-managed lists to block sources associated with volumetric and protocol flood traffic.
- Firewall enables custom, rule-based filtering for connection-state and rate-based anomalies across TCP and UDP traffic.
- WAF addresses the application-layer component of a blended campaign, including HTTP floods and endpoint-targeted request abuse.
- WAAP combines network, protocol, and application-layer protections into a single posture, which is the architecture best suited to blended, multi-vector campaigns specifically because no single module needs to cover every layer alone.
Because Azion terminates connections and inspects traffic across distributed points of presence spanning network, transport, and application layers, a multi-vector campaign is met with the corresponding defense at each layer concurrently, rather than requiring a defender to manually stitch together separate volumetric, protocol, and application-layer tools.
Related Resources
- What Is a DDoS Attack?
- DDoS Attack Types
- What Is a SYN Flood Attack?
- What Is DDoS Protection and Mitigation?
- What Is a DDoS Botnet?
- Azion DDoS Protection
Frequently Asked Questions
What is a mixed flood or multi-vector DDoS attack? A mixed flood is a DDoS campaign that combines two or more distinct attack vectors — such as volumetric UDP or ICMP floods, protocol-level SYN or RESET floods, and application-layer HTTP floods — launched together or in sequence against a single target, to defeat defenses tuned for only one vector at a time.
Why do attackers combine vectors instead of using one large flood? Combining vectors diversifies the resources under attack (bandwidth, connection tables, application compute), dilutes detection focus toward the most visible vector, and can exploit gaps in mitigation sequencing. It often achieves more sustained impact than a single, larger flood of one type.
How is a multi-vector attack different from a simple high-volume DDoS attack? A high-volume single-vector attack, even at large scale, targets one resource type and is neutralized once that resource is protected — for example, bandwidth scrubbing for a large UDP flood. A multi-vector attack targets several resource types simultaneously, so protecting one does not resolve the others.
Can a multi-vector attack include both TCP and UDP floods at once? Yes, this is one of the most common combinations. A UDP flood saturates bandwidth while a concurrent SYN, FIN, RESET, or ACK-PSH flood targets TCP connection-state tables, forcing defenders to address both network capacity and protocol-state exhaustion at the same time.
Why do single-vector detection thresholds fail against mixed floods? Thresholds are typically set per protocol or per metric — UDP bandwidth, SYN rate, HTTP requests per second. Multi-vector attacks are structured so each individual vector stays near or under its own threshold while their combined effect on shared infrastructure exceeds capacity, so no single threshold triggers reliably.
How does correlated detection differ from standard DDoS monitoring? Correlated detection aggregates network flow data, transport-layer state counters, and application logs into a shared time-series view and tracks the number of concurrent anomalous vectors as its own signal, rather than evaluating each protocol or layer independently.
Does mitigating the largest vector in a mixed flood mean the attack is over? Not necessarily. Attackers sometimes rely on defenders declaring victory once the most visible, highest-bandwidth vector is absorbed, while a lower-volume protocol or application-layer vector continues to cause damage. Full mitigation requires verifying that every layer has returned to baseline.
What is the relationship between multi-vector DDoS and DDoS botnets? Botnets provide the distributed source infrastructure that makes launching multiple simultaneous vectors practical at scale — different subsets of compromised devices can be tasked with different vectors (UDP flood from one segment, HTTP flood from another) under coordinated command-and-control.
Can amplification attacks be part of a multi-vector campaign? Yes. DNS, NTP, or other amplification techniques are frequently used as the volumetric component of a blended attack, paired with a protocol-level flood (like SYN flood) or an application-layer attack aimed at a specific endpoint.
What architecture best defends against multi-vector DDoS attacks? A layered, defense-in-depth architecture that applies volumetric scrubbing, protocol-state protection (such as SYN cookies and stateful flag validation), and application-layer controls (WAF, rate limiting) concurrently, ideally at a distributed network edge that inspects traffic across all layers before it reaches the origin.
Sources:
- CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”
- NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.
- NIST. “Guide to DDoS Attacks.” SP 800-83.
- IETF. “Transmission Control Protocol (TCP).” RFC 9293. 2022.
- IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP 38). 2000.