Background and context
On March 27, 2026 at 09:52:14 EST, a coordinated multi-vector DDoS attack hit Lorikeet Security's dedicated bare-metal event infrastructure during a live cybersecurity training session with 240 active participants. The attack peaked at 48.3 Gbps and 1.1 million packets per second, combining two distinct vectors with separate botnet/reflector infrastructure. Flowtriq detected it in 0.9 seconds and had the full upstream mitigation stack active in 11 seconds. Not one participant was disconnected.
This post is a complete technical post-mortem intended for network engineers and security researchers. It covers the PCAP analysis methodology, reflector distribution for the NTP component, source entropy analysis for the SYN flood, the exact FlowSpec rules that fired and their BGP encoding, and the forensic indicators that revealed separate attack infrastructure for each vector.
Attack vector breakdown
Vector 1: NTP Amplification
Vector 2: TCP SYN Flood
PCAP forensic analysis
NTP amplification: reflector distribution
The NTP amplification component used 2,140 unique source IPs acting as open NTP reflectors. These are servers running NTP daemon versions that still respond to the monlist command (NTP mode 7, request code 42), which returns a list of the last 600 hosts that queried the server. Each reflector was sent a small spoofed request (forged source IP: Lorikeet's target address) and returned a disproportionately large response directly to the target.
The amplification factor for NTP monlist abuse is approximately 550x: a 46-byte request generates up to 48 UDP responses averaging 468 bytes each in the Lorikeet capture. With 2,140 reflectors generating simultaneous responses, this produces the 39 Gbps / 1.06M PPS peak observed at the target node.
Reflector geographic distribution by source AS confirmed the typical NTP amplification profile: China Telecom (AS4134) accounted for approximately 19% of reflector IPs, CNCGROUP (AS4837) for 14%, with Korean, Brazilian, and US-origin reflectors filling the remainder. This distribution is consistent with known open NTP resolver populations, not with a botnet. The reflectors are not compromised; they are misconfigured servers that simply respond to monlist requests as designed. Source TTL analysis showed a narrow TTL distribution consistent with a fixed reflector pool: 18 of the 2,140 source IPs showed TTL values of 55, 56, 111, or 112, which maps to 64 and 128 initial TTLs at 8-9 and 16-17 hop distances respectively.
SYN flood: source entropy and spoofing detection
The SYN flood component presented a very different source IP profile. Source IP entropy for the NTP amplification component was 0.31, consistent with a fixed reflector pool (low entropy means the addresses are concentrated in a small set). Source IP entropy for the SYN flood was 0.87, indicating near-maximum randomization. This is the signature of IP spoofing: addresses are being generated pseudo-randomly, not drawn from a real botnet.
Confirmation came from two additional PCAP indicators. First, no TCP SYN-ACK packets from the target were followed by ACK completions: all 890,000 SYN/s connections were half-open, exactly what spoofed source addresses produce (the SYN-ACK is sent to a random address that did not originate the SYN, so no ACK ever returns). Second, packet TTL distribution for the SYN flood showed only 4 unique TTL values (57, 58, 113, 114), despite 18,400 apparent source IPs. If these were real distributed sources, you would expect TTL variance across dozens of values. Four values from 18,400 IPs means a small number of actual sending hosts generating packets with randomized source fields but consistent TTL from each real source.
The 4 unique TTL values map to approximately 2 to 4 actual sending infrastructure nodes, each generating spoofed packets at high rate from a consistent hop distance. This is characteristic of rented botnet or VPS-based flooding infrastructure, not a broadly distributed botnet. The SYN component required far less infrastructure to achieve its 9 Gbps / 890K SYN/s rate due to IP spoofing: small packet sizes (60 bytes) and high line rate from a few high-bandwidth nodes.
What 4 unique TTLs in a SYN flood means for attribution: IP spoofing makes source IP attribution useless, but TTL analysis cuts through the noise. Each sending host has a fixed initial TTL (64, 128, or 255 on most operating systems) and a fixed hop count to the target. The resulting received TTL is consistent per real source regardless of the spoofed source IP. Finding 4 unique TTL values across 18,400 apparent source IPs means 4 real sending machines. This is useful for upstream ISP abuse reports: you know to report 4 specific ASNs rather than chasing 18,400 spoofed IPs.
Multi-vector correlation: separate infrastructure confirmed
The PCAP analysis confirmed that the two vectors were launched from separate infrastructure. The NTP amplification used a fixed reflector pool (entropy 0.31) with TTL values indicating real geographic diversity. The SYN flood used spoofed sources (entropy 0.87) with only 4 unique TTLs indicating a small number of actual senders. The timing correlation shows the two vectors started within 2 seconds of each other, indicating coordinated launch but from operationally separate components. This is the typical DDoS-for-hire model: the customer specifies a target and duration, and the service uses separate infrastructure for amplification and direct flooding to maximize total volume while complicating single-rule mitigation.
The FlowSpec rules that fired
Flowtriq pushed two BGP FlowSpec rules to Lorikeet's upstream transit provider, each targeting one vector independently.
Rule 1: NTP amplification (T+11s)
The first rule targeted the amplification traffic by source port. NTP reflectors respond from source port 123; legitimate NTP servers rarely send high-volume traffic from port 123 to arbitrary non-NTP destinations. The FlowSpec rule encoded in BGP NLRI (SAFI 133) was:
match: source-port: = 123 protocol: udp packet-length: >= 400 action: traffic-rate: 0 (discard)
The packet-length qualifier (>= 400) was added to avoid discarding legitimate NTP sync traffic, which uses much smaller packets. NTP monlist responses average 468 bytes; normal NTP sync traffic is 48 to 76 bytes. The combined match (source port 123, UDP, packet >= 400 bytes) produces a near-zero false positive rate against normal NTP usage while dropping essentially all monlist reflection traffic.
Rule 2: SYN flood source prefix (T+19s)
The SYN flood required a different approach. Since source IPs were spoofed, port-based or IP-based matching was not effective. The 4-TTL analysis pointed to specific originating ASNs. The second FlowSpec rule targeted the dominant source prefix contributing the highest SYN rate:
match: source-prefix: [dominant /24 subnet from TTL analysis] protocol: tcp tcp-flags: syn && !ack destination-port: = 443, = 8443 action: traffic-rate: 0 (discard)
The tcp-flags: syn && !ack qualifier ensures only SYN-only packets (not legitimate SYN-ACK or established connection traffic) are matched. The destination port qualifiers limit the rule to the attack's target ports. Within 4 seconds of the second rule being pushed, the SYN/s rate on the CTF server dropped from 890,000 to under 200 SYN/s, well within the normal range for a server handling 240 HTTPS connections.
Why FlowSpec requires two rules for a two-vector attack: BGP FlowSpec rules match on a specific set of packet header fields. A single rule can match multiple fields with AND logic, but it cannot express "match traffic that looks like NTP amplification OR traffic that looks like a SYN flood" in a single BGP NLRI. Multi-vector attacks require one rule per vector, each targeting the specific protocol and packet characteristics of that vector. A single port-blocking rule for UDP/123 would have done nothing to the SYN flood, and a TCP SYN rule would have done nothing to the UDP amplification traffic. Parallel classification of both vectors is required before you can write the right rules.
Second-by-second incident timeline
PCAP indicators and forensic methodology
Flowtriq automatically triggers a PCAP capture at incident detection. The resulting capture file from the Lorikeet incident contained the following forensically significant characteristics:
- Avg packet length 392 bytes: This is a weighted average combining NTP amplification packets (468 bytes) and SYN packets (60 bytes), with the NTP component dominating by volume. A pure SYN flood would show ~60 bytes average; a pure NTP flood would show ~468 bytes. The 392-byte weighted average is itself a multi-vector indicator.
- Packet length distribution: bimodal: The histogram shows two distinct peaks at 60 bytes and 468 bytes with very little volume between them. This bimodal distribution is a strong indicator of simultaneous multi-vector attack rather than a single-vector attack with variable packet sizes.
- Source IP entropy: 0.87 overall: The combined source entropy is high because the SYN flood's random spoofing dominates. Computing entropy per-protocol (UDP vs TCP) separates the picture: UDP entropy 0.31 (fixed reflector pool), TCP entropy 0.87 (randomized spoofing).
- 4 unique TTL values across all TCP traffic: As described above, this reveals the actual sending infrastructure size for the SYN flood component.
- Zero TCP ACK completions for SYN traffic: All 890K SYN/s resulted in SYN-ACK responses sent to random/non-existent addresses, none of which returned ACKs. This is conclusive evidence of spoofed source addresses.
- NTP payload inspection: mode 7 opcode 42: Random sampling of UDP/123 packets confirms NTP monlist response format. Response packets contain the monlist data structure (arrays of peer IP records), not normal NTP sync exchanges.
- IOC matches: 5 pattern matches against Flowtriq's attack signature database: NTP_MON_GETLIST (abuse.ch, 93% confidence), NTP Monlist Request (93%), TCP SYN-only Flood (86%), AS4134 as DDoS-source ASN (62%), AS4837 as DDoS-source ASN (58%).
Why parallel classification is required for multi-vector attacks
A detection system that classifies attack vectors sequentially has a structural problem with multi-vector incidents: the classification of the first vector consumes time that the second vector is still escalating. By the time both vectors are classified, the mitigation for the first vector is being pushed while the second continues unmitigated.
Flowtriq's classification runs per-protocol in parallel. The UDP anomaly analysis (NTP amplification) and the TCP SYN rate analysis (SYN flood) run in the same detection cycle, not serially. Both are classified and both mitigation rules are queued within the same 0.9-second window. The difference in implementation time for the two FlowSpec rules (T+11s for rule 1, T+19s for rule 2) reflects the time required for the engineer's one-click activation and BGP propagation, not classification lag.
For this attack specifically, the NTP amplification component was the primary volume driver (39 Gbps of the 48.3 Gbps total). Addressing it first was the correct priority ordering. But the system had already classified the SYN flood simultaneously, so the follow-up rule was ready to push immediately after the first rule propagated.
Post-incident FlowSpec rule withdrawal: One detail worth noting for network engineers: FlowSpec rules should not be left in place indefinitely. After the attack subsided at T+38min, Flowtriq withdrew both FlowSpec rules via a single BGP UPDATE message with route withdrawals for both NLRI entries. Leaving FlowSpec rules in place after an attack ends risks false-positive drops on legitimate traffic that happens to match the rule criteria (legitimate NTP servers on port 123 with large responses, for example). Automated withdrawal after attack resolution is part of Flowtriq's incident lifecycle management.
Get sub-second detection and automatic FlowSpec for your infrastructure
Flowtriq deploys in under two minutes per node. Multi-vector detection, BGP FlowSpec, PCAP capture, and instant alerts. Starting at $9.99/node/month.
Start Free Trial →No credit card required · 7-day free trial