Mirai botnets are groups of compromised Internet of Things (IoT) devices that an attacker controls to send traffic. The original Mirai spread through exposed Telnet remote administration services and weak credentials. Later Mirai-related campaigns have also used software vulnerabilities, so changing a password addresses only one possible route into a device.

A camera, router, or recorder can become a bot without its owner deliberately installing malware. Recovery requires addressing the weakness that allowed the infection and removing the malware through a procedure supported by the manufacturer. A device that sends less traffic may still be infected.

From Exposed Device to Remotely Controlled Bot

The original infection process had distinct stages: finding a reachable service, obtaining a login, loading malware, and joining the attacker's command system. Other infected devices helped discover more targets. Once recruited, a bot could contribute to attacks that overloaded a remote service.

A device can be infected this way without its owner browsing a malicious website or opening an attachment. A vulnerable network service can be enough. A recorder may continue recording while unauthorized software uses its network connection.

Original Mirai and Later Campaigns

The 2016 Mirai implementation searched IPv4 addresses for Telnet services on ports 23 and 2323, tried username and password combinations stored in the bot, and reported successful access to infrastructure that loaded the bot. The original malware ran in memory and did not survive a system reboot.

Later Mirai variants can behave differently. A 2023 Mirai-related campaign used several command execution vulnerabilities to install bot clients; a client sample from that campaign did not contain spreading functionality. An attacker can therefore conduct recruitment through separate infrastructure rather than relying on every bot to perform the same steps.

Credentials and Software Flaws Need Different Fixes

A default or weak administration password can let an attacker authenticate to a reachable service. Replacing it with a strong, unique password blocks attempts that rely on the old password, provided the affected service uses the changed credential. Check which accounts and interfaces the product exposes instead of assuming that a password changed in one app governs every administrative service.

A software flaw creates a different problem. Some command execution vulnerabilities allow a request to make the device run unauthorized commands. A stronger password does not repair vulnerable code, particularly when the affected operation does not require that password in the first place.

Firmware is the device's built-in software. Check its installed version against the manufacturer's security advisories and supported releases. A model name alone is insufficient when hardware revisions or regional editions require different update images.

Check Device Exposure and Signs of Infection

Find the device in your router's device list, note its model and firmware version, and inspect its account and management settings. Check whether its administration interface is intended to be reachable only locally or through an authenticated service.

Review the router's inbound access rules and any forwarding that exposes the device. A deliberately enabled remote management service is different from an ordinary outbound connection used to contact the manufacturer's cloud. Determine the function of a rule before removing it, especially on equipment managed by your internet provider.

If the device provides logs or security reports, save entries showing unusual connections, unauthorized account changes, or unexpected configuration changes, including their timestamps and device identifiers. Match a network event to the device's address at that time. A connection total alone does not explain whether the activity was an update, ordinary service traffic, or an attack.

Slow internet access or an unfamiliar connection is not by itself proof of a Mirai infection. Suspicious observations justify investigation, while confirmation may require the vendor's diagnostics or a qualified responder's analysis. Keep a record of the symptoms and when they occurred to help identify the cause.

Restrict Access and Keep Firmware Updated

Restrict device management to authorized access and disable unnecessary interfaces or services through the manufacturer's supported controls. This removes opportunities to reach vulnerable administration functions. Preserve the functions needed for legitimate operation rather than assuming that every network connection is an exposure to eliminate.

Apply authentic updates intended for the exact device, using the supported update mechanism. Confirm that the installed version changes to the intended release. Downloading an update does not mean the device has installed it.

Check how long the manufacturer will provide security updates. If the manufacturer no longer supplies fixes for a device that must remain connected, replacement may be the workable long-term response. If replacement is not yet possible, restrict the device's access while planning a supported alternative.

What Network Separation Can Protect

Enforced network separation can restrict a compromised device's access to trusted computers and other local systems. A separate network also lets you restrict connections during an investigation. Network access controls must enforce that separation; simply placing devices in a group labeled IoT does not block traffic.

Separation does not replace a firmware fix, remove an unauthorized program, or automatically stop traffic sent toward the internet. Consider local access and internet access separately. A contained device may remain compromised even when it can no longer contact your file server.

Recovering a Suspected Device

Contain the device's network access before returning it to normal service. For an ordinary device that can safely be disconnected, remove the network path that permits continued control or reinfection. If it performs an essential safety or operational function, use the manufacturer's supported safe state and an appropriate maintenance plan.

Preserve useful logs and the configuration information needed for recovery when doing so is feasible. Restarting or resetting can remove evidence, and a reset can erase settings required to reach the device again. Gather observations without leaving a suspected device broadly exposed merely to watch what it does.

Use the manufacturer's recovery instructions for the exact model. The process may involve a reset, restoration of an authentic firmware image, or another supported procedure. Do not assume that every product's factory reset rewrites its firmware or removes every possible persistence mechanism.

Reapply only the settings needed for secure operation, set the relevant credentials, and complete required security updates before reconnecting the device for normal use. Review a saved configuration before importing it: an old backup can restore the remote access rule or account setting you intended to remove.

Why a Reboot Is Only Part of Recovery

Rebooting stops malware that runs only in memory, as the original Mirai did. It does not change an exposed service, weak credential, or unpatched vulnerability. An unchanged device can be recruited again after it reconnects, and later malware may have a different persistence method.

Check the restored device's firmware version, accounts, management access, and required functions, then monitor the logs or network reports it provides. Note whether suspicious activity returns after recovery. If unexplained activity continues or the device cannot be restored securely, keep its network access restricted while arranging vendor support or replacement.