What Is a Mixed Flood (Multi-Vector DDoS Attack)?

Learn how mixed flood, or multi-vector, DDoS attacks combine two or more protocols such as UDP, TCP, and ICMP simultaneously to defeat single-vector defenses, and how to detect and mitigate blended attack campaigns.

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:

  1. 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.
  2. 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.
  3. 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 mitigated

This 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

CombinationLayers targetedObserved compounding effect
UDP Flood + SYN FloodL3/4 bandwidth + L4 connection tableVolumetric absorption tuning can leave connection-table capacity relatively under-monitored, letting SYN flood build state undetected
ICMP Flood + UDP FloodL3/4 bandwidth, router/firewall CPUBoth consume bandwidth and inline device CPU simultaneously, accelerating saturation of on-path network gear
Amplification (DNS/NTP) + HTTP FloodL3/4 bandwidth + L7 application computeMassive volumetric noise draws mitigation focus while a comparatively small, targeted HTTP flood degrades a specific application function
SYN Flood + TCP RESET/FIN FloodL4 connection establishment + L4 connection teardownSimultaneously stresses both ends of the TCP state machine, doubling the state-table churn defenders must track
TCP ACK-PSH Flood + HTTP FloodL4 CPU/buffer processing + L7 application computeElevated 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 computeMaximum 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.

Terminal window
# Per-protocol packet and byte counters (useful but incomplete alone)
nstat -az
# TCP state summary — correlate with UDP/ICMP volume from the same window
ss -s
# Netfilter conntrack table state — shared resource across protocols
conntrack -L | wc -l
cat /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 alone

Effective 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.

IndicatorSingle-vector viewMulti-vector correlated view
UDP/ICMP volumeSpikes, easily flaggedCorrelated with simultaneous TCP state-table growth
SYN rateMay stay near threshold if volumetric noise draws mitigation focusRises in the same window as unrelated-looking HTTP request growth
HTTP request rate per endpointMay appear within normal range in aggregateAnomalous when isolated to a single endpoint during a volumetric event
Conntrack table growthAttributed to whichever protocol is most visibleAttributable to combined SYN + FIN/RST + ACK-PSH activity when broken down by flag/protocol
Number of concurrent distinct vectorsNot tracked by single-vector systemsDirectly 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:

LayerVectors addressedMitigation approach
Network (L3/4 volumetric)UDP flood, ICMP flood, amplificationTraffic scrubbing, Anycast distribution, rate limiting at network edge
Transport (L4 protocol/state)SYN, FIN, RESET, ACK-PSH floodsSYN cookies, stateful flag validation, sequence number checks, edge TCP termination
Application (L7)HTTP flood, Slowloris, targeted API abuseWAF rules, per-endpoint rate limiting, bot detection, connection timeout tuning
Cross-layer correlationCombined/blended campaignsNetFlow/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:

  1. Aggregate telemetry from network flow records, transport-layer state counters, and application logs into a common time-series view.
  2. 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.
  3. 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.
  4. 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

MistakeImpactCorrect approach
Declaring an attack “mitigated” once the largest vector is absorbedLower-volume vectors (HTTP flood, protocol floods) continue causing damage undetectedVerify all layers — network, transport, application — have returned to baseline before closing an incident
Tuning defenses for the historically most common vector onlyLeaves other simultaneous vectors unmitigatedMaintain concurrent, layer-appropriate defenses for volumetric, protocol, and application attacks
Treating each protocol’s telemetry in isolationMisses the correlated pattern that defines a multi-vector campaignCorrelate NetFlow/sFlow, TCP state, and application logs within the same time window
Assuming scrubbing alone is sufficientScrubbing addresses volumetric traffic but not protocol-state or application-layer vectorsCombine scrubbing with protocol-state protection and application-layer controls
Under-resourcing application-layer monitoring during a visible network-layer attackAttackers exploit the distraction to run a targeted HTTP flood or credential-stuffing campaignMaintain 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.

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.
stay up to date

Subscribe to our Newsletter

Get the latest product updates, event highlights, and tech industry insights delivered to your inbox.