Default Credentials Are Still the Front Door: Reading the 2026 IoT Botnet Notices as an Asset Management Problem

In late August 2026, China's National Network and Information Security Notification Centre published a notice covering five active cross-border botnet families: Mirai, CondiBot, Gafgyt, TBot and SoftBot. The command and control nodes listed in the notice were distributed across at least five countries, including the United States, Germany and the Netherlands.

The technical detail in that notice is unremarkable, and that is the point. The initial access methods were Telnet and SSH brute force against unchanged factory credentials, together with exploitation of vulnerabilities that were disclosed years ago. Nothing in the intrusion chain required a novel technique.

The pattern that keeps repeating

Mirai appeared in 2016 and its source code was released publicly. Variants derived from it have been circulating ever since, and the intrusion logic has barely changed: scan for reachable devices, attempt a dictionary of default username and password pairs, download a payload, and add the device to a DDoS-capable swarm.

A newer sample analysed by Nozomi Networks in August 2026, named KATARU after a field in its configuration, follows the same entry path. Researchers captured it after repeated Telnet brute-force attempts against a honeypot, followed by download of an ARM payload. The malware attempts to gain root on the device, survives reboots, and hides its command traffic.

What is different about newer families is not the door they use but what they do afterwards. The Dysphoria botnet, flagged in a July 2026 joint notice from CNCERT and QiAnXin, introduced a control mechanism based on blockchain naming services (ENS and SNS), turning infected devices into relay and proxy nodes. That makes takedown considerably harder, because there is no single domain to seize.

Why these devices stay unpatched

It is tempting to treat IoT botnets as a consumer problem. The 2026 notices describe something broader: cameras, routers, DVR and NVR storage devices, and industrial gateways, many of them deployed in small business and branch environments where no one owns the device after installation.

Three structural issues keep the population vulnerable.

Ownership gaps. The person who installs a camera is rarely the person responsible for updating it. In many small organisations there is no asset register entry for the device at all, so no one receives the vendor advisory.

Firmware lifecycle. Consumer and prosumer hardware often receives a short support window, if any. A device that works perfectly well after three years may have stopped receiving security updates after one. The notice published by the National Notification Centre explicitly recommends that procurement contracts include a firmware security maintenance clause requiring a defined period of security updates.

Exposed management interfaces. Telnet and unauthenticated HTTP management interfaces remain enabled by default on a meaningful share of devices. Where the service is reachable, the credential is the only control, and the credential is often the factory default.

What actually reduces the population at risk

The measures that work are unglamorous and mostly administrative.

Inventory the devices. You cannot patch or decommission what you have not recorded. For branch and small-site environments, this means a register that includes network devices, cameras, recorders and any gateway with a management interface, along with the responsible owner.

Change credentials at deployment, and enforce it. The recommendation to set a strong unique password on first use is well known and still not universally applied. Where a device supports it, disable remote management from the internet entirely and require access through a management network.

Close the unnecessary services. Telnet should not be enabled on a device that supports SSH, and neither should be reachable from outside the management network. Where a device offers a cloud relay, use it instead of exposing the local interface.

Set a replacement date at purchase. Because firmware support windows are short, the procurement decision should include an expected service life and a plan for replacement when updates stop. A device that cannot be updated should be treated as a device with a known end-of-support date, not as a permanent fixture.

Segment the device network. Cameras and building systems rarely need to reach corporate file shares or domain controllers. Network separation limits what an infected device can do beyond participating in a DDoS swarm.

The uncomfortable conclusion

The 2026 botnet notices are not describing a sophisticated adversary. They are describing an adversary with a large dictionary and a lot of patience, working against a device population that was never designed to be maintained.

That means the effective control is not a detection signature. It is knowing which devices you own, whether they are still supported, and whether anyone is responsible for them. Organisations that can answer those three questions are largely outside the affected population, regardless of which botnet family is active this quarter.

References

• National Network and Information Security Notification Centre notice on cross-border botnet families, August 2026.
• CNCERT and QiAnXin joint risk notice on the Dysphoria botnet, July 2026.
• Nozomi Networks analysis of the KATARU IoT malware sample, August 2026.