Mirai Botnet

What Mirai taught defenders

Mirai is a well-known botnet family associated with large-scale DDoS attacks launched from compromised internet-connected devices. Its importance is not just historical. Mirai showed that cameras, routers, recorders, and other embedded devices can become powerful attack infrastructure when they are exposed online, protected by weak credentials, and rarely maintained after installation.

For defenders, Mirai is a lesson about scale and neglect. Many individual devices have limited computing power. When thousands or millions of them are coordinated, the combined traffic can create serious availability pressure. The owners of those devices may be homes, small businesses, schools, shops, or service providers that have no relationship to the eventual victim.

This page focuses on defensive understanding. It does not describe how Mirai operates in a way that would help someone build, run, or reproduce a botnet.

Why IoT botnets are hard to eliminate

IoT botnets persist because the internet contains many devices that are installed and then forgotten. Some ship with insecure defaults. Some expose management services to the public internet. Some have weak or reused credentials. Some never receive updates after purchase. Others are owned by people who do not think of them as computers, even though they run software, listen on networks, and can be remotely abused.

The economics also favour attackers. Compromised devices are distributed across consumer and business networks, which makes simple source blocking difficult. A DDoS victim may see traffic from many countries, autonomous systems, and access networks. Many sources may be real devices behind real connections, not easily identifiable data-centre traffic. Some devices may be cleaned up while new ones are compromised elsewhere.

Mirai also changed how defenders think about responsibility. An organisation can be affected in two ways: its public service can be the target of botnet traffic, or its own unmanaged devices can become participants in attacks against others. Good defence includes both service resilience and asset hygiene.

What an attack may look like

A Mirai-like DDoS event can present as high packet rates, high bandwidth, connection floods, or application request pressure depending on the traffic pattern used by the botnet and the exposed surface of the victim. Users may see timeouts, slow responses, intermittent reachability, failed logins, degraded APIs, or complete service outage if upstream links or edge systems are saturated.

Indicators include sudden traffic from a wide range of residential or small-business networks, abnormal request rates, repeated connection attempts, unusual protocol mixes, rising error rates, overloaded firewalls or load balancers, and origin systems seeing more traffic than normal. At the application layer, defenders should compare route patterns, methods, user agents, cache outcomes, request durations, and session behaviour against expected user journeys.

Source reputation is helpful but incomplete. Many compromised devices sit on networks that also carry legitimate users. Blocking an entire provider, country, or access network may reduce attack volume but harm real customers. During triage, teams should identify whether mitigation can happen at the network edge, per route, by protocol, by behaviour, or by a combination of signals.

Reducing exposure in your own environment

Organisations should treat connected devices as managed assets. Cameras, printers, routers, building systems, kiosks, storage appliances, development boards, and monitoring devices need owners, patch status, network placement, and retirement plans. If a device cannot be patched or monitored, it should not sit on a flat network with broad access.

Basic hygiene is powerful: change default credentials, disable unused remote access, restrict management interfaces to trusted networks, apply firmware updates, remove unsupported devices, and segment device networks from business-critical systems. Where possible, outbound traffic from device networks should be limited to expected destinations. A camera does not normally need unrestricted access to arbitrary internet hosts.

Procurement matters too. Before buying connected devices, teams should ask how updates are delivered, how long the vendor supports the product, whether default credentials are unique, whether management access can be restricted, and what logs are available. Cheap devices can become expensive if they create incident response work, privacy risk, or outbound abuse complaints.

Building resilience against botnet DDoS

For services that may be targeted, resilience starts with knowing critical paths. Which hostnames, IP addresses, APIs, login flows, checkout routes, DNS providers, and upstream links are required for users to complete important tasks? Which of those can absorb botnet-scale traffic, and which depend on a small origin or stateful component?

Layered controls help because botnet traffic can shift. Network-level DDoS protection and upstream filtering can absorb packet and bandwidth pressure. Edge caching and origin shielding reduce avoidable dynamic work. Rate controls, connection limits, bot detection, and application firewall policy protect specific routes. Queue limits, timeouts, circuit breakers, and graceful degradation reduce the blast radius when a dependency is strained.

Evaluation should measure clean-user continuity, not just blocked traffic. During an event, are legitimate users still resolving DNS, establishing connections, loading public content, authenticating, and completing critical workflows? A mitigation that produces impressive block numbers but breaks key users is not sufficient.

Common misconceptions

One misconception is that Mirai was a one-time event. The original name is historical, but the model continues: insecure connected devices are repeatedly recruited into new botnets and variants.

Another misconception is that only large enterprises are targets. Smaller sites, game servers, schools, local services, and community platforms can be targeted because the attacker's cost may be low.

A third misconception is that IoT security is separate from web availability. The same device hygiene failures that create botnets can also affect internal operations, privacy, physical security, and business continuity.

Response and review

A Mirai-like DDoS runbook should define who monitors traffic, who contacts upstream providers, who can adjust edge policy, who watches application health, and who communicates user impact. It should also identify evidence to collect: timestamps, traffic classes, affected services, mitigation actions, false positives, provider notes, and any related extortion or abuse messages.

If the organisation discovers its own devices participating in abuse, the response path is different but just as important. Isolate affected devices, preserve logs where available, remove public exposure, change credentials, update firmware, and check whether the device network has signs of broader compromise. If devices cannot be secured, retire or replace them.

After any botnet-related incident, review both sides of the problem. Could the protected service absorb distributed traffic without losing clean users? Could the organisation's own devices be abused by someone else? Mirai remains relevant because it turned ordinary neglected devices into a collective availability threat. Durable defence combines internet-facing DDoS resilience with disciplined management of the devices an organisation puts online.