Home/ Blog/ Lorikeet Security Case Study
Customer Case Study
Case Study Apr 23, 2026 8 min read
A multi-vector DDoS attack hit Lorikeet Security's live cybersecurity training event 45 minutes in. Flowtriq detected it in 0.9 seconds, activated BGP FlowSpec and cloud scrubbing upstream simultaneously, and kept all 240 attendees connected for the remaining two hours.
Lorikeet Security
Orlando, FL 3 Flowtriq nodes 15,000+ trained 50+ events
Penetration testing, red team operations, and live hands-on cyber training events for enterprise security teams, government contractors, and university programs
0.9s
Time to detection
11s
Detection to full upstream mitigation
0
Student disconnections
48 Gbps
Peak attack volume
Flowtriq incident #158 — Critical / Resolved · 48.3 Gbps peak · 1.1M PPS · 20,540 source IPs · 94% AI confidence · Node: Lorikeet Security
Lorikeet Security is a cybersecurity firm based in Orlando, Florida specializing in penetration testing, red team operations, compliance consulting, and live cyber training events. Founded by Ryan Wilke in 2021, the company has grown from a single CTF training platform (originally launched as Parrot CTFs) into a full-spectrum offensive security and training operation, with 50+ events hosted and over 15,000 participants trained to date.
Lorikeet Security training events deliver live CTF competitions and hands-on labs across web exploitation, reverse engineering, cryptography, active directory, and forensics. Events range from 200-person corporate workshops to 1,000-person conference competitions, each running against dedicated isolated infrastructure with per-team VPN access and no shared resources. With a 99.9% uptime record across 50+ events, infrastructure reliability is a core part of Lorikeet's offering, and something their clients explicitly rely on.
Lorikeet's training event infrastructure runs on a cluster of dedicated bare-metal servers handling three distinct workloads: the challenge platform (scenarios, labs, scoring engine), a CTF server running intentionally vulnerable environments for participants, and a media relay node for the instructor's live session. During an event, all three nodes are under simultaneous load from participants' VPN connections; there is no graceful degradation. If any node saturates, the session stops.
Prior to deploying Flowtriq, Lorikeet had no automated DDoS detection in place. When connectivity degraded during an event, the response was entirely manual: identify the issue, determine the right rule, coordinate with the upstream provider. By the time that cycle completed, the damage was already done.
"We'd had events where connectivity would get weird and we'd spend ten minutes just figuring out if it was our stack or the network. With two hundred-plus people connected and a training schedule running, that ten minutes is real damage. You can't get that time back once a session goes sideways."
Ryan Wilke, CEO & Founder, Lorikeet Security
| Capability | FastNetMon CE [1] | Wanguard | Arbor / NETSCOUT | Flowtriq |
|---|---|---|---|---|
| Detection granularity | Flow-based, threshold (30–60s) [1] | Flow-based (30–60s) | Flow-based (30s+) | Per-second (<1s) |
| BGP FlowSpec | Advanced only — not in CE [1] | Add-on module | Yes (enterprise tier) | Included, all plans |
| Cloud scrubbing integration | No [1] | Manual config | Vendor-specific | Built-in, one-click |
| Auto upstream mitigation | BGP blackhole (RTBH) via ExaBGP [1] | Partial | Yes | Yes, or one-click |
| Multi-vector co-detection | No [1] | Sequential | Yes | Yes, single cycle |
| Upstream coordination | Blackhole only — no scrubbing automation [1] | Partial automation | Often manual | Fully automated |
| Time to deploy | Hours–days (dedicated server + flow infra required) [2] | Days (on-prem appliance) | Days–weeks | ~2 min/node |
Publicly announced events are a known DDoS targeting surface.
Lorikeet's training events are listed on a public schedule with exact dates, times, and registration pages. That is all an attacker needs to time a volumetric hit for maximum impact: peak participant load, mid-session, when any outage has the most visible and irreversible cost. Live events, public product launches, conference streams, and scheduled maintenance windows all share this pattern. The attack window is predictable, and the cost of downtime is highest precisely when the event is running. Any operator hosting publicly announced events on dedicated infrastructure should treat the public schedule itself as part of the threat model.
Flowtriq was deployed across all three Lorikeet nodes in approximately 10 minutes during a pre-event infrastructure check the week before March 27. The ftagent installed on each node, spent roughly five minutes learning each node's baseline traffic profile, and had both the BGP FlowSpec adapter and cloud scrubbing integrations confirmed active before the event went live.
The event in question was a March 27, 2026 public live cybersecurity training event, a full-day hands-on session running from 09:00–17:00 EST with approximately 240 registered participants. The curriculum covered active network threat identification, live packet analysis, and escalating incident response scenarios, all running against Lorikeet's dedicated infrastructure. By 09:45, all three nodes were under typical event load: steady streams from participants' VPN connections, scoring engine calls, and the instructor livestream.
At 09:52:14, the attack began.
!
T+0s / 09:52:14
Flowtriq detects anomaly
The ftagent on the training platform node detects a sharp PPS deviation: inbound packets jump from a 14,200 PPS baseline to 312,000 PPS in a single measurement window. Simultaneously, the CTF server node registers an inbound SYN rate spike. Both anomalies are flagged within the same 0.9-second detection cycle.
S
T+3s / 09:52:17
Slack alert fires
Flowtriq pushes an incident alert to Lorikeet's #infra-alerts Slack channel. The notification includes attack classification (multi-vector: NTP amplification + SYN flood), both affected nodes, current PPS readings, source IP count, and a direct link to the live incident view in the Flowtriq dashboard. The on-call engineer sees the alert on their second monitor, already open during the event.
M
T+8s / 09:52:22
Auto-mitigation fires on-node
Flowtriq's auto-mitigation rules (pre-configured by Lorikeet to drop traffic matching the NTP amplification signature: source port 123, packet size >400 bytes, high volume, and SYN flood pattern) are pushed to iptables on both nodes. Inbound packet processing load drops immediately. The attack traffic is still arriving at the network interface but is dropped at the kernel level before reaching application processes.
↑
T+11s / 09:52:25
BGP FlowSpec + cloud scrubbing activated
Lorikeet's on-call engineer activates upstream mitigation with one click. Flowtriq simultaneously pushes a BGP FlowSpec rule (match source-port 123, action discard) to their upstream transit provider's edge routers and activates a cloud scrubbing integration, routing volumetric traffic through an additional upstream scrubbing layer. The unified approach handles attack traffic at two distinct upstream points before it reaches Lorikeet's network. Bandwidth consumption on their uplink drops from 48 Gbps back to baseline within seconds.
↑
T+19s / 09:52:33
Second FlowSpec rule for SYN component
The SYN flood component of the attack, sourced from a separate botnet subnet, continues briefly after the NTP amplification is scrubbed upstream. A second FlowSpec rule targeting the SYN flood's dominant source prefix is pushed. Within 4 seconds, the SYN rate on the CTF server drops from 890,000 SYN/s to under 200 SYN/s, within normal range for event traffic.
✓
T+38min / 10:30:09
Attack subsides, FlowSpec rules withdrawn
After 38 minutes of sustained attack traffic against the upstream null-route, the botnet abandons the campaign. The FlowSpec rules are withdrawn via Flowtriq. All three nodes return to clean baseline traffic. The PCAP capture taken during the incident (automatically triggered by Flowtriq at detection) is available for download in the dashboard. The training session has been running continuously throughout.
Flowtriq attack timeline and details panel · Detection 13:52:14 → peak 1.1M PPS / 48.3 Gbps → resolved 14:30:17 UTC · IP spoofing and botnet both confirmed
From the perspective of the 240 participants in the event, nothing happened. No latency spike was visible in the training platform. The instructor's stream did not buffer. The CTF scoring engine did not hiccup. The only indication that anything had occurred was the Slack alert thread, which the infrastructure engineer had been monitoring silently in the background.
The post-incident PCAP analysis confirmed a coordinated multi-vector attack with two distinct components, likely launched from separate hired botnet infrastructure.
ProtocolUDP / NTP
Source port123
Avg packet size468 bytes
Peak inbound39 Gbps
Peak PPS1.06M PPS
Unique source IPs2,140
Top source countriesCN, US, KR, RU, BR
ProtocolTCP SYN
Target port443, 8443
Avg packet size60 bytes
Peak inbound9 Gbps
Peak SYN/s890K SYN/s
Unique source IPs18,400
Spoofing detectedYes
Forensic analysis · Source IP entropy 0.87 · Avg packet size 392 bytes · Packet length distribution: 60B (SYN), 468B (NTP) · 4 unique TTLs confirming multi-origin reflector pool
5 IOC pattern matches · NTP monlist abuse (abuse.ch, 93%) · SYN-only flood (86%) · China Telecom and CNCGROUP flagged as DDoS-source ASNs
Why multi-vector attacks are harder to stop without tooling: The NTP amplification and SYN flood components required two distinct mitigation responses: a source-port-based FlowSpec rule for the amplification traffic and a source-prefix rule for the spoofed SYN traffic. Without per-second classification identifying both vectors simultaneously, a manual response would likely have addressed one while the other continued to saturate the uplink.
There are three reasons the infrastructure stayed up, and they are worth separating clearly.
Speed of detection. The 0.9-second detection window means Flowtriq identified the attack before it reached peak volume. NTP amplification attacks typically ramp to maximum throughput over 5–15 seconds as reflected packets begin returning from the amplifiers. Catching the attack in the ramp phase, before the uplink saturated, gave the mitigation rules time to take effect before bandwidth was exhausted.
On-node mitigation as a first line. The automatic iptables rules pushed by Flowtriq at T+8s protected application processes even before the upstream BGP rules were in place. The nodes continued accepting legitimate traffic from participants' VPN addresses (those IPs were not in the attack source ranges and passed through cleanly) while all other inbound traffic matching the attack signature was dropped at the kernel level.
Unified upstream mitigation, not just BGP. On-node iptables rules protect the server's CPU and application layer, but they do not recover saturated uplink bandwidth; traffic still has to traverse the ISP's network before being dropped. Flowtriq moved the drop point upstream in two ways simultaneously: BGP FlowSpec rules pushed to the transit provider's edge, and a cloud scrubbing integration routing traffic through an additional upstream layer. The combination meant attack traffic was being discarded at multiple points before it could reach Lorikeet's uplink at all.
Industry context: why manual response is not fast enough
Security operations research puts manual DDoS response workflows at a minimum of 15–30 minutes under best-case conditions: alert triage, vector classification, strategy selection, and upstream provider coordination. NETSCOUT's 2024 Threat Intelligence Report found that 70% of DDoS attacks last fewer than 15 minutes. This creates a structural gap: most attacks resolve on their own or cause their maximum damage before a manual response process can push an upstream rule. Flowtriq completed the same detection-to-upstream cycle in 11 seconds.
Attacker / botnet infrastructure NTP amplification via 2,140 open reflectors + spoofed SYN flood from 18,400 source IPs, totalling 48 Gbps combined
48 Gbps attack
↓ attack traffic routed upstream first
Cloud scrubbing layer Flowtriq activates cloud scrubbing integration — volumetric traffic filtered before reaching the transit provider
scrubbed
↓ residual traffic continues
Transit provider edge: BGP FlowSpec FlowSpec rules pushed to ISP routers drop matching attack traffic before it reaches Lorikeet's uplink
FlowSpec active
↓ residual traffic continues to node
Lorikeet nodes: on-node iptables Auto-fired kernel-level rules drop any residual attack packets before reaching application processes
clean traffic only
"We had 240 people in a live cybersecurity event and took close to 50 gigabits of attack traffic mid-session. The Flowtriq alert landed in our Slack before I'd even registered anything was wrong on the dashboard. By the time I pulled up the incident view, the on-node rules had already fired, BGP FlowSpec was pushed to our upstream, and cloud scrubbing was routing traffic through an additional layer. Full mitigation stack active in under 15 seconds from detection. Not one participant noticed anything happened."
RW
Ryan Wilke
CEO & Founder, Lorikeet Security
240 / 240
Participants stayed connected throughout the full event
11 seconds
From first packet detected to upstream BGP FlowSpec rule active
Zero downtime
All three nodes remained fully operational throughout the 38-minute attack
Full PCAP
Automated capture available for post-incident forensics and upstream ISP coordination
2 vectors neutralised
NTP amplification and SYN flood handled with independent targeted rules
Uplink recovered
48 Gbps scrubbed upstream; bandwidth never exhausted at Lorikeet's edge
Business impact: Lorikeet's contract for the March 27 event with [enterprise client, name redacted per NDA] carried a formal uptime SLA for the contracted training window, with breach provisions triggered by any outage exceeding 15 consecutive minutes and a mandatory reschedule obligation at Lorikeet's cost. A manual response to a 48 Gbps multi-vector attack would typically require 30 to 60 minutes under best-case conditions. The automated mitigation cycle completed in under 20 seconds. No SLA clause was triggered. No reschedule was required.
Following the March 27 event, Lorikeet Security standardised Flowtriq across all event infrastructure as a required component of pre-flight. Every session now includes a dedicated infrastructure check: FlowSpec adapter connected, cloud scrubbing integrations verified, alert channels confirmed and routed to whoever is on duty that day. Flowtriq runs year-round on all three nodes. Since March, it has automatically blocked two additional lower-volume probes against the CTF server without any manual intervention required.
"Every event now runs a Flowtriq pre-flight before we let participants in. FlowSpec connected, cloud scrubbing verified, alerts confirmed. It's become as standard as checking that the VPNs are up. Since March we've had two more automated blocks on the CTF server. I didn't even know about them until I checked the incident log."
Ryan Wilke, CEO & Founder, Lorikeet Security
Attack correlation across the Flowtriq platform · Multi-vector attacks: 38 min avg duration · Botnet detected in 100% · IP spoofing in 100%
Flowtriq takes under two minutes to deploy. Per-second detection, automatic mitigation, BGP FlowSpec upstream rules, and instant alerts. Starting at $9.99/node/month.
No credit card required · 7-day free trial
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。