Tengu Botnet's Hardware Watchdog Trick: A New Persistence Level?
Just caught the report from Nozomi Networks Labs regarding the new Tengu botnet. It seems we have a new Mirai variant that is taking persistence to a frustrating level by leveraging hardware watchdogs.
The mechanism is clever in a destructive way: if defenders kill the bot's main process, the hardware watchdog timer expires, forcing a reboot of the compromised Linux device. This gives Tengu's persistence mechanisms (like cron jobs or init scripts) a fresh chance to respawn the malware. It's a significant step up from standard forking techniques.
Since it spreads via Telnet brute force, basic credential hygiene is still the first line of defense. However, standard incident response involves killing malicious processes. If Tengu is running, killing the parent process triggers the watchdog. Usually, you can disable a watchdog by writing a specific magic character ('V') to the device, but if the process is killed abruptly (SIGKILL), that never happens.
For detection on Linux servers, I'd suggest monitoring for interactions with the watchdog device, which is often unused in standard container or server setups:
# Identify processes holding the watchdog device open
sudo lsof /dev/watchdog
# Check dmesg for watchdog initialization or timeouts
sudo dmesg | grep -i "watchdog"
Given that Tengu supports 25 DDoS vectors, the payload is dangerous. Are you guys seeing much Telnet traffic on your edge networks still, or has everyone finally moved to SSH-only for IoT management? How are we handling the physical disconnect requirement if software kill fails?
This is exactly why we aggressively disable hardware watchdogs on any Linux server that doesn't have a strict high-availability requirement. If the hardware doesn't need to auto-recover on kernel panic, the watchdog module shouldn't be loaded.
You can blacklist the common Intel watchdog modules to prevent this specific attack vector:
# Blacklist watchdog modules
echo "blacklist iTCO_wdt" | sudo tee /etc/modprobe.d/disable-watchdog.conf
sudo update-initramfs -u
Of course, for IoT devices, you might not have that luxury. In those cases, changing default Telnet credentials is the only real defense before the bot even lands.
From a SOC perspective, the reboot behavior actually makes detection easier if you're monitoring for it. A device that cycles repeatedly every few minutes is a huge red flag.
We use Zeek to monitor for Telnet traffic, which is usually the "canary in the coal mine" for Mirai derivatives like Tengu. A simple script to look for successful Telnet logins followed by a binary download is usually enough to catch the dropper before the watchdog persistence kicks in.
The reliance on /dev/watchdog is interesting. In my experience pentesting IoT, many cheap devices have the kernel module loaded but the actual hardware timer isn't enabled or configured in the bootloader. Still, if the device is vulnerable, Tengu will try it.
If you are cleaning an infected device, don't just kill the process. You need to write the 'V' magic character to the device first to disarm it, then kill the process, then remove the cron jobs. If you kill it first, you lose the session.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access