Botnets and Mirai: How IoT Devices Get Hijacked and Secured
Most connected gadgets aren’t built like traditional computers, yet they live on the same networks and talk to the same internet. That mismatch is why botnets love them. A cheap camera with a guessed password can suddenly help flood a target with traffic. If you’ve ever wondered how that happens and how to stop it, we’ll walk through the mechanics and the fixes in plain terms.
Two ideas unlock the story. First, many devices ship with remote services exposed and weak defaults, which makes them easy to crawl and break into at scale. Second, once a single foothold is gained, automation handles the rest: identify the platform, fetch the right payload, phone home, and wait for attack commands. You don’t need a master hacker at every step—just a lot of identical doors left unlocked.
We’ll focus on Mirai because it defined the playbook: rapid internet scanning, credential stuffing against remote shells, simple but effective flooding modules, and a command-and-control (C2) tier that can steer hundreds of thousands of nodes. Variants still copy this pattern today, sometimes swapping the initial break-in from weak passwords to web interface exploits. The defensive playbook is also stable: shrink exposure, segment traffic, patch faster, and watch for telltales.
Before we dive into countermeasures, a quick mental model helps: exposure brings compromise, compromise brings coordination, coordination brings scale. Break any one of those and you ruin a botnet operator’s day.
How Mirai Turns IoT Into a Botnet
Classic Mirai hunts the public internet for devices that answer on Telnet (TCP 23/2323) or similar remote shells. It tries a short list of factory usernames and passwords against these services. When one works, the compromised device is told to retrieve a small binary compiled for its CPU, such as ARM, MIPS, or PowerPC. That binary kills competing malware processes so it owns the limited CPU and RAM, then connects to a C2 to receive attack instructions. Persistence is usually minimal; many samples live only in memory, so a power cycle wipes them—until the scanner finds the device again minutes later.
Inside the Infection Pipeline
The workflow looks like this: a scanner sprays the address space, a “report” server records successful logins or exploit results, and a “loader” pushes the correct bot binary over protocols the device allows (often HTTP/TFTP). The bot immediately opens a control channel to the C2, sometimes using a domain that operators can rotate. Because the bot knows the device’s architecture, the loader ships the exact binary that fits the kernel and instruction set.
What Attacks Botnets Launch
Mirai’s modules favor simple volumetric floods that are hard to filter at scale: TCP SYN/ACK floods that exhaust connection tracking, UDP floods that saturate links, GRE floods that force routers to do extra work, and HTTP GET floods that drown web stacks. Volumetric floods don’t need clever payloads; they just need a lot of sources that can each push a modest stream. Cameras and small routers are perfect for that.
Why IoT Devices Get Owned
It’s not one thing—it’s a stack of small shortcuts that add up. Devices ship with default credentials and remote admin enabled, management interfaces sit on public IPs, and automatic updates are rare or disabled. Many products expose legacy protocols like Telnet or ship web UIs with command-injection bugs. When a severe bug lands in a popular model, attackers scan for it within hours and fold new victims into existing botnets.
Weak Defaults and Exposed Services
Default usernames and passwords are deadly because they’re guessable at internet scale. Even if you changed the password, leaving Telnet exposed means any new vulnerability can still bite you. Some consumer gateways also expose TR-069/TR-064 management services on TCP 7547; when those are misconfigured or vulnerable, they become mass-exploitation magnets.
Slow Updates and Long Tails
Small vendors may not maintain firmware, and users don’t always know how to apply updates. Even when patches exist, old stock continues to ship and stays online for years. That “long tail” is why Mirai variants keep finding fresh hosts every day.
Hardening Playbook for Homes and Organizations
You don’t need to be perfect—you need to remove the easy wins attackers count on. Think of it as three layers: reduce exposure, fence devices, and watch the exits.
Inventory and Segmentation
Start with a list: what’s on your network, what it’s for, and which VLAN or SSID it lives on. Put untrusted devices on their own network with no lateral access to laptops or servers. Deny east-west traffic except what’s explicitly required. A small “things” SSID plus a management VLAN goes a long way.
Lock Down Management Interfaces
Disable Telnet everywhere and prefer SSH only on internal segments. Turn off remote admin from the internet and require a VPN for any off-site management. Change default credentials on day one and use unique passwords per device. If a device cannot disable risky services, place it behind an access control list that blocks inbound 0.0.0.0/0 and limits outbound to what it truly needs.
Patch Faster and Track Vulnerabilities
Enable automatic updates when available and subscribe to vendor advisories for models you own. When a severe bug drops for a common router or camera, assume active scanning has already started. Apply the fix or, if none exists, isolate or replace the device. Build a simple calendar reminder to review firmware quarterly.
Egress Controls and DDoS Readiness
Block or rate-limit outbound traffic patterns you don’t expect from gadgets, such as high-rate UDP to random internet hosts or HTTP floods to a single domain. On upstream firewalls, cap outbound PPS (packets per second) for IoT VLANs so a single compromised gadget can’t saturate your link. Keep your ISP’s DDoS contact and know how to null-route if your public IP is abused.
Detection and Forensics on Your Network Gear
Most compromises are noisy if you look. A tiny camera shouldn’t open thousands of outbound connections per minute or resolve dozens of domains quickly. NetFlow or simple firewall logs can surface that pattern in minutes. If you see sudden CPU spikes on the gadget, sluggish video streams, or your uplink graph pegged without a legitimate reason, investigate.
Indicators of Compromise You Can Check
Look for repeated failed logins to Telnet/SSH, processes named oddly for the platform, and outbound connections to hardcoded C2 addresses. DNS queries to random-looking domains or sudden spikes in GRE/UDP are also red flags. If you can shell in, check for unfamiliar binaries in /tmp and busybox processes spawned by unknown parents.
Testing Your Defenses Without Breaking Things
Use harmless scanners on your own external IP to confirm nothing exposes Telnet/SSH/HTTP unnecessarily. Run a small synthetic monitor that fetches your gateway’s CPU and interface counters, and alert on sustained outbound spikes. If you have a lab, replay a traffic capture of a SYN flood from an isolated port to see whether your egress caps kick in.
Buying Better Devices Next Time
Pick vendors who commit to security updates and publish firmware timelines. Favor products that support automatic updates, unique default credentials, and features like WPA3. For larger environments, look for support of the Manufacturer Usage Description (MUD) standard so your network can automatically apply least-privilege policies per device class. If a device cannot meet those basics, price alone is a trap: risk and replacement costs will eat any savings.
Policy as Code for IoT: MUD in Practice
MUD lets a device advertise “I only talk to these services and domains,” and lets your switches or firewall enforce that claim. That turns segmentation from a manual spreadsheet into an automated contract between the device and the network. It won’t stop a vendor from shipping a vulnerable web UI, but it does contain blast radius when something goes wrong.
What Usually Backfires
Two moves tend to cause trouble. First, exposing device web UIs to the internet for convenience—bots find them quickly. Second, relying on reboots as a long-term fix—Mirai-style scanners simply reinfect, sometimes within minutes. Treat a reboot as containment, not remediation; the real fix is to remove the exposure and update the firmware.
A Minimal Incident Response for a Suspected Bot
If you suspect a gadget is part of a botnet, disconnect it from the internet or block its VLAN’s egress immediately. Snapshot logs if you can. Factory-reset the device, apply the latest firmware before reconnecting, and change credentials. Then review your perimeter: close or forward-only the necessary ports, disable UPnP, and confirm remote administration stays off. Finally, monitor for at least a day; if the same IP or hostname reappears in logs, investigate other devices on the same segment.
The Payoff
Small, steady changes—unique credentials, no exposed services, tight segments, and egress limits—remove the easy wins from attackers and make your network dull and unprofitable to scan. That’s the goal. You won’t stop new bugs from being discovered, but you’ll turn mass exploitation into a much harder, noisier job.