Is a botnet the same as a distributed denial-of-service attack?

No. A botnet can support such an attack, but botnets have other uses and the two terms describe different things.

Does the device owner have to install the malware deliberately?

No. Compromise can occur without informed consent or awareness.

Is restarting a device enough to resolve an infection?

Not reliably. Recovery depends on the device, malware and underlying weakness; follow appropriate vendor and incident-response guidance.

AI Glossary / Data engineering and architecture / Beginner

Botnet

Definition

A botnet is a network of compromised computers or other connected devices that can be directed to perform activities for an unauthorized operator. Each participating device is often called a bot. Its legitimate owner may be unaware of the compromise.

What it means

The important feature is coordinated misuse of devices, not their intelligence. A botnet does not need artificial intelligence, and an ordinary chatbot is not a botnet member merely because it is called a bot. Legitimate fleets of automated computers are also different from the malicious networks discussed here.

Botnets can include laptops, servers, routers, cameras and other internet-connected equipment. Their operators may use them to distribute unwanted messages, relay criminal traffic, overwhelm services or support further intrusions. Individual networks differ in their capabilities and purpose.

A business can be affected in two ways: its devices can become part of a botnet, or its services can receive activity originating from one. Those situations require different investigations. Seeing traffic from a device does not establish that its owner knowingly participated in an attack.

How it works

A device first becomes compromised, for example through malicious software or an exploitable weakness. Some incidents involve misleading messages; others involve devices that users never interact with directly. The compromised device then communicates with infrastructure that coordinates its activities.

This communication is often called command and control, or C2. Architectures vary: some rely on central services, while others distribute coordination. The operator can assign work across many devices, making the combined activity harder to address by focusing on one machine.

For defenders, identifying a suspicious connection is a starting point rather than a complete diagnosis. They need to establish which device made it, whether the behavior is authorized and what else occurred. Removing one known malicious component does not prove that all stolen credentials, additional malware or exploitable weaknesses have been addressed.

Three practical examples

A household router is misused as a relay, making another person's traffic appear to originate from that household's internet connection.
A business discovers that several computers infected through a malicious attachment are communicating with an unauthorized control service.
An online retailer faces requests from many compromised devices and works with its service providers to distinguish hostile activity from legitimate customers.

Think of it this way

Think of an intruder secretly taking control of many unattended loudspeakers and instructing them to broadcast together. Each speaker contributes to a coordinated disturbance even though its owner did not approve the message.

The analogy explains coordination and innocent owners. Real devices can do much more than broadcast: they may relay traffic, expose information or run additional software. A botnet also need not make every device perform the same action at the same moment.

Worked example

Consider a fictional office with 120 managed devices. An investigation finds eight communicating with confirmed malicious infrastructure during a defined hour. Analysts classify five as confirmed compromised, two as requiring further investigation and one as a legitimate research system whose connection was authorized.

The confirmed-compromise proportion is 5 divided by 120, or about 4.2%, for the assessed inventory and evidence. It is not 8 divided by 120 simply because eight connections were observed. The two unresolved devices must remain visible in the investigation record.

Nor does the 4.2% figure prove that the other devices are clean. Some may have been offline or outside the monitoring coverage. If two records describe the same physical device, the count also needs correction. The example shows why a useful incident summary separates observations, confirmed findings, uncertainty and the population actually examined.

Illustrative case study

Illustrative case study: A fictional design studio receives an alert about unexpected traffic from its office internet address. Staff initially suspect a workstation. Inventory review instead identifies an old router whose support status and administrative settings have not been reviewed for years.

The studio's authorized support team investigates, contains the affected equipment and plans a supported replacement. It also checks relevant accounts and other devices rather than assuming that replacing one box resolves every possible consequence. The team records what was confirmed and what remains uncertain before reconnecting services.

This invented scenario illustrates the value of device ownership and response planning. It is not a report of a particular botnet infection or a guarantee that the same remediation would suit every device.

Common misconceptions and mistakes

Assuming only desktop computers can join a botnet.
Treating every automated account, chatbot or web crawler as malicious.
Concluding that a suspicious internet address identifies the responsible human attacker.
Assuming a temporary loss of contact with a control service means the device is fully recovered.
Counting alerts as unique infected devices without checking duplication and evidence.

Business use

For businesses, the practical aim is to reduce opportunities for compromise and respond coherently when evidence appears. Maintain an inventory that includes networking equipment and connected appliances, with responsibility for updates and replacement decisions. Unsupported devices deserve particular attention because fixes may no longer be available.

Separate incident facts from assumptions when communicating with staff or customers. Use the organization's response process to coordinate containment, evidence handling, recovery and service restoration. An AI-assisted alert summary can help organize observations, but it should preserve uncertainty and should not turn an unexplained connection into a confirmed attribution.

Check your understanding

Eight devices contacted a suspicious service, but only five are confirmed compromised. Should the report call all eight infected?

Answer: No. Report five confirmed findings, two unresolved cases and the authorized research connection separately, while stating the limits of the investigation.

Related terms

Malware
Incident response
Command and control
Compromised device
Distributed denial of service
Phishing
Internet of Things
Network monitoring
Threat intelligence

Learn next

Distinguish a device inventory, a security alert and a confirmed incident. Then trace how an organization assigns ownership, investigates suspicious traffic and decides when a recovered device can return to service.

Sources

Primary sources: FBI, Cybercriminal Proxy Services Exploiting End-of-Life Routers: https://www.fbi.gov/investigate/cyber/alerts/2025/cybercriminal-proxy-services-exploiting-end-of-life-routers ; FBI, Qakbot infrastructure disruption and malware explanation: https://www.fbi.gov/news/stories/fbi-partners-dismantle-qakbot-infrastructure-in-multinational-cyber-takedown . Relevant passages reviewed. Office counts and design studio scenario are original fictional examples, not statistics from these incidents.

Previous: Bootstrap test Next: Bottom-up design