Tengu Botnet: Using Hardware Watchdogs for Persistence
Has anyone taken a deep dive into the new Tengu botnet reported by Nozomi Networks? It's another flavor of Mirai, but the persistence mechanism caught my eye. It's abusing the Linux hardware watchdog to ensure survivability.
If defenders kill the main process, the hardware watchdog triggers a device reboot because the process stops "kicking" the timer. This gives Tengu's dropper and persistence scripts a chance to respawn. The infection vector is classic Mirai style: Telnet brute force targeting Linux devices.
Since it supports at least 25 DDoS vectors, you want to catch this early. One immediate check is seeing what has the watchdog device open. Legitimate daemons like systemd-watchdog might use it, but malware binaries will stick out.
lsof /dev/watchdog
If you don't use the watchdog for failover, you can attempt to restrict access or audit its usage via `auditd`.
auditctl -w /dev/watchdog -p rwxa -k tengu_watchdog
Combined with blocking Telnet (if possible), this should help contain it. However, in embedded environments, you can't always just kill the watchdog functionality without breaking failover logic. How are folks handling persistence on IoT devices where patching isn't an option? Are you isolating them in VLANs and accepting the risk?
Great post. We just deployed a Sigma rule to catch lsof anomalies on our critical assets. From the SOC side, we look for the sudden reboot followed by immediate outbound flood traffic.
title: Potential Tengu Botnet Watchdog Abuse
detection:
selection:
process|name: 'lsof'
cmdline|contains: '/dev/watchdog'
condition: selection
We've seen a few hits on our honeynets mostly, but none on prod yet. Still, blocking Telnet at the edge is step zero.
If you aren't using the hardware watchdog (rare on servers, common on IoT), just blacklist the module to be safe. It saves you the headache of the reboot loop if you do kill the process.
echo "blacklist watchdog" >> /etc/modprobe.d/blacklist.conf
echo "blacklist softdog" >> /etc/modprobe.d/blacklist.conf
update-initramfs -u
That said, for actual routers/cameras, you can't do this easily. You really need to disable Telnet entirely via telnetd removal or firewall drops, as brute force is the entry point here.
Solid point on the persistence. If you suspect a process but want confirmation before it forces a reboot, use strace to see if it's actively interacting with the watchdog. You'll catch the writes to the device that are intended to keep the system alive. Here is a quick check on a suspicious PID:
strace -p -e trace=open,write
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access