Teenagers sold DDoS attacks: Poland's booter-as-a-service case

On 10 March 2026, CBZC said it had identified seven minors who were aged 12 to 16 at the time of the alleged conduct. According to investigators, they made DDoS-capable programs available online, cooperated in administering the infrastructure and received financial benefit. Alleged targets included sales portals, hosting providers, IT domains and accommodation-booking services.

Officers acting in four Polish regions seized computers, phones, storage media, disks, a hardware device for digital assets and handwritten notes. Because of the suspects’ ages, the material was to be referred to family courts. The Bydgoszcz-Północ District Prosecutor’s Office supervises the case. These are law-enforcement findings, not final judgments.

What a booter or stresser does

A booter turns DDoS into a service: a customer chooses a target, duration and traffic class, pays, and a panel directs distributed sources. “Stresser” can be marketing cover suggesting authorised testing, but a legal load test needs explicit owner approval, limits and a rollback plan. Sending traffic to somebody else’s service “for testing” is not authorised.

The service may use a botnet of compromised devices, servers rented under false identities or UDP amplification. In amplification, the actor spoofs the victim’s IP and sends small queries to exposed services that return larger responses. Geographically distributed sources make simple address blocking ineffective.

Why a short DDoS still matters

A fifteen-minute outage may escape some users, yet for commerce, booking and hosting it means abandoned transactions, SLA impact and incident labour. DDoS can also be a diversion: while administrators watch bandwidth, an intruder tests authentication, changes DNS or exploits an application flaw.

Defence has to separate layers. A carrier or globally distributed scrubbing/CDN service should absorb volumetric traffic. Protocol attacks require network-stack protections, while application-layer pressure needs per-identity limits, caching, queues and behavioural controls. An on-premises firewall cannot help after the internet circuit is saturated.

A practical service runbook

Establish normal requests per second, bandwidth, geography, errors and backend cost. Then configure limits that preserve legitimate users and a degraded mode: static content, disabled expensive searches, queuing, and priority for authentication and payment.

During an incident, retain NetFlow or PCAP samples, timestamps, ASNs, headers and application metrics. The mitigation provider must have a tested 24/7 escalation path. Afterwards, inspect concurrent authentication and configuration changes rather than checking uptime alone. Our HTTP/2 Rapid Reset analysis explains a modern application-protocol example.

Never load-test production without coordination among the carrier, hosting provider and business owner. A safe exercise has bounded traffic, observers on both sides and an immediate kill switch. We can design that scenario without putting customers at risk.

Three different problems called DDoS

A volumetric attack fills the circuit. A protocol attack exhausts state tables, queues or TLS resources. An application-layer attack sends apparently valid requests to an expensive function such as search or report generation. Each needs different metrics; an Mbps graph will not reveal a depleted database pool.

Assign ownership in the runbook: the carrier handles upstream scrubbing or routing controls, the platform owns autoscaling and caching, and the application team owns endpoint cost. Routing everything to one “network team” delays decisions.

Limits that survive distribution

Per-IP limits are necessary but insufficient. Legitimate users may share NAT while a botnet distributes traffic across thousands of addresses. Combine identity, session, token, ASN, reputation and operation cost. Separate the budget for starting an expensive job from downloading a cheap object.

Enforce resource budgets for CPU time, concurrent work and response size. A circuit breaker should stop a dependency before cascading failure. Caches help repeated reads but must not mix user data.

Post-incident metrics

Measure detection time, mitigation time, rejected legitimate traffic and cloud cost. Check whether autoscaling increased spend without backend throughput. Review authentication, DNS and deployments in the same window because DDoS may have been a diversion.

Is a CDN enough? Not always. It protects cacheable content and absorbs traffic, while origin, APIs and a leaked direct address remain targets. The origin should accept traffic only from the CDN network.

---

Primary sources: CBZC — seven teenagers allegedly sold DDoS tools, CISA — Guide to DDoS Attacks.