Why attackers use multiple vectors
A single-vector DDoS attack has a straightforward mitigation: identify the protocol, write a rule to drop traffic matching that protocol's characteristics, and push it. An NTP amplification attack is mitigated by blocking UDP traffic with source port 123 above a size threshold. A SYN flood is mitigated by rate-limiting SYN packets or blocking the dominant source prefix. Neither is trivial, but each has a well-understood countermeasure.
Multi-vector attacks are harder to stop not because the vectors are individually more sophisticated, but because the combination creates two simultaneous problems that require two different solutions. While you are addressing the amplification traffic, the SYN flood continues. While you are writing the SYN flood rule, the amplification traffic is saturating the uplink. The two vectors are not independent problems; they are coordinated to maximize the window during which at least one vector is causing damage.
The Lorikeet Security incident on March 27, 2026 provides a concrete example. The attack combined NTP amplification (39 Gbps, 1.06M PPS, 2,140 reflectors) with a SYN flood (9 Gbps, 890K SYN/s, 18,400 spoofed source IPs). Peak combined volume was 48.3 Gbps. Neither vector needed to be that large to cause serious damage on its own, but the combination meant that any single-rule mitigation approach would have left one vector active.
NTP amplification: how it works
NTP (Network Time Protocol) runs on UDP port 123 and is essential infrastructure for synchronized clocks across the internet. The vulnerability exploited in NTP amplification attacks is the monlist command, a mode 7 request (opcode 42) that asks an NTP server to return a list of the last 600 clients that queried it.
The amplification attack works as follows. The attacker sends small UDP packets (approximately 46 bytes) to open NTP servers with the source IP address spoofed to the victim's IP address. Each NTP server, seeing what it believes is a legitimate monlist request from the victim, sends its response directly to the victim. The monlist response can contain up to 100 records per packet, delivered in up to 6 UDP responses averaging 468 bytes each. The amplification factor is approximately 550x: a 46-byte request generates roughly 2,800 bytes of responses.
With 2,140 open NTP reflectors sending simultaneous responses to a single target, the inbound bandwidth quickly reaches tens of gigabits per second. In the Lorikeet incident, 2,140 reflectors produced 39 Gbps at 1.06M PPS. The reflectors are not compromised machines; they are legitimately operating NTP servers with older daemon versions that still respond to monlist requests. Patches and configuration changes to disable mode 7 responses have significantly reduced the open NTP reflector population since the technique was widely exploited around 2014, but a large enough population of unpatched servers remains to enable attacks of this scale.
NTP amplification vs DNS amplification: Both exploit UDP's connectionless nature to reflect and amplify traffic. DNS amplification uses recursive DNS resolvers (amplification factor 28–54x for ANY queries). NTP amplification using monlist has a higher amplification factor (~550x) but requires a smaller pool of responsive servers. DNS amplification can achieve higher total volume due to the much larger population of open resolvers. For this reason, DDoS-for-hire services often combine both, or substitute DNS for NTP when open NTP reflector populations are depleted in a geographic region.
SYN flood: how it works
TCP's three-way handshake (SYN, SYN-ACK, ACK) requires the receiving server to maintain connection state between the SYN and the final ACK. When the server receives a SYN, it allocates a Transmission Control Block (TCB) in the kernel's connection state table, records the connection parameters, sends a SYN-ACK, and waits for the ACK to complete the handshake. This wait period is bounded by the SYN timeout.
A SYN flood exploits this by sending SYN packets with spoofed source IP addresses at very high rate. The server sends SYN-ACK responses to the spoofed (non-existent) addresses, which are either dropped or sent to machines that respond with RST (if the address exists). Either way, no ACK arrives to complete the handshake. The server's connection state table fills with half-open connections waiting to time out. Once the state table is exhausted, the server cannot accept new legitimate connections because it has no space to track the handshake state for them.
This is state table exhaustion: a resource exhaustion attack rather than a bandwidth saturation attack. The server does not need to be overwhelmed by traffic volume. It needs only to receive SYN packets faster than half-open connections time out. At 890K SYN/s with a default SYN timeout of 120 seconds, the number of half-open connections trying to accumulate vastly exceeds any practical state table size.
In the Lorikeet incident, the SYN flood used IP spoofing with near-maximum source entropy (0.87), generating 18,400 apparent source IPs from approximately 4 actual sending machines (identified by TTL analysis). The target ports were 443 and 8443, which are the HTTPS ports for Lorikeet's training platform and CTF server. The attack was specifically targeting the ports handling participant connections.
Why the combination is harder to stop
The NTP amplification and SYN flood in the Lorikeet attack address two different failure modes simultaneously:
- Bandwidth saturation (NTP amplification): 39 Gbps of UDP traffic saturates any uplink that isn't multiply over-provisioned. Even if the server's application layer is functioning, if the uplink is full, legitimate packets cannot reach the server.
- State table exhaustion (SYN flood): 890K SYN/s exhausts the kernel's TCP connection state table. Even if bandwidth is available, the server cannot establish new legitimate TCP connections.
A mitigation response that addresses only one vector leaves the other operating. If you push a FlowSpec rule that drops all UDP/123 traffic (addressing the NTP amplification), the SYN flood continues exhausting the state table. If you push a SYN rate limit (addressing the SYN flood), the NTP amplification continues saturating the uplink. Both vectors must be addressed simultaneously with independent rules targeting each vector's specific protocol and packet characteristics.
Why threshold-based detection fails multi-vector attacks
Many DDoS detection systems operate on simple thresholds: if PPS exceeds X, or bandwidth exceeds Y, fire an alert. This approach has a specific failure mode with multi-vector attacks: each vector may be deliberately sized to stay below the individual threshold, even while the combined effect achieves the attacker's goal.
Consider an organization with these detection thresholds: UDP traffic alert at 30 Gbps, TCP SYN rate alert at 1M SYN/s, total bandwidth alert at 40 Gbps. A 39 Gbps NTP amplification attack combined with a 9 Gbps SYN flood produces: 39 Gbps UDP (above the 30 Gbps UDP threshold, so this specific combination would trigger), but if the attacker sizes the NTP component to 28 Gbps and the SYN component to 700K SYN/s, neither vector breaches its individual threshold. The combined effect of 28 Gbps + 700K SYN/s simultaneously saturates bandwidth and exhausts state tables, but no alert fires.
The threshold evasion problem: Experienced attackers calibrate attack volume specifically to stay near but below static thresholds. If they observe that your service degrades at a certain bandwidth level without triggering your alerts, they will run continuous attacks sized just below your detection threshold. These sub-threshold attacks do not trigger your response, but they do degrade your service, exhaust your SLA allowances, and accumulate business impact over time. Dynamic baselines that detect deviations from normal behavior (rather than absolute thresholds) are significantly harder to evade because the attacker would need to stay below your normal traffic level, which means not attacking effectively at all.
How Flowtriq correlated both vectors in 0.9 seconds
Flowtriq's detection runs per-protocol analysis in parallel within each measurement window. Rather than applying a single aggregate threshold to total traffic, the detection engine analyzes UDP and TCP traffic independently and simultaneously. The NTP amplification signature (high UDP PPS from many source IPs, source port 123, large average packet size, high source IP entropy) and the SYN flood signature (high TCP SYN rate, SYN-only packets, spoofed source IPs, target port concentration) are evaluated in the same cycle.
Both anomalies were flagged at T+0.9s: the NTP amplification on the training platform node (PPS jump from 14,200 to 312,000 in one window) and the SYN flood on the CTF server node (SYN rate spike to 890K SYN/s). A single incident was created covering both vectors, with independent mitigation rules queued for each. The Slack alert at T+3s described both vectors and both affected nodes.
This parallel classification is critical for the subsequent mitigation steps. Because both vectors were classified simultaneously, the engineer's one-click action at T+11s triggered the correct FlowSpec rules for both vectors, with appropriate rule sequencing (NTP rule first due to volume dominance, SYN rule pushed 8 seconds later). A sequential classification model would have classified one vector, pushed its rule, observed that the attack continued, then classified the second vector. This sequential approach adds minutes to the time-to-full-mitigation for multi-vector attacks.
FlowSpec rules for each vector
The two FlowSpec rules pushed during the Lorikeet incident illustrate the independent targeting required for multi-vector mitigation:
Rule 1 (NTP amplification, T+11s):
match source-port 123 protocol udp packet-length >= 400 action traffic-rate 0
Rule 2 (SYN flood, T+19s):
match source-prefix [dominant /24] protocol tcp tcp-flags syn destination-port 443 8443 action traffic-rate 0
Neither rule would have addressed the other vector. The UDP/123 rule has no effect on TCP SYN packets. The source-prefix SYN rule has no effect on UDP NTP traffic. Both were required, and both targeted the minimum necessary traffic to avoid disrupting legitimate services: legitimate NTP sync traffic (small UDP/123 packets) passes through Rule 1 due to the packet-length qualifier; legitimate HTTPS traffic from non-attack source prefixes passes through Rule 2.
What the 4 unique TTLs revealed
One of the most practically useful findings from the PCAP forensic analysis was the TTL distribution of the SYN flood packets. Despite 18,400 apparent source IPs (all spoofed), the TCP SYN packets showed only 4 unique TTL values: 57, 58, 113, and 114.
Initial TTL values on most operating systems are 64, 128, or 255. A packet with a received TTL of 57 started with TTL 64 and traversed 7 hops. A packet with received TTL 58 traversed 6 hops from a 64-initial-TTL host. TTLs of 113 and 114 correspond to 128-initial-TTL hosts at 15 and 14 hops respectively. This gives us 4 real machines (or small clusters behind the same hop counts) generating all the spoofed traffic. The attacker used 2 to 4 VPS or dedicated server nodes to produce the entire SYN flood component, randomizing source IPs in software while the true packet origin remained constant enough to show in TTL analysis.
This is directly useful for upstream abuse reports. Rather than reporting 18,400 source IPs (all spoofed and therefore useless), you can report 2 to 4 specific network paths identified by their TTL signatures, significantly narrowing the upstream investigation scope.
Detect multi-vector attacks in under one second
Flowtriq classifies all attack vectors simultaneously in a single detection cycle. Parallel mitigation rules, BGP FlowSpec, and PCAP forensics. Starting at $9.99/node/month.
Start Free Trial →No credit card required · 7-day free trial