What Is a Botnet? Command Structures and Takedowns Explained

One infected computer is a problem for its owner. Thousands of infected devices, all taking orders from the same operator at the same moment, are a problem for everyone else. That is a botnet: an army of hijacked machines, coordinated at scale, pointed at whatever target or task the operator chooses. The individual owners usually have no idea their device is enlisted.

A botnet is a network of internet-connected devices infected with malware and controlled together by a single operator, often called a bot herder. Each infected device, a bot, quietly does its normal job for its owner while also waiting for instructions from the operator's command-and-control system. The power is in the numbers and the coordination.

What gets recruited into a botnet

Anything that connects to the internet and runs code is a candidate. Botnets are built from:

Home and office computers, infected through the usual malware routes.
Servers, especially internet-facing ones with unpatched vulnerabilities.
Routers and network gear, often running old firmware.
Internet-of-Things devices: cameras, recorders, smart appliances, frequently shipped with default passwords that were never changed.

That last category matters. Cheap connected devices with default credentials and no update path are ideal recruits, because they are numerous, always on, and rarely monitored. Many of the largest botnets are built substantially from such devices.

How botnets are commanded

The command structure is what turns a scatter of infections into a coordinated force, and it shapes how resilient the botnet is.

Centralized command-and-control. Bots connect to one or a few servers to receive instructions and report back. This is simple to operate: the herder issues one command and the herd acts. Its weakness is the same as its strength. Take down the central servers and the whole botnet goes dark. Bots hide this traffic inside ordinary protocols to blend in, which maps to MITRE ATT&CK Application Layer Protocol (T1071).

Peer-to-peer command-and-control. Instead of central servers, bots relay commands among themselves. Any bot can pass an instruction to its neighbors, so there is no single server to seize. This is far more resilient against takedown, at the cost of being slower and harder for the operator to control.

Domain generation. To resist seizure, many botnets have their bots compute a changing list of rendezvous domains, so defenders cannot simply block one address. The operator registers whichever domain the algorithm will produce next; defenders must predict and pre-empt them.

Resilience cuts both ways

Centralized botnets are easy to command and easy to decapitate. Peer-to-peer botnets survive server takedowns but are clumsier to run and slower to update. Operators pick a structure by trading control against durability, and defenders exploit whichever weakness that choice creates.

What botnets are used for

A botnet is general-purpose infrastructure. Once built, it is rented out and pointed at whatever pays. Common jobs:

Distributed denial-of-service (DDoS). Every bot floods a target with traffic at once, overwhelming it. This maps to Network Denial of Service (T1498), and it is the use botnets are best known for.
Spam and phishing distribution. Thousands of machines sending mail spread the load and dodge simple blocklists.
Credential stuffing and brute force. Bots test stolen username and password pairs against many sites in parallel, from many addresses, evading rate limits.
Proxy and anonymization services. Infected devices are resold as residential proxies, laundering an attacker's traffic through innocent victims' connections.
Click fraud and ad abuse. Bots generate fake ad clicks and impressions for money.
Malware and cryptomining distribution. The botnet spreads further payloads or quietly mines cryptocurrency on every enlisted device.

The same herd can switch between these jobs, which is why a botnet is valuable long after it is built.

Command structures compared

Structure	Operator control	Takedown resistance	Typical disruption method
Centralized servers	High, fast to command	Low, one point of failure	Server seizure and domain blocking
Peer-to-peer	Lower, slower to update	High, no single point	Poisoning the peer network
Domain-generation rendezvous	Moderate	Moderate to high	Pre-registering or sinkholing generated domains

The trade is always control against survivability, and every choice an operator makes opens a specific line of attack for defenders.

How botnets are taken down

Disrupting a botnet means cutting the operator off from the herd. The main techniques:

Sinkholing. Defenders take over the domains or addresses that bots use to reach their controller and redirect that traffic to servers they control, called sinkholes. The bots keep phoning home, but their calls now reach defenders instead of the operator. This severs command and lets responders measure the botnet and notify victims. Sinkholing is most effective against centralized and domain-generation botnets, where there is a rendezvous point to capture.

Domain and infrastructure seizure. Coordinated legal and technical action seizes the domains, servers, and accounts the botnet depends on, often across several countries at once to prevent the operator from simply failing over.

Peer poisoning. Against peer-to-peer botnets, defenders inject their own nodes to disrupt how commands propagate, degrading the network from inside since there is no central server to seize.

Infrastructure takedowns disrupt, but operators rebuild. Durable results usually require identifying and prosecuting the people running the botnet, which is why takedowns pair technical action with law enforcement.

The malware that recruits new bots is delivered like any other, often through an abused file format arriving by phishing or a poisoned download. Our File-Format Abuse Atlas catalogues those delivery formats and how to detect them, which is where you stop a device from being enlisted in the first place. The crews that build, rent, and operate botnets are tracked in our Threat Groups directory, so you can connect a campaign to its operator.

How to defend against botnets

Defense has two fronts: keep your own devices out of botnets, and protect your services from botnet-driven attacks.

Keeping your devices out of a botnet:

Change default credentials on everything, especially IoT. Default passwords are how the largest device botnets recruit. A unique, strong credential on every connected device removes the easiest recruitment path.
Patch firmware and software. Routers, cameras, and servers with known vulnerabilities are prime recruits. Keep them current or replace gear that no longer receives updates.
Segment and monitor connected devices. Put IoT and untrusted devices on their own network segment, and watch for the outbound command-and-control traffic that signals an infection.
Block known command-and-control destinations. Threat-intelligence feeds and DNS filtering can stop a bot from reaching its controller, neutralizing an infected device even before cleanup.

Defending your services against botnet attacks:

Prepare for DDoS. Use upstream scrubbing or a mitigation service so a traffic flood does not take you offline, and rehearse the response.
Rate-limit and add friction to logins. Defend against credential stuffing with rate limiting, anomaly detection, and phishing-resistant authentication, so a botnet cannot cheaply test stolen passwords against you.

Watch outbound traffic, where enlisted devices reveal themselves

A botnet infection shows up as unexpected outbound connections: a camera or router repeatedly contacting an unfamiliar address. Monitoring and filtering outbound traffic catches enlisted devices that inbound defenses missed, and blocking the command-and-control destination disables the bot even before you can clean it.

A worked example: how a flood comes together

Following one job from start to finish shows how the pieces connect. Suppose an operator has quietly built a herd of tens of thousands of infected home routers and cameras, each recruited through an unchanged default password. Day to day, those devices do nothing unusual. They serve their owners, and in the background they hold an open path to the operator's command-and-control channel, checking in on a schedule and waiting.

A buyer rents the herd for an hour to knock a target offline. The operator issues one instruction through the command channel: send traffic to a specific address and port, starting now. Because the bots are already connected and waiting, the instruction propagates in seconds. Every device begins sending traffic to the target at once. No single camera sends much, and a camera sending a trickle of traffic looks unremarkable. Tens of thousands of them together saturate the target's capacity, and the service goes down. This is a distributed denial-of-service, and it maps to Network Denial of Service (T1498).

The distributed nature is what makes it hard to stop. The traffic arrives from tens of thousands of separate, legitimate-looking addresses belonging to innocent owners, so blocking any one of them accomplishes nothing, and blocking all of them means blocking a large slice of ordinary internet users. When the rented hour ends, the operator sends a stop command, the bots fall silent, and the same herd is ready for the next buyer and a different job entirely. The devices were never damaged, their owners never noticed, and the infrastructure remains intact for reuse.

What gets recruited, compared

Not every recruited device serves the same purpose, and the mix shapes what a botnet is good for.

Device type	Why it is recruited	Best suited for
Home and office computers	Rich compute, general-purpose, common malware routes	Spam, credential stuffing, malware spreading
Internet-facing servers	High bandwidth and uptime, unpatched services	Large traffic floods, hosting further payloads
Routers and network gear	Always on, old firmware, sits on the network path	Traffic floods, traffic redirection, proxying
Internet-of-Things devices	Numerous, default credentials, no updates, unmonitored	Massive device floods, residential proxying

The pattern is that abundant, always-on, poorly maintained devices contribute numbers and bandwidth, while richer machines contribute the compute for jobs like credential testing and mining. An operator values a mix, because different buyers want different capabilities from the same herd.

Common misconceptions

Several beliefs about botnets lead defenders to underestimate them.

A botnet needs a central server. Many do, and peer-to-peer and domain-generation designs remove that single point deliberately, which is what makes them survive server seizures. Assuming there is always one address to block leaves you unprepared for the resilient designs.
Only computers get recruited. Cameras, routers, recorders, and smart appliances make up a large share of the biggest botnets, precisely because they are numerous and rarely secured. Ignoring device security leaves the easiest recruitment path wide open.
An infected device shows obvious symptoms. A bot keeps doing its normal job and stays quiet to avoid getting cleaned up, so the owner typically notices nothing. The signals live in outbound network traffic, not in obvious device misbehavior.
Taking down the servers ends the botnet. Seized infrastructure gets rebuilt, and operators fail over to backups. Durable disruption usually requires going after the people running the botnet, which is why takedowns pair technical action with law enforcement.
A botnet does one thing. The same herd switches between denial-of-service, spam, credential stuffing, proxying, click fraud, and mining depending on what pays. Its flexibility is exactly why it stays valuable long after it is built.

The life cycle of a botnet

A botnet is not a single event. It moves through stages, and each stage is a place a defender can intervene.

The first stage is recruitment. Malware reaches a device through a phishing attachment, a drive-by download, an exploited service, or a scan that finds a device still running default credentials. The payload runs and the device becomes a bot. For the largest device botnets, this recruitment is fully automated: infected devices scan the internet for more devices with weak or default logins and infect them in turn, so the herd grows on its own without the operator lifting a finger.

The second stage is rendezvous. A fresh bot needs to find its command-and-control channel. It may connect to a hard-coded server, resolve a domain from a generation algorithm, or reach into a peer network to find its neighbors. This is the moment a bot is loudest on the network, because it must reach out to something it does not yet trust, and it is where outbound monitoring has its best chance to catch an infection.

The third stage is tasking. Once in contact with its controller, the bot waits for instructions and executes whatever job it is given, whether that is joining a traffic flood, sending spam, or testing stolen credentials. A single bot may sit idle for long stretches and then activate in unison with thousands of others when the operator sells the herd's capacity.

The final stage is maintenance and monetization. The operator updates the malware, adds resilience, prunes cleaned devices, and rents the herd out. A botnet that survives cleanup and takedown attempts keeps earning, which is why operators invest in the resilience mechanisms that make disruption hard.

Detection signals

A botnet infection is designed to be quiet on the host, so the clearest signals are on the network and in the aggregate.

Unexpected outbound connections. A camera, router, or workstation repeatedly contacting an unfamiliar external address, especially on an odd schedule, is the classic sign of a bot phoning home to its controller.
Beaconing patterns. Command-and-control traffic often shows a regular heartbeat, a connection at steady intervals, that stands out from the irregular timing of human-driven traffic once you baseline what normal looks like.
Traffic to generated domains. A device resolving a stream of long, random-looking domain names, most of which fail, is a strong indicator of a domain-generation algorithm searching for its live rendezvous point.
Protocol anomalies. Bots hide command traffic inside ordinary protocols, which maps to MITRE ATT&CK Application Layer Protocol (T1071). Traffic that uses a common protocol in an uncommon way, such as unusual request patterns or payloads, can reveal the tunnel.
Participation in floods. A sudden surge of outbound traffic to a single external target suggests the device has been tasked into a denial-of-service job, mapping to Network Denial of Service (T1498).
Login attempts from your address range. If your devices are enlisted for credential stuffing, you may see outbound bursts of authentication attempts to many third-party services.

The infected owner is usually the last to know

Because a bot keeps doing its normal job while it waits for orders, the device's owner rarely notices anything. The signals live in the network traffic and in patterns visible only across many connections, which is why monitoring outbound flows and command-and-control destinations catches enlisted devices that the device itself gives no sign of hosting.

How botnets evolved

Early botnets often coordinated through public chat protocols, where bots joined a channel and read commands the operator posted. That was simple and effective until defenders learned to find and shut the channels, which decapitated the whole botnet at once. The pressure of takedowns pushed operators toward more resilient designs.

The response came in stages. Operators moved command traffic into ordinary web protocols so it blended with normal browsing. They added domain-generation algorithms so there was no single fixed address to seize. They built peer-to-peer structures so there was no central server at all. In parallel, the target set widened dramatically as cheap internet-connected devices proliferated, many shipping with default credentials and no update path, giving operators a vast and easily recruited population. The through-line across this history is a constant trade between the operator's need to control the herd and the need to survive disruption, with each defensive advance answered by a design that spread the botnet's coordination more widely.

Frequently asked questions

How does a device end up in a botnet? Through the same routes as any malware infection: a phishing attachment, a drive-by download, an exploited unpatched service, or an automated scan that finds a device still using default credentials. Many device botnets grow by having infected devices scan for and infect other weakly secured devices automatically.

Can my home router or camera really be part of a botnet? Yes, and these are among the most common recruits. Cheap connected devices are numerous, always on, rarely monitored, and often ship with default passwords that were never changed, which makes them ideal bots. Changing default credentials and keeping firmware current removes the easiest recruitment path.

Why are some botnets so hard to take down? Resilience comes from the command structure. A centralized botnet dies when its servers are seized, but a peer-to-peer botnet has no central server to seize, and a domain-generation design constantly changes the address bots look for. Durable takedowns usually require identifying and prosecuting the operators, because seized infrastructure gets rebuilt.

What is sinkholing? Sinkholing is when defenders take over the domains or addresses that bots use to reach their controller and redirect that traffic to servers they control. The bots keep phoning home, but their calls reach defenders instead of the operator, which severs command and lets responders measure the botnet and notify victims.

How do I know if a device on my network is a bot? Watch outbound traffic. Unexpected connections to unfamiliar addresses, a regular beaconing heartbeat, a stream of failed lookups for random-looking domains, or sudden traffic surges toward a single target are all signals. Monitoring and filtering outbound flows catches enlisted devices that inbound defenses missed.

What is the difference between a botnet and a single piece of malware? A single infection affects one device and its owner. A botnet is many infected devices controlled together through a command-and-control channel, so the operator can direct thousands of machines at once. The power is in the numbers and the coordination, which is what makes a botnet valuable long after it is built.

Is defending against botnets different from defending against their attacks? Yes, and you need both. Keeping your own devices out of a botnet is about credential hygiene, patching, segmentation, and outbound monitoring. Defending your services against botnet-driven attacks such as denial-of-service and credential stuffing is about scrubbing capacity, rate limiting, anomaly detection, and phishing-resistant authentication.

Why do operators rent botnets out instead of using them directly? Renting turns the herd into recurring income and spreads the risk. A buyer pays for an hour of flooding or a batch of spam, and the operator keeps the infrastructure and reuses it for the next customer. This rental model is why a botnet is treated as general-purpose infrastructure, built once and monetized many times across many different jobs and buyers.

Does a botnet stop working if I clean one infected device? Cleaning one device removes that one bot, and the botnet continues with the rest. For your own protection that cleanup matters, and blocking the command-and-control destination disables the bot even before you finish cleaning it. Disrupting the whole botnet is a separate effort that targets the operator's command infrastructure.

Botnets endure because they are flexible, rentable infrastructure built from other people's devices. You fight them from both ends: secure and monitor your own connected devices so they are never recruited, and harden your services so the herd has nothing to gain when it is pointed at you. Change the default password, patch the firmware, and watch the outbound traffic, and you deny the botnet the two things it runs on, numbers and quiet.