An IoT botnet is a network of compromised Internet of Things devices, such as cameras, routers, smart plugs and video doorbells, that an attacker controls remotely through command-and-control infrastructure. In smart home privacy, the term describes the most common way a poorly secured household device stops serving its owner and starts serving someone else, usually without any visible sign.
The infected devices, called bots or zombies, keep working normally while they run hidden code that waits for instructions. The operator then rents or uses the combined bandwidth and processing power for distributed denial-of-service (DDoS) attacks, credential stuffing, ad fraud, spam relaying or as residential proxies that disguise criminal traffic as ordinary home traffic.
How an IoT botnet recruits and controls devices
An IoT botnet grows through automated scanning and infection, not through targeted attacks on individual homes. Bots constantly probe random internet addresses for open services such as Telnet on ports 23 and 2323, SSH on port 22, web administration pages and exposed device APIs. When a device answers, the scanner tries a short list of factory default credentials or exploits a known firmware vulnerability.
After a successful login, a loader downloads a binary compiled for the device’s processor architecture, typically ARM, MIPS or x86. The malware often kills competing malware, closes the port it used to enter and then connects to its command-and-control (C2) server. Many families run only in memory, so a simple reboot removes the infection, but an unchanged password lets the device be reinfected within minutes.
The lifecycle below shows the stages a typical infection passes through and what each stage means for the owner.
| Stage | What happens | Effect on the device owner |
|---|---|---|
| Scanning | Bots probe random addresses for open ports | None visible; traffic is outbound from other homes |
| Intrusion | Default password or exploit grants a shell | Device is now under outside control |
| Payload delivery | Loader fetches malware for the CPU architecture | Short burst of unusual traffic |
| Persistence | Malware blocks rivals, sometimes survives reboot | Device may feel slower or reboot oddly |
| Command and control | Bot reports in and waits for orders | Periodic connections to unknown servers |
| Monetization | Floods, proxying, fraud or further scanning | Bandwidth use, possible ISP warnings or blocks |
Why smart home devices make attractive bots
Smart home devices combine several properties that suit botnet operators: they are always on, rarely monitored, connected through fast residential broadband and often run outdated Linux-based firmware. A single camera adds little power, but hundreds of thousands of them produce attack volumes that have reached hundreds of gigabits per second and, for the largest recorded events, several terabits per second.
Residential addresses also carry reputation value. Traffic from a home connection looks legitimate to banks, ticket sellers and streaming services, so criminals pay for residential proxy access to evade fraud filters. Some proxy networks are built from infected devices, and some cheap streaming boxes have shipped with pre-installed proxy or botnet software, which means the device was compromised before it ever reached the buyer.
The table compares device categories by how often they appear in IoT botnets and why.
| Device type | Typical weakness | Relative exposure |
|---|---|---|
| IP cameras and DVRs | Default passwords, exposed web and Telnet services | Very high |
| Home routers | Unpatched firmware, remote administration left on | Very high |
| Android TV boxes | Uncertified firmware, pre-installed malware | High |
| Network storage (NAS) | Internet-facing services with known flaws | High |
| Smart plugs and bulbs | Weak cloud APIs, rarely directly exposed | Low to moderate |
| Certified hub devices | Usually updated; risk rises after end of support | Low |
Notable IoT botnet families
Mirai, first observed in 2016, defined the modern IoT botnet: it used a table of about 60 default username and password pairs and launched DDoS attacks large enough to disrupt a major DNS provider and many popular websites. The public release of its source code produced hundreds of variants that are still active.
Later families changed the method rather than the goal. Hajime spread through a peer-to-peer design without a central server, Mozi used a distributed hash table for resilience, and BrickerBot deliberately damaged insecure devices instead of recruiting them. Newer variants rely less on passwords and more on exploits for unpatched firmware, which makes timely updates as important as strong credentials.
| Family | Spread method | Main use |
|---|---|---|
| Mirai and variants | Telnet brute force, later exploits | DDoS for hire |
| Hajime | Peer-to-peer, default credentials | Unclear; blocked rival malware |
| Mozi | Peer-to-peer over a distributed hash table | DDoS, payload delivery |
| BrickerBot | Telnet brute force | Destroyed device storage |
| Proxy botnets | Exploits and pre-installed firmware | Residential proxy resale, fraud |
Signs of infection and how to protect a home network
Infected devices rarely show obvious symptoms, so protection depends on prevention rather than detection. Owners may notice unexplained upload traffic, a sluggish connection, devices that become hot or unresponsive, or a notice from the internet service provider about abusive traffic from their address.
The most effective defenses are simple and close the entry points that scanners use. The decision table maps each common situation to a measure and the reason it works.
| Situation | Recommended measure | Why it works |
|---|---|---|
| Device uses a shared default password | Set a unique strong password | Defeats credential lists used by scanners |
| Firmware update available | Install updates or enable automatic updates | Closes exploited vulnerabilities |
| Router forwards ports or uses UPnP | Disable UPnP and unneeded port forwarding | Removes direct exposure to scanning |
| Many low-trust devices at home | Place them on a guest or IoT network | Limits spread to computers and phones |
| Device past end of support | Replace or disconnect it | Unpatched flaws stay open permanently |
| Suspected infection | Reboot, factory reset, change credentials | Clears memory-resident malware and reentry |
IoT network isolation does not prevent infection by itself, but it stops a compromised camera from attacking laptops and phones on the same network. Regulatory baselines such as ETSI EN 303 645, the UK PSTI regime and the U.S. Cyber Trust Mark target the root causes by banning universal default passwords and requiring a published security update period.
Common misconceptions about IoT botnets
- A working device is a clean device. Bot malware is designed to stay quiet and leave the main function untouched.
- Only expensive devices are targeted. Scanners do not select by brand or price; any reachable device with a weak login qualifies.
- A reboot fixes everything. It clears memory-resident malware, but an unchanged password allows reinfection almost immediately.
- Botnets are only a problem for the victims of attacks. Owners also face bandwidth costs, ISP blocks and the risk that traffic from their address is linked to crime.
- Privacy is not affected. A compromised camera or hub can expose video, audio and network data, so a botnet infection is also a privacy breach.
A non-technical view
An IoT botnet is a hidden army of hijacked gadgets. Criminals use automated programs that knock on millions of internet-connected devices every day, looking for ones that still use the password they had when they left the factory. When the door opens, the gadget quietly joins the army while it keeps doing its normal job.
Think of it as someone copying the key to many houses and using the garages to store stolen goods, while the owners notice nothing. The key takeaway is simple: change default passwords, install updates and retire unsupported devices, and most of these break-ins never happen.
A concrete example
A family installs two inexpensive Wi-Fi cameras and a network video recorder, keeps the default administrator password and lets the router open ports automatically through UPnP so the cameras can be viewed remotely. Within a day, a scanner finds the recorder through its exposed Telnet service and installs a Mirai variant.
Weeks later, the family notices that video calls freeze in the evenings, and their internet provider sends a notice that their address took part in a DDoS attack. A technician finds constant outbound connections from the recorder, performs a factory reset, installs current firmware, sets unique passwords, disables UPnP and moves all cameras to a separate IoT network. The outcome: upload traffic returns to normal, the provider lifts the warning and the devices stay clean during later checks.