The Template Gorilla Inherited
For Gorilla, the Mirai design was not just historical background; it was the starting architecture for a rentable attack service. This chapter traces what crosses each boundary—from a compromised IoT device to the command system and then to a victim—and explains what an operator hides behind a simple customer interface. The result is a baseline for judging Gorilla's later changes as repairs to real dependencies rather than as a random collection of features.
From exposed device to coordinated fleet
The basic Mirai-style flow begins with a device that is connected to the Internet and insufficiently protected. Mirai became known for looking for IoT devices that still used weak or default credentials. When a vulnerable device was compromised, malware could be placed on it and the device could join a controlled group. The important point is not the particular credential or the scanning technique. It is the division of responsibility: one part of the system finds opportunities, another delivers the software, and the newly infected device becomes both a potential source of attack traffic and, in the original design, another participant in finding more devices.
A command-and-control server, or C2, gives the fleet a shared point of coordination. Once a bot can reach the C2, it can receive an instruction to act against a chosen target. The bot then generates traffic from the compromised device. The C2 is not the same thing as the bot fleet. It maintains the control relationship and issues commands; the bots provide the distributed endpoints that carry them out. If the C2 is unavailable, a bot may remain infected but lose its ability to receive new work. If a bot is offline, filtered, or cleaned, the C2 may still control other devices. These are different failure conditions, and keeping them separate is essential to understanding the architecture.
Propagation adds another dependency. In a common Mirai-based setup, bots scan for more vulnerable devices, an infector uses an exposed weakness to place the malware, and a hosting server makes the payload available for download. The C2, the infector, and the hosting service do not have identical jobs. The C2 coordinates an existing fleet. The propagation side grows or replenishes that fleet. The hosting side supplies what a newly compromised device needs to become active. A failure in any one of them can change the system's behavior: the attack fleet may continue to execute existing commands while growth stops, or new infections may occur without a working control channel.
Compromise is therefore only the beginning of control. A device can be infected yet unavailable, unable to reach the C2, or unable to generate useful traffic. Conversely, the C2 can remain online while individual devices disappear from the fleet. The platform's effective capacity is the result of these conditions lining up: a device must be present, connected, recognized by the control system, and able to carry out the requested action. This is why “number of infected devices” is an incomplete description even before centralized infrastructure enters the picture.
The architecture also has a time dimension. Propagation is about changing the population of devices; command and control is about coordinating the population that exists now; attack execution is about producing a target-facing effect at a particular moment. These activities can overlap, but they have different signals and different failure paths. A system that keeps scanning after it has been noticed may grow faster while drawing more attention. A system that stops growing may become quieter but depend more heavily on the devices and infrastructure it already has. Those are design trade-offs, not interchangeable stages.
The hosting function adds a further point of dependence because a newly compromised device needs somewhere to obtain the software or supporting material that makes it active. If that delivery path fails, new opportunities do not become usable members of the fleet. If the C2 fails after delivery, the device may remain present but cannot receive new work. The original Mirai-style arrangement thus offers a simple route from exposure to attack, but its simplicity exposes the interfaces an operator must keep working. Gorilla's later separation of responsibilities becomes meaningful against this baseline: it changes who performs a job and where a failure is contained.
The flow can be pictured at a high level:
The diagram deliberately leaves out low-level exploit details. Its purpose is to show the control boundaries. The customer request enters through an interface and ends up as a command. The command crosses from the C2 to many bots. Traffic then crosses from those devices to the victim service. Propagation is related to the attack path, but it is not the same path: it determines how the fleet is built, not how a particular customer request reaches a target.
That separation also explains why a botnet is more than a pile of infected machines. Each device has a local state—infected or not, connected or not, capable of executing an instruction or not. The C2 has a different state—whether it is reachable, whether it accepts a bot, and which requests it is willing to distribute. The propagation side has another state—whether it can discover and load new devices. A service appears reliable to a customer only when enough of those states line up at the moment an attack is requested.
Mirai's public source-code release in 2016 changed the economics of building this kind of system. An operator could reuse a known architecture and modify it instead of creating a complete botnet framework from nothing. That lowered the barrier to entry and helped produce many descendants. Reuse, however, is not the same as reliability. Shared code can carry shared assumptions, familiar traffic patterns, and the same single points of failure. A design that is quick to copy may also be quick for defenders to recognize or for a rival operator to disrupt.
This is the inheritance Gorilla had to manage. The Mirai template supplied a practical division between control, infection, and attack execution. It also left operators with a propagation process that could be visible, a control channel that could be studied, and a fleet whose useful capacity varied with device availability. Gorilla's later history is therefore best read as an attempt to retain the productive parts of that template while changing the parts that made the service fragile.
What a customer buys
DDoS-for-hire adds a commercial boundary above the technical one. A customer does not normally buy a list of infected devices or a copy of the C2. They buy the ability to request an effect: send traffic toward a target for a chosen period, using an option the service exposes. The operator keeps the underlying inventory, command format, propagation machinery, and capacity-management decisions out of sight. The control panel or API is a translation layer between a customer's request and the internal actions needed to fulfill it.
That translation changes who carries the complexity. In a self-operated botnet, the person launching an attack would need to assemble infrastructure, keep bots connected, distribute commands, and understand why some requests fail. In a stresser service, the customer sees a form or an interface, while the operator absorbs the maintenance burden. The customer may still choose a target and an attack option, but they do not need to know whether the resulting traffic comes from many compromised devices, centralized systems, or a mixture. The simpler the interface, the more the operator must standardize behind it.
Consider what the interface has to hide. A request that looks like one action to a customer may require checking an account, translating a product label into an internal command, finding available capacity, and deciding whether several requests can run together. A failed request could mean that the C2 is unreachable, that too few bots are active, that a requested option is not implemented as advertised, or that the service is protecting its remaining capacity for other customers. The customer does not need to see those internal states, but the operator must distinguish them well enough to keep the service usable.
This abstraction also changes the meaning of a successful attack. The customer judges the platform by the result at the victim, while the operator can judge it by internal indicators such as connected bots, active commands, or available slots. Those measures may diverge. A command can be accepted even when the target effect is weak; a dashboard can show an active request even when upstream networks filter part of the traffic. A commercial service has to manage that gap through its interface, limits, status information, and promises. The more confidently it presents an effect, the more pressure falls on the hidden system to make the effect repeatable.
This arrangement creates requirements that a one-off attack tool could ignore. First, the service needs predictable capacity. If every customer request competes unpredictably for the same bots, the advertised result will vary. Second, it needs continuity. A C2 change or infrastructure outage that invalidates accounts or interrupts access can destroy customer confidence even if the malware remains on devices. Third, it needs a way to expose options without exposing every implementation detail. A service can present several attack choices while translating them into a smaller or changing set of backend actions. Fourth, it needs some form of customer communication, whether that is support, status information, promotion, or a response to complaints.
Gorilla's control panel showed these requirements in practice. The study found a service where users could buy subscriptions, launch attacks, view operational statistics, and contact the operators. It offered ordinary access and API access, so some customers could automate requests rather than use the web interface. The panel also showed the status of platform components, which revealed that the operators depended on centralized infrastructure alongside the bots. That is a significant clue: the product being sold was not simply “time on a botnet.” It was access to a managed system with several moving parts.
The distinction matters for interpreting the platform's apparent success. If an operator preserves customer access while changing a C2, the change is not only a software migration; it is a service-continuity event. If the platform adds a capacity tier, it must connect a customer-facing promise to a controllable resource. If it offers a free demonstration, it can use centralized capacity to show the interface before committing the bot fleet. These choices belong to the same operating model as the malware, even though a customer may never see them.
A lower technical barrier can increase demand, but it also raises the cost of failure. Non-specialist customers are less able to diagnose a failed request, distinguish a temporary outage from a capacity limit, or adapt to an unfamiliar backend. They judge the service through availability, responsiveness, and visible results. The operator therefore has an incentive to turn hidden engineering decisions into stable, understandable product behavior. In that sense, DDoS-for-hire makes reliability part of the attack capability itself.
The Mirai template made the first version of that service possible, but it did not settle how the service would survive. It left open questions about how to keep control channels reachable, how to grow the fleet without making propagation conspicuous, how to manage uneven bot capacity, and how to keep customer requests consistent as the backend changed. Gorilla's distinctiveness lies in the way its operators addressed those questions over time. The next step is to follow those revisions as a lifecycle of engineering decisions, with each change tied to a weakness in the inherited design.