A Botnet Became a Service
Gorilla was a Mirai-based DDoS-for-hire platform that operated from late 2024 into 2025. The question this series asks is not simply how many devices it infected, but how a familiar botnet design became a comparatively durable service that customers could rent. That distinction matters because it connects software changes, operating infrastructure, a marketplace, and real victims. Understanding those connections gives readers a better way to judge both the platform's resilience and the defenses that can limit its effects.
What DDoS-for-hire changes
A distributed denial-of-service attack, or DDoS attack, tries to make an online service unavailable by sending it more traffic or requests than it can handle. The target might be a website, a game server, a business network, or another Internet-facing service. The immediate problem is availability: legitimate users cannot connect reliably, responses slow down, or the service stops responding altogether. The consequences can extend beyond a server. Downtime can interrupt operations, reduce revenue, damage trust, and reveal weaknesses that attackers may exploit later.
The “distributed” part changes the problem. A denial-of-service attack can come from one source, but a DDoS attack uses many connected devices or networks at once. In a botnet, those devices have been compromised and placed under someone else's control. They can then receive a command to send traffic toward a chosen target. Because the traffic comes from many places, the target must handle a larger combined load, while the apparent sources do not necessarily reveal the person directing the attack.
Mirai made this arrangement easier to reproduce. The malware became notorious in 2016 for scanning the Internet for IoT devices that still used weak or default credentials. Once a device was compromised, it could be added to a controlled fleet and used in coordinated attacks. When Mirai's source code became public, later operators could reuse its broad architecture instead of designing every component from the ground up. A typical Mirai-style platform contains several responsibilities: a command-and-control server, often shortened to C2, directs infected devices; the bots execute commands; and separate propagation or hosting functions help find and load malware onto more devices.
DDoS-for-hire adds another layer to that technical arrangement. The customer does not need to find vulnerable devices, maintain a C2 server, or understand how the traffic is generated. They buy access through a web panel or an API, choose an attack option, and leave the operator to manage the hidden machinery. The service therefore changes the question from “Can someone build a botnet?” to “Can someone operate a dependable attack product?” A product needs capacity that customers can use, an interface that hides complexity, and enough continuity that a customer returns rather than looking elsewhere.
That change in roles is central to Gorilla. The operators were not only maintaining malicious software. They were presenting a service, setting limits, choosing what capabilities to expose, and communicating with users. Customers were not merely passive beneficiaries of a botnet's existence; their purchases and repeated requests shaped what the service had to provide. Victims, meanwhile, encountered the result as a loss of availability, regardless of whether the traffic came directly from infected devices or from other infrastructure managed by the operators.
The basic relationship can be represented without treating the botnet as the whole system:
The distinction in this map is important. The infected devices are one source of attack traffic, but they need not be the only source. A customer-facing service can coordinate both the bot fleet and centralized infrastructure. That broader boundary is one of the reasons a simple count of compromised devices may not explain the impact a platform can deliver.
Why Gorilla is an unusual case
The USENIX study treats Gorilla as a notable exception among Mirai-based DDoS services because it remained active across a longer period than the weeks or few months often reported for comparable platforms. The public description places its operation between fall 2024 and summer 2025. More precisely, the researchers observed the C2 going offline on June 28, 2025 and saw no subsequent activity. They infer that a law-enforcement takedown probably succeeded because the C2, Telegram channel, and supporting infrastructure became inactive, but they also note that no official law-enforcement statement confirmed that conclusion. “Long-lived” here is therefore a research characterization of an observed case, not a claim that Gorilla set a universal record or that every part of its history is known.
The case is worth studying because its apparent durability was not attributed to one dramatic innovation. The researchers found a platform built largely from decade-old Mirai ideas, then modified through two major software phases. Changes affected command-and-control communication, client updates, propagation, attack functionality, and the control of packet rates and concurrent attacks. In the later phase, scanning was moved away from individual bots and toward centralized infrastructure. The service also adjusted its plans, promoted demonstrations, offered discounts, and preserved customer accounts through C2 changes. Taken together, these details suggest a system that learned from operating experience and treated continuity as both an engineering problem and a commercial requirement.
There are two different kinds of duration to keep separate. An individual attack may last only minutes, while the service that makes many such attacks available can remain online for months. A customer can also turn short commands into a longer campaign by repeating them or running several at once. For a victim, the relevant experience is not necessarily the lifespan of one command; it is whether the service can return after a brief gap, change its traffic, or continue when one part of its infrastructure is interrupted. For an operator, the relevant question is whether a C2 change, a software update, or a capacity problem causes customers to leave. Gorilla's long life therefore describes the continuity of a service, not a single uninterrupted flood.
Its Mirai lineage should also not be mistaken for a complete explanation. Reusing a public architecture lowers the cost of entry, but it preserves assumptions that may be easy to observe or disrupt. The evidence suggests that Gorilla's operators had to maintain a living system around that inherited core: they changed how clients communicated, moved some responsibilities elsewhere, adjusted what customers could request, and kept the service legible to buyers. The central puzzle is thus a maintenance puzzle. How did operators preserve enough compatibility with the old design to keep using it while changing enough of the surrounding system to avoid its most visible weaknesses? That tension connects the technical history to the commercial one without requiring us to assume that every change had the same purpose.
The evidence comes from several vantage points. The researchers reverse-engineered malware samples, emulated a bot to observe commands, watched scanning through network telescopes, examined provider-level flow records, monitored the control panel and public promotion, and compared the results with controlled tests and victim accounts. That mix matters because each view answers a different question. A C2 observation can reveal what commands were issued. A traffic measurement can show what reached a monitored network. A control panel can show what the operators promised or sold. A victim account can show what disruption looked like in practice. None of those views alone is the whole platform.
This also sets a standard for the numbers that appear later. The study recorded a large number of attacks during its measurement period, but that total is an observed dataset, not necessarily every attack Gorilla ever launched. Public dashboards offered useful indications of attack volume, but their readings fluctuated. Netflow helped validate traffic and establish lower bounds, yet provider visibility, sampling, spoofed sources, and upstream filtering limited what it could prove. The researchers themselves caution that they may not have seen the platform's complete firepower. A precise number can be real and still be incomplete evidence.
The practical significance is broader than the fate of one service. A DDoS-for-hire platform lowers the expertise needed to turn an availability attack into an action. That makes the operator's reliability decisions consequential to organizations that may never interact with the botnet directly. It also complicates defense. A victim may see a mixture of traffic types, repeated bursts, and apparent sources that do not correspond neatly to the actual control structure. A mitigation strategy aimed at only one signature or one address can therefore miss another part of the attack path.
A wider system than the botnet
Gorilla's central lesson is a systems lesson: longevity can emerge when several modest improvements reinforce one another. Mirai supplied a reusable starting point. Iterative releases addressed weaknesses that made communication, propagation, or capacity control easier to disrupt. Separate infrastructure reduced the need for every bot to perform every job. Centralized attack capacity appears to have supplemented the direct output of the bots. The marketplace translated those capabilities into plans and a simple interface. Marketing and customer support helped turn technical availability into continued demand.
That does not mean the platform was invulnerable or that its operators had solved DDoS. The paper reports weaknesses and uncertainties alongside its successes. Early communication still resembled Mirai closely enough to support detection. A checksum or authentication exchange did not by itself prevent a hostile takeover if the protocol became known. The study could not determine the complete size or ownership of the centralized component. It could correlate commands with high-profile disruptions but could not identify who ordered those attacks. And because the research focuses on one successful platform, it cannot establish that the same combination would produce the same result elsewhere.
For readers, the useful starting point is therefore not “Gorilla had a large botnet.” It is “Gorilla managed dependencies.” It had to keep enough devices reachable, make commands useful, control shared capacity, hide complexity from customers, and respond to failures without destroying demand. The inherited Mirai template made that work possible, but it did not explain the platform's later durability by itself. To understand the repairs and trade-offs, we first need to examine what that template actually provided—and what it left exposed.