A 50TB hug to Kloop Media: Forensic analysis of the DDoS attack targeting Kloop.kg

2 September 2026

Overview

In the early morning of the 31 of August (3AM UTC), the independent Kyrgyz news outlet Kloop.kg suffered a a high volume multi-vector DDoS attack aiming to bring the site down.

During the seven-hour attack, the attack generated roughly 50 TB of traffic in total — equivalent to around 15 years of the website’s normal traffic volume.

The attack targeted Kloop’s article Массовые жалобы на авторские права. Как в соцсетях банят критиков власти в Кыргызстане (Eng: A Flood of Copyright Complaints: How Critics of the Kyrgyz Government Are Being Banned on Social Media) from 7 August 2026. The article documents how critics of the Kyrgyz government are being targeted with coordinated mass copyright complaints on social media, resulting in the removal of critical content and suspension of accounts, a tactic also reported against independent journalists elsewhere in Central Asia.

Kloop Media has faced repeated reprisals in recent years as a consequence of its independent and fearless reporting on corruption and abuses of power in Kyrgyzstan. Kloop has effectively been forced out of normal operation inside Kyrgyzstan. Its websites were blocked in 2023, its domestic legal entity was ordered liquidated in February 2024, and the decision became final after the Supreme Court upheld it in July 2024. The official justification was based on the lack of valid company registration and claims that its reporting harmed state interests. Press-freedom organizations worldwide viewed the measures as part of a broader campaign against independent and investigative media in Kyrgyzstan. The pressure escalated further in May 2025 when security services detained at least eight current and former Kloop staff and associates.

Kloop’s co-founder and CTO, Rinat Tuhvatshin, is not sure how to interpret the DDoS attack against their news site. “DDoSing an already blocked site — an act of desperation? Whatever the reason, it illustrates what media outlets have to deal with online these days: state blocks, false copyright claims on social media, and good old DDoS attacks.”

Rinat adds: “I wish social media platforms would fight attempts to silence independent media and activists as zealously and effectively as Qurium fights DDoS attacks. It’s good to have Qurium protecting us.”

Qurium’s Forensic Lab has analyzed close to 10 TB of traffic associated with the DDoS attack against Kloop.kg. The traffic analyzed covers an observation window of about 2h50min (00:55-03:45 UTC) on 31 August 2026. The attack lasted 7 hours and generated around 50TB of junk traffic.

The first clear finding confirmed that this was not a single-vector flood. Kloop.kg was targeted simultaneously with several types of DDoS traffic.

The dataset analyzed contained approximately 3 million flow records and close to 15,000 observed source IP addresses. While GRE was by far the largest component, accounting for 74% of the traffic analysed, TCP contributed with 21%, with most of that traffic directed at HTTPS on TCP port 443. UDP accounted for approximately 5% of the traffic, with significant traffic directed at UDP ports 443 and 53.

Packet-level analysis showed the same overall pattern: a very large GRE flood accompanied by HTTPS/TLS connection traffic, UDP flooding against ports 443 and 53, and a separate TCP ACK flood targeting port 443.

The GRE flood

The GRE traffic is the most prominent feature of the attack.

GRE (Generic Routing Encapsulation), allows one network packet to be carried inside another. In this case, there is no indication that the traffic represented an attempt to establish legitimate GRE tunnels with Kloop.kg. Instead, GRE was being used as a flooding vector.

Approximately 75% of all traffic in the analyzed sample consisted of GRE packets. At this volume, the objective is primarily volumetric: consume available bandwidth and force routers, firewalls and DDoS mitigation infrastructure to process a very large number of encapsulated packets before legitimate traffic can reach the protected service.

The scale of the GRE component indicates that exhaustion of network capacity and network-processing resources was a central part of the attack.

It was however, not the only part of the attack.

Multiple attack vectors

While the GRE flood placed pressure on the network, other traffic targeted different resources.

Within the TCP/443 traffic we identified two distinct behaviors. One population of hosts established TCP connections and proceeded to generate TLS/HTTPS traffic. A second population generated small TCP ACK packets for which we could not identify the corresponding TCP handshake. The latter behavior is consistent with a spoofed TCP ACK flood.

UDP added another layer to the attack, with substantial traffic directed at ports 443 and 53.

The combination matters. GRE primarily attacks bandwidth and network-processing capacity. TCP connection and HTTPS traffic can additionally consume connection state, firewall and load-balancer resources, TLS processing capacity and resources closer to the application itself. ACK and UDP floods introduce additional packet-processing load while forcing mitigation systems to distinguish several different types of malicious traffic at the same time.

In practical terms, the attacker was applying pressure at several layers of the infrastructure simultaneously.

IP addresses involved in the attack

One important finding concerns the almost 15,000 source IP addresses present in the dataset.

These addresses should not be interpreted as evidence of a 15,000-device botnet.

Packet-level analysis indicates that the source population is mixed. We observed a recurring group of addresses whose behavior is compatible with real consumer routers, IoT devices and other customer-premises equipment. At the same time, another substantial part of the source population shows strong indications that the source IP addresses were forged.

We also observed addresses belonging to private and carrier-grade NAT ranges. We deliberately treated these separately from the stronger indicators of source-address spoofing.

The appearance of RFC1918 or CGNAT addresses in a packet capture is not a conclusive evidence of forgery. Depending on where traffic is observed, these addresses can become visible upstream of address translation or elsewhere in a provider’s network.

For that reason, we did not classify traffic as spoofed simply because its apparent source belonged to private or CGNAT address space.

The stronger spoofing assessment instead comes from the combination of several independent indicators: unrouted source addresses, an implausibly broad distribution across IPv4, common ingress paths, consistent TTL characteristics, and a separate population of TCP ACK packets for which no normal TCP handshake was observed.

Our assessment is therefore that the source list contains two different things: real systems participating in the attack, and a manufactured population of apparent source addresses introduced through IP spoofing.

This manufactured source population makes both filtering and attribution more difficult.

Greetings from Aisuru/TurboMirai

The overall traffic pattern had strong similarities with capabilities reported for the Aisuru/TurboMirai ecosystem, which is a large Mirai-derived IoT botnet ecosystem that compromises internet-connected devices, particularly routers and other CPE, and uses them to launch high-volume, multi-vector DDoS attacks.

The combination observed here, a dominant GRE volumetric flood together with TCP/443, UDP/443, UDP/53 and TCP ACK flooding, is consistent with the multi-vector attack capabilities associated with this class of IoT botnet. The recurring population of apparently genuine sources is also compatible with the use of compromised consumer routers, CPE and IoT equipment.

We do not, however, consider the traffic alone sufficient to attribute the attack definitively to Aisuru/TurboMirai. DDoS tooling and botnets frequently reuse the same techniques, and several related families are capable of producing similar traffic.

After we shared our preliminary analysis with third party intelligence sources, we could confirm that the attack was conducted by the Aisuru botnet.

Main source networks observed

The five largest source ASNs accounted for roughly 23% of the analyzed volume, where VNPT Corp alone represented around 11%.

These are networks in which the observed source addresses appeared, not evidence that the network operators knowingly participated in the attack.

The traffic was also not concentrated in a small number of networks. Approximately 47 ASNs were required to account for 50% of the observed traffic volume.

Attack vectors observed