Tengu-Botnet: Wenn der Hardware-Watchdog die Forensik aushebelt
08.08.2026 iot-forensicsmiraianti-forensicsembedded-linux
Ende Juli 2026 veröffentlichte Nozomi Networks Labs die Analyse einer neuen Mirai-Variante namens Tengu – und liefert damit ein Lehrstück dafür, wie ein legitimes Sicherheitsfeature eingebetteter Linux-Systeme zur Anti-Forensik-Waffe umfunktioniert werden kann. Die Entdeckung erfolgte über ein maschinelles Lernsystem von Nozomi Networks Labs, das Tengu zunächst unter unbekannten Malware-Familien markierte, bevor Forscher eine manuelle Tiefenanalyse durchführten. Verbreitet wird die Malware klassisch: Nozomi Networks Labs beobachtete, wie der Dropper über Telnet-Credential-Brute-Force auf ihre Honeypots gelangte.
Der Watchdog-Trick: Ein Reboot als Anti-Forensik-Werkzeug
Kern der forensischen Brisanz ist ein Mechanismus, der branchenüblich eigentlich der Systemstabilität dient. Der Hardware-Watchdog-Timer ist ein speziell entwickelter Sicherheitsschaltkreis, der praktisch in jedem eingebetteten Linux-Gerät vorhanden ist – Router, IP-Kameras, digitale Videorekorder, Smart-Home-Hubs. Seine Aufgabe ist es, einen Systemreset zu erzwingen, wenn die Hauptsoftware nicht mehr reagiert, um entfernte oder unbeaufsichtigte Geräte vor dauerhaften Blockaden zu schützen. Tengu dreht diese Schutzfunktion um: Ein Hintergrundprozess maskiert sich als [kworker/0:0], öffnet das Watchdog-Gerät erneut, aktiviert es mit einem Timeout von etwa 30 Sekunden und sendet Keepalive-Signale nur, solange der Hauptprozess der Malware am Leben ist.
Tötet ein Incident Responder den Hauptprozess, bleibt das Keepalive-Signal aus – die Konsequenz beschreibt SC Media so: wird der Watchdog nicht mehr gefüttert, was einen Geräte-Reboot auslöst, der wiederum Tengus weitere Persistenzmechanismen reaktiviert. Für die forensische Praxis bedeutet das den vollständigen Verlust flüchtiger Beweise: Laufende Prozesslisten, offene Netzwerkverbindungen, Artefakte im Arbeitsspeicher – alles, was ein Responder zur Dokumentation der Infektion bräuchte, verschwindet. Währenddessen hat sich Tengu über systemd-Service-Einträge, init.d-Skripte, Shell-Startdateien und Cron-Verzeichnisse verankert. Das Gerät kommt wieder online, die Malware läuft erneut, und ein Responder, der den Watchdog-Trick nicht kennt, wird das Gerät fälschlich für bereinigt halten.
Zusätzlich erschwert Tengu die Nachanalyse durch Manipulation der Wiederherstellungswerkzeuge selbst: Die Malware nutzt außerdem memfd_create, um vollständig aus dem RAM zu laufen, tarnt sich als Systemdienst und beschädigt ELF-Header von Reboot-Utilities, um die Wiederherstellung zu erschweren. Ergänzt wird dies durch Integritätsprüfungen: Tengu überwacht seinen eigenen Ausführungszustand und prüft, ob sein Code verändert wurde. Die Malware liest Memory-Mapping-Informationen aus dem Linux-proc-Dateisystem, berechnet einen SHA-256-Basiswert für Teile ihres Codes und vergleicht das Ergebnis wiederholt, um Manipulationen zu erkennen.
Konsequenzen für die IR-Praxis
Das eigentliche Problem für Verteidiger liegt nicht in Tengu selbst, sondern in der Übertragbarkeit der Technik: Der Fund ist bedeutsam über diese einzelne Variante hinaus – die von Tengu genutzte Technik ist kein geräte-spezifischer Exploit, sondern eine architektonische Eigenschaft, die in praktisch jedem eingebetteten Linux-Gerät auf dem Markt vorhanden ist, was bedeutet, dass jeder Mirai-Malware-Autor sie nun kopieren kann. Historisch hat sich genau dieses Muster bereits mehrfach bestätigt, seit die ursprüngliche Mirai-Botnet 2016 veröffentlicht wurde, hat sich jede neu auftretende Fähigkeit im Mirai-Ökosystem durch Nachfolgevarianten verbreitet.
Für Incident Responder ändert sich damit die Reihenfolge des Vorgehens fundamental: Die zentrale Änderung, die Tengu von Respondern verlangt, ist die Sequenzierung: Beweissicherung muss vor jeder Aktion erfolgen, die einen Reboot auslösen könnte, denn ein Reboot wird die Beweise zerstören. Nozomi rät Respondern, flüchtige Artefakte – Prozesslisten, Netzwerkverbindungen, Speicherforensik – zu erfassen, bevor ein Beendigungsversuch unternommen wird. Ein einfacher Neustart reicht zur Bereinigung ohnehin nicht mehr aus: Weil einfache Reboots die Malware nicht eliminieren, erfordert die Sanierung arbeitsintensive manuelle Eingriffe, einschließlich vollständiger Werksrücksetzungen, Firmware-Reflashings oder kompletter Hardware-Bereinigung.
Für DFIR-Teams, die IoT- und Edge-Geräte in Scope haben, ist Tengu damit weniger eine einzelne IOC-Liste als ein Weckruf: Standard-Playbooks, die auf „Prozess killen, dann analysieren" setzen, müssen für eingebettete Linux-Systeme grundlegend überarbeitet werden – mit Live-Memory-Capture, Netzwerk-Traffic-Snapshot und Integritätsprüfung der Recovery-Binaries als festen ersten Schritten, bevor überhaupt ein Kill-Signal gesendet wird.
← Zurück zur Übersicht