Multi-vector DDoS: why your
single-protocol detection fails

Back to Blog

The Evolution of DDoS Attacks

In the early days of DDoS, attacks were simple: a botnet of compromised machines would flood a target with as much UDP or ICMP traffic as possible. Detection was equally simple: if inbound PPS exceeded a threshold, you were under attack. Defense meant rate-limiting the offending protocol and waiting for the attacker to give up.

Modern attackers have evolved well beyond single-vector floods. A typical sophisticated DDoS attack in 2025 uses multiple protocols simultaneously or in rapid succession, with each vector designed to exploit a different weakness in the target's defenses. The goal is not just volumetric overwhelming but systematic evasion of detection and mitigation systems that are tuned for single-protocol attacks.

Anatomy of a Multi-Vector Attack

A multi-vector attack typically unfolds in phases, each designed to compound the damage of the previous one. Here is a real-world pattern we have observed through Flowtriq deployments:

Phase 1: Volumetric UDP Flood (0-5 minutes)

The attack begins with a high-bandwidth UDP flood, often using DNS or NTP amplification. The purpose is twofold: saturate the target's inbound bandwidth and trigger the first-line defense. Most organizations have automated mitigation for UDP floods (upstream scrubbing, null-routes, or CDN absorption). The attacker expects this mitigation to activate within minutes.

Phase 2: SYN Flood (5-15 minutes)

Once the UDP mitigation is in place, the attacker shifts to a SYN flood targeting the same IP. The UDP scrubbing rules do not affect TCP traffic, so the SYN flood bypasses the first mitigation entirely. The target now has to activate a second mitigation path, which requires additional coordination with the upstream provider. Meanwhile, the server's connection table is under assault.

Phase 3: HTTP Application Layer (15-30 minutes)

With the operations team focused on network-layer mitigation, the attacker launches an HTTP flood. These are valid, complete HTTP requests that pass through all network-level filters because they look like legitimate web traffic. The requests are designed to be computationally expensive: complex search queries, large file downloads, or API endpoints that trigger database operations. The web server or application backend becomes overwhelmed even though the network-layer attack has been mitigated.

Phase 4: Rotation and Replay

The attacker cycles back through the vectors, sometimes combining two simultaneously. A UDP flood combined with an HTTP slowloris attack forces the defender to fight on two fronts at different layers of the stack. Each time a vector is mitigated, another activates, creating a continuous state of incident response that exhausts the human operators as much as the infrastructure.

Multi-vector attacks are not just technically sophisticated. They are operationally sophisticated. The attacker's goal is to exhaust your team's capacity to respond, creating windows where mitigation gaps exist.

Why Single-Protocol Detection Fails

Traditional DDoS detection systems monitor specific protocols independently. They have a UDP flood detector, a SYN flood detector, and maybe an HTTP anomaly detector. Each operates in isolation with its own thresholds and baselines. This architecture has several critical blind spots:

• Sub-threshold vectors. When an attacker splits bandwidth across three protocols simultaneously, each individual vector might fall below its protocol-specific detection threshold. A 3 Gbps attack split evenly across UDP, TCP SYN, and HTTP means each vector is only 1 Gbps, which might not trigger detection on a server with a 10 Gbps link and thresholds set at 2 Gbps per protocol.
• Detection gaps during transitions. When the attacker switches from UDP to TCP, the UDP detector sees traffic return to normal and may close the alert. The TCP detector has not yet triggered because the SYN flood is still ramping up. There is a window of seconds to minutes where no active alert exists despite the attack continuing.
• Separate escalation paths. Each protocol detector may alert different teams or create separate incidents. The network team handles the UDP flood while the application team handles the HTTP flood, and neither team has visibility into the full picture. Coordination failures delay effective mitigation.
• Baseline poisoning. A slow-ramping multi-vector attack can gradually shift the baselines of each individual detector. If the attacker increases traffic by 5% every hour across all protocols, the dynamic baselines absorb the increase as normal, and the attack reaches damaging levels without ever triggering an alert.

How Flowtriq Detects Multi-Vector Attacks

Flowtriq's detection engine was designed from the beginning to handle multi-vector attacks. Instead of running independent per-protocol detectors, Flowtriq uses a correlated detection model that considers all traffic metrics simultaneously.

Composite Anomaly Scoring

Flowtriq computes an anomaly score for each metric independently (PPS, BPS, SYN rate, UDP ratio, fragmentation rate, and others), then combines them into a composite score. The composite score uses a weighted sum where metrics that are currently deviating from baseline contribute more weight. This means that three metrics each deviating by 2x from baseline can produce a higher composite score than a single metric deviating by 4x.

# Simplified composite scoring
score = 0
for metric in [pps, bps, syn_rate, udp_ratio, frag_rate]:
    deviation = current[metric] / baseline[metric]
    if deviation > 1.5:
        score += weight[metric] * log2(deviation)

if score > threshold:
    fire_alert(severity=classify(score))

This approach catches sub-threshold multi-vector attacks that would evade per-protocol detection. Even when no single metric is alarming on its own, the combination of multiple moderate deviations triggers detection.

Attack Session Correlation

When Flowtriq detects an anomaly, it opens an "attack session" that tracks the event across protocol transitions. If a UDP flood alert fires and then UDP traffic drops while SYN traffic spikes, Flowtriq correlates both events into a single attack session rather than closing the first alert and opening a new one. The alert in PagerDuty, Slack, or Discord is updated with the new vector information rather than creating a new incident.

This correlation is critical for operational response because it ensures the on-call engineer sees one evolving incident rather than a series of disconnected alerts. The attack session timeline in the Flowtriq dashboard shows every vector transition, making it easy to understand the attacker's strategy and predict what might come next.

Rate-of-Change Detection

To counter baseline poisoning from slow-ramp attacks, Flowtriq monitors the rate of change across all metrics, not just their absolute values. A sustained increase of 5% per hour across three protocols simultaneously is itself an anomaly, even if the absolute values remain within baseline. The rate-of-change detector flags these patterns with a "slow ramp" classification so operators can investigate before the traffic reaches damaging levels.

Defending Against Multi-Vector Attacks

Detection is only the first step. Effective defense against multi-vector attacks requires a layered mitigation strategy:

1. Upstream scrubbing for volumetric vectors. Work with your ISP or DDoS mitigation provider to filter high-bandwidth UDP and TCP floods before they reach your network. Flowtriq's webhook integration can automatically trigger scrubbing via your provider's API.
2. Host-level rate limiting for connection floods. Use iptables or nftables rules to limit SYN rates and drop invalid packets at the kernel level. Flowtriq's alert includes recommended iptables rules based on the specific attack pattern observed.
3. Application-layer protection for HTTP floods. Deploy a WAF or reverse proxy with rate limiting, challenge pages (CAPTCHAs), and bot detection. The HTTP vector is the hardest to mitigate because it requires distinguishing malicious requests from legitimate ones.
4. Automated response playbooks. Pre-build mitigation scripts for each attack type so that when Flowtriq detects a new vector, the corresponding mitigation activates within seconds rather than waiting for manual intervention.

Multi-vector detection is available on all Flowtriq plans starting at $9.99/mo per node. The composite scoring engine runs locally on each agent with zero configuration required. Start your free trial and test multi-vector detection on your infrastructure.

Back to Blog

Related Articles