Okay, lass uns mal ehrlich sein. Wenn du diesen Artikel liest, dann gehörst du wahrscheinlich zu den Leuten, die nachts wach liegen und sich fragen ob da vielleicht was auf ihrem System läuft, das sie nicht sehen können. Willkommen im Club. Ich hab mich die letzten Wochen intensiv mit einem Thema beschäftigt, das die meisten Linux-User entweder ignorieren oder für Science-Fiction halten: Kernel-Rootkits und wie man sie aufspürt.
Spoiler vorab: Es ist komplizierter als du denkst. Aber auch faszinierender.
---
Das Problem das keiner sehen will
Stell dir vor du fragst deinen Kernel "Hey, welche Prozesse laufen gerade?" und er antwortet brav mit einer Liste. Sieht gut aus, oder? Aber was wenn ich dir sage dass dein Kernel dich anlügen kann? Nicht weil er böse ist, sondern weil jemand ihm beigebracht hat bestimmte Dinge zu verschweigen.
Das ist im Kern das was ein Kernel-Rootkit macht. Es sitzt da unten im Ring 0, manchmal sogar noch tiefer, und filtert einfach raus was du nicht sehen sollst. Du rufst `ps aux` auf und siehst 127 Prozesse. In Wirklichkeit sind es 128. Dieser eine versteckte Prozess? Der telefoniert gerade nach Hause.
Das Fiese daran ist dass jedes Tool das du auf deinem System ausführst durch den Kernel muss. Und wenn der Kernel kompromittiert ist dann ist jede Antwort die du bekommst potenziell eine Lüge. Das nennt man das Blue Pill Problem, benannt nach dem Film Matrix. Du steckst in einer simulierten Realität und weisst es nicht mal.
Ich hab mich gefragt wie man da rauskommt. Wie kann man einem System vertrauen das möglicherweise schon kompromittiert ist? Die Antwort ist nicht einfach, aber es gibt sie. Und sie ist verdammt elegant.
---
Der Kernel vergisst immer irgendwo
Nach wochenlanger Recherche durch akademische Paper und Sicherheitstools bin ich auf etwas gestossen das ich das Vergesslichkeitsprinzip nenne. Die Idee dahinter ist so simpel dass sie fast schon poetisch ist.
Wenn ein Rootkit sich verstecken will muss es sich aus den Datenstrukturen löschen die das Betriebssystem zur Anzeige nutzt. Unter Linux heisst das konkret es entfernt sich aus der task_struct Liste für Prozesse oder aus der modules Liste für Kernel-Module. Soweit so logisch.
Aber hier kommt der Haken. Der Kernel führt nicht nur eine Liste. Er führt verdammt viele Listen. Für verschiedene Zwecke. Und ein Rootkit müsste sich aus allen löschen um wirklich unsichtbar zu sein.
Nehmen wir mal Kernel-Module als Beispiel. Ein Modul kann sich aus der Hauptliste entfernen, dann zeigt lsmod es nicht mehr. Aber es existiert wahrscheinlich noch im module_kset weil /sys/module/ irgendwoher seine Daten bekommen muss. Es steckt noch im mod_tree, einem Red-Black-Tree den der Kernel für schnelle Adressauflösungen braucht. Es liegt noch in der vmap_area Liste weil das Modul ja irgendwo im virtuellen Speicher existieren muss. Es ist in der module_bug_list registriert damit Kernel-Panics richtig zugeordnet werden können. Und wenn es Tracing nutzt steht es in den ftrace_mod_maps.
Das sind sieben verschiedene Orte wo ein Modul auftauchen kann. Sieben Chancen für uns es zu erwischen.
Es gibt ein Tool namens ModXRef das genau das macht. Es vergleicht alle diese Datenquellen und sucht nach Diskrepanzen. In Tests mit 55 verschiedenen Rootkits auf Kernel-Versionen von 2.6 bis 6.13 hatte es eine Erkennungsrate von hundert Prozent. Ja wirklich. Hundert Prozent. Weil selbst die ausgefeiltesten Rootkits irgendwo vergessen sich zu löschen. Der Kernel ist einfach zu komplex geworden. Zu viele Querverweise, zu viele Subsysteme die voneinander abhängen.
Für Prozesse funktioniert das genauso. Das Volatility Plugin linux_psxview vergleicht die normale Prozessliste mit der PID Hash Table, mit dem SLAB Allocator Cache, mit physischen Speicherscans. Ein Prozess kann sich aus der Hauptliste ausklinken aber er muss in der PID Hash Table bleiben um Signale empfangen zu können. Er muss im Scheduler sein um CPU-Zeit zu bekommen. Diese Invarianten kann ein Rootkit nicht brechen ohne sich selbst kaputtzumachen.
Das ist meiner Meinung nach der robusteste Ansatz den wir haben. Er funktioniert unabhängig von der konkreten Technik die das Rootkit benutzt. Egal ob Syscall-Table-Hooking, ftrace-Hooks oder VFS-Manipulation. Wenn sich etwas versteckt hinterlässt es Spuren in den Nebenstrukturen. Der Kernel ist sein eigener Verräter.
---
Jeder Hook kostet Zeit
Jetzt wird es ein bisschen nerdig aber bleib dran. Es ist brillant.
Jeder Code der ausgeführt wird braucht CPU-Zyklen. Das ist Physik, daran kann kein Rootkit etwas ändern. Wenn ein Rootkit einen Syscall hookt, also abfängt und durch eigenen Code leitet, dann dauert dieser Syscall länger als normal. Das ist unvermeidlich.
Die Frage ist nur wie viel länger. Ein optimierter ftrace-Hook kostet vielleicht 50 CPU-Zyklen, das sind etwa 16 Nanosekunden auf einem modernen Prozessor. Ein eBPF-Hook liegt bei 100 bis 200 Zyklen, also 30 bis 66 Nanosekunden. Ein klassischer Kprobe der über Traps arbeitet kostet über 6000 Zyklen, das sind mehr als 2 Mikrosekunden.
Aber das ist nur der Overhead der Hook-Infrastruktur. Die eigentliche Rootkit-Logik kommt noch obendrauf. Wenn das Rootkit bei jedem Verzeichnislisting prüfen muss ob ein Dateiname versteckt werden soll, dann macht es String-Vergleiche, Speicherzugriffe, vielleicht Sprünge in andere Funktionen. In Experimenten mit einem Test-Rootkit namens CARAXES wurden Verzögerungen von bis zu 60 Mikrosekunden gemessen. Das ist eine Ewigkeit für einen Computer.
Es gibt ein Framework namens Trace of the Times das genau das ausnutzt. Es verwendet eBPF um die Ausführungszeit einzelner Kernel-Funktionen zu messen. Nicht den ganzen Syscall, das wäre zu verrauscht, sondern die internen Funktionen wie filldir64 oder verify_dirent_name. Die Isolation auf Funktionsebene reduziert das Rauschen durch I/O-Operationen und macht die Messung präziser.
Die Ergebnisse sind beeindruckend. Über 98 Prozent Erkennungsgenauigkeit, selbst unter simulierter Systemlast mit stress-ng. Das System lernt eine Baseline des normalen Verhaltens und erkennt statistische Abweichungen durch Hooks.
Aber hier kommt der Haken an der Sache. Timing-Analysen funktionieren nur gegen Hooking-Rootkits. Gegen DKOM, Direct Kernel Object Manipulation, wo nur Datenstrukturen geändert werden ohne zusätzlichen Code auszuführen, hilft Timing nicht. Da verändert sich die Ausführungszeit nicht weil kein zusätzlicher Code läuft. Für DKOM brauchen wir wieder die Cross-View-Analyse.
Aber genau hier liegt die Schönheit der Kombination. Cross-View findet DKOM weil das Rootkit vergisst sich überall zu löschen. Timing findet Hooks weil zusätzlicher Code messbare Zeit kostet. Zusammen erwischen sie fast alles. Das eine kompensiert die Schwächen des anderen.
Was mich an Timing besonders fasziniert ist dass es theoretisch der einzige universelle Detektor ist. Code-Ausführung kostet immer Zeit. Das ist Physik. Daran kann niemand was ändern, nicht mal ein perfektes Rootkit. Es kann sich tarnen so gut es will, aber die Nanosekunden die es für seine Arbeit braucht kann es nicht verstecken.
---
Die Hardware-Ebene oder warum du deinem RAM nicht trauen kannst
Jetzt kommen wir zu dem Teil der mich nachts nicht schlafen lässt. Was wenn das Rootkit so tief sitzt dass es alle Software-basierten Erkennungen manipulieren kann?
Willkommen in der Welt von DMA-Forensik.
DMA steht für Direct Memory Access. Das ist eine Technik bei der Hardware direkt auf den Arbeitsspeicher zugreifen kann ohne die CPU zu fragen. Eigentlich ist das ein Feature für schnelle Datenübertragungen. Deine Grafikkarte nutzt das, deine NVMe SSD auch. Aber es bedeutet eben auch dass ein externes Gerät den RAM auslesen kann ohne dass das Betriebssystem davon weiss.
Tools wie PCILeech nutzen genau das. Mit einem FPGA-Board, kostet so 300 bis 600 Euro, zum Beispiel ein PCIe Screamer, kannst du den kompletten RAM dumpen mit über 190 Megabyte pro Sekunde. Du kannst das Dateisystem live mounten. Du kannst Code in den laufenden Kernel injizieren. Du kannst den Passwort-Check umgehen.
Klingt nach einem Angriffstool? Ist es auch. Aber für Forensik ist es Gold wert. Der Speicherdump den du bekommst ist die absolute Wahrheit. Der Kernel kann nicht lügen weil er gar nicht gefragt wird. Du liest den physischen RAM direkt aus, am Betriebssystem vorbei.
Mit diesem Dump kannst du dann Volatility laufen lassen und die Cross-View-Analyse durchführen. Was du findest ist echt. Keine Manipulation möglich. Das ist der Vorteil von Hardware-basierter Forensik. Du umgehst die gesamte Software-Schicht die ein Rootkit kontrollieren könnte.
Das Coole daran ist dass diese Technik für technisch versierte Desktop-User mittlerweile realistisch umsetzbar ist. Was früher staatlichen Akteuren oder spezialisierten Laboren vorbehalten war wurde durch günstige Hardware und Open-Source-Software demokratisiert. Du brauchst keine esoterische Ausrüstung mehr. Ein FPGA-Board, ein Thunderbolt-Anschluss am Zielrechner, und PCILeech auf deinem Laptop. Das wars.
Thunderbolt ist hier der Angriffsvektor der Wahl weil es PCIe-Signale nach aussen führt. Du musst das Gehäuse des Zielrechners nicht öffnen. Einfach anstecken, dumpen, analysieren. Das funktioniert sogar bei eingeloggten aber gesperrten Rechnern, klassisches Evil-Maid-Szenario.
Aber warte, es gibt noch mehr Ebenen der Paranoia. Was ist mit Ring minus 2? Das ist der System Management Mode, SMM, der noch unter dem Hypervisor läuft. Ein SMM-Rootkit könnte theoretisch sogar DMA-Analysen manipulieren weil es Zugriff auf alles hat. Der SMM-Handler wird beim Boot geladen und läuft komplett transparent für das Betriebssystem. Wenn der kompromittiert ist, dann wars das.
Hier kommen TPM und Measured Boot ins Spiel. Das Trusted Platform Module speichert Hash-Werte von allem was beim Boot geladen wird. Firmware, BIOS, Bootloader, Kernel. Wenn jemand was manipuliert stimmen die Hashes nicht mehr. Das kann für Remote-Attestierung genutzt werden, ein externer Server prüft ob dein System sauber gebootet hat.
Aber auch das hat Grenzen. TPM prüft den Boot-Vorgang. Was nach dem Boot passiert sieht es nicht. Das ist das klassische TOCTOU Problem, Time of Check to Time of Use. Das TPM bestätigt dass alles sauber geladen wurde. Aber Millisekunden später könnte ein DMA-Angriff den Kernel im Speicher manipulieren und das TPM würde es nie erfahren.
Für Runtime-Überwachung gibt es Linux IMA, die Integrity Measurement Architecture. Die misst zur Laufzeit was geladen und ausgeführt wird und speichert die Hashes im TPM. Aber auch das kann von einem SMM-Rootkit umgangen werden weil SMM privilegierter ist als alles andere auf dem System.
Meine brutale ehrliche Meinung dazu: SMM-Rootkits sind staatliche Kapazität. Wenn du gegen einen Akteur kämpfst der SMM kompromittieren kann dann hast du grössere Probleme als dein Linux-Desktop. Du bist dann Ziel einer gezielten Operation mit Ressourcen die normale Kriminelle nicht haben. Für 99.9 Prozent der realistischen Bedrohungen reichen die Software-basierten Methoden plus gelegentliche DMA-Dumps völlig aus.
---
Die Sache mit der Baseline
Eine Frage die mich lange beschäftigt hat ist wie man überhaupt eine vertrauenswürdige Baseline erstellt. Wenn dein System schon kompromittiert ist bevor du anfängst zu messen, dann lernst du das Verhalten des Rootkits als normal. Das ist ein fundamentales Problem.
Die beste Lösung die ich in der Recherche gefunden habe ist externe Referenzen zu nutzen. Du erstellst die Baseline nicht auf dem verdächtigen System sondern auf einem identischen aber garantiert sauberen System. Eine frische VM im Labor zum Beispiel. Da führst du Testprogramme aus und sammelst Referenzwerte für Ausführungszeiten und Hardware Performance Counter.
Diese Referenzwerte überträgst du dann auf das Produktionssystem. Du führst dieselben Testprogramme aus und vergleichst. Wenn die Werte um mehr als einen Schwellenwert abweichen, sagen wir 5 Prozent, dann stimmt was nicht. Das Schöne daran ist dass du keine Baseline des gesamten Systems brauchst. Du brauchst nur die Baseline eines kontrollierten Testprogramms das du selbst geschrieben hast.
NumChecker, ein Forschungsprototyp, macht genau das. Es nutzt eine Offline-Phase wo das System garantiert sauber ist um Referenzwerte zu sammeln. Im Online-Modus vergleicht es dann kontinuierlich. Das läuft sogar auf Hypervisor-Ebene, also ausserhalb des Gast-Betriebssystems wo das Rootkit es nicht manipulieren kann.
Für Timing-Analyse mit eBPF geht es auch anders. Das Framework Trace of the Times nutzt ein Sliding Window. Es lernt kontinuierlich aus den jüngsten Daten und erkennt plötzliche Sprünge. Wenn ein Rootkit aktiviert wird entsteht ein Bruch in der Verteilung der Ausführungszeiten. Das System erkennt den Shift als Anomalie.
Das Problem dabei ist natürlich wenn das Rootkit schon vor Beginn der Überwachung aktiv und stabil war. Dann lernt das System das bösartige Verhalten als normal. Aber hey, perfekte Sicherheit gibt es nicht. Es geht darum die Hürden so hoch wie möglich zu legen.
---
Was du konkret tun kannst
Genug Theorie. Was kannst du als Desktop-User tatsächlich umsetzen?
Das Minimum ist rkhunter. Der klassische Rootkit-Scanner der nach bekannten Signaturen sucht und kritische Systemdateien prüft. Installieren mit `sudo apt install rkhunter`, dann `sudo rkhunter --update` und `sudo rkhunter --propupd` um eine Baseline zu erstellen. Danach regelmässig `sudo rkhunter --check --skip-keypress` laufen lassen. Das findet Commodity-Rootkits zuverlässig. Gegen moderne zielgerichtete Angriffe ist es machtlos aber es kostet nichts und schadet nicht.
Dazu auditd für die Protokollierung kritischer Systemänderungen. In /etc/audit/rules.d/ legst du Regeln an die überwachen wenn jemand an sudoers rumfummelt oder Kernel-Module lädt. Das gibt dir zumindest einen Audit-Trail falls was passiert.
Der nächste Level ist eBPF-basierte Überwachung mit Tracee. Das ist ein Tool von Aqua Security das Syscalls in Echtzeit überwacht und sogar Syscall-Hooking erkennen kann. Es generiert sogenannte Derived Events, es erkennt zum Beispiel wenn ein Syscall-Handler auf Speicher ausserhalb des normalen Kernel-Text-Segments zeigt. Das ist ein starkes Signal für Hooking. Tracee läuft am einfachsten über Docker, dann musst du keine Abhängigkeiten installieren.
Mit bpftool kannst du eBPF-Programme auditieren. `sudo bpftool prog show` zeigt alle geladenen eBPF-Programme, `sudo bpftool map show` zeigt die eBPF-Maps. eBPF-Rootkits, ja die gibt es wirklich, laden keine Kernel-Module aber sie müssen sich als eBPF-Programme registrieren. Mit bpftool siehst du was da läuft.
Wenn du wirklich sicher gehen willst brauchst du Memory-Dumps und Offline-Analyse. LiME, der Linux Memory Extractor, erstellt einen Dump deines RAMs. Den analysierst du dann auf einem anderen System mit Volatility. Wichtig ist dass du die Analyse nicht auf dem potenziell kompromittierten System machst. Das wäre sinnlos weil ein Rootkit die Ergebnisse manipulieren könnte.
Für die ganz Paranoiden, und ich sage das mit Respekt weil ich selbst dazugehöre, gibt es die DMA-Forensik mit PCILeech. Ein FPGA-Board, Thunderbolt-Anschluss, und du kannst den RAM am Betriebssystem vorbei auslesen. Das ist für die meisten Overkill aber wenn du dem laufenden System null vertrauen kannst ist es die einzige Option.
---
Das Bedrohungsmodell und wo die Grenze liegt
Lass uns zum Schluss realistisch sein. Die Erkennungsmethoden die ich beschrieben habe haben unterschiedliche Anwendungsfälle.
Gegen Script-Kiddies und Commodity-Malware reichen rkhunter und auditd völlig. Diese Angreifer benutzen bekannte Tools, hinterlassen Spuren, machen Fehler. Die wollen schnelles Geld mit Krypto-Minern oder Botnetzen, nicht monatelang in deinem System rumschleichen.
Gegen gezielte Angriffe, sagen wir ein mittelgrosser APT, brauchst du Cross-View-Analyse und Timing-basierte Erkennung. Tracee, regelmässige Memory-Dumps, Volatility-Analyse mit ModXRef. Das sind Angreifer die sich Mühe geben unsichtbar zu bleiben aber nicht unbegrenzte Ressourcen haben.
Gegen staatliche Akteure mit unbegrenztem Budget und Zugang zu Zero-Days und Hardware-Implants? Ehrlich gesagt hast du wahrscheinlich verloren bevor du überhaupt angefangen hast. Diese Leute haben SMM-Rootkits, kompromittierte Firmware, Implants die in der Hardware sitzen. Die können Dinge die in keinem Paper stehen weil sie klassifiziert sind.
Die gute Nachricht ist dass du wahrscheinlich kein Ziel für staatliche Akteure bist. Und selbst wenn erhöht jede Verteidigungsschicht die Kosten für den Angreifer. Sicherheit ist kein binärer Zustand sondern ein Spektrum. Es geht darum den Aufwand so hoch zu treiben dass sich der Angriff nicht lohnt.
---
Was mich an diesem Thema fasziniert
Nach Wochen der Recherche bin ich zu ein paar Erkenntnissen gekommen die ich teilen will.
Der Kernel ist ein Vertrauensproblem. Wir bauen unser gesamtes Sicherheitsmodell auf der Annahme auf dass der Kernel vertrauenswürdig ist. Wenn diese Annahme fällt fällt alles. Das ist unbequem aber wichtig zu verstehen. Jedes Sicherheitstool das auf dem System läuft kann vom Kernel belogen werden. Die einzige Lösung ist von aussen zu schauen, per DMA oder per Hypervisor.
Die Erkennung ist ein Katz-und-Maus-Spiel aber die Katze hat strukturelle Vorteile. Das Vergesslichkeitsprinzip ist real. Der Kernel ist so komplex geworden dass es praktisch unmöglich ist sich aus allen Datenstrukturen zu löschen. Je mehr Cross-View-Vergleiche wir machen desto schwieriger wird es für Rootkits. Die Komplexität die uns Sicherheitsprobleme bringt hilft uns auch sie zu finden.
Timing ist Physik. Du kannst Code nicht ausführen ohne Zeit zu verbrauchen. Das ist unveränderlich. Selbst wenn ein Rootkit perfekt versteckt ist verrät es sich durch die zusätzliche Latenz. Das ist für mich das Eleganteste an der ganzen Sache. Es gibt keine Möglichkeit sich davor zu verstecken. Jeder Hook kostet Nanosekunden und Nanosekunden kann man messen.
Die Demokratisierung von Forensik-Tools ist real. Was vor zehn Jahren Spezialwissen für Incident-Response-Teams war ist heute mit Open-Source-Tools und günstiger Hardware für jeden umsetzbar. Volatility, LiME, PCILeech, Tracee, ModXRef, das sind alles Tools die du runterladen und benutzen kannst. Die Einstiegshürde ist niedriger als je zuvor.
Und zum Schluss, vielleicht am wichtigsten: Perfekte Sicherheit gibt es nicht. Es gibt nur Kosten-Nutzen-Rechnungen. Jede Schicht die du hinzufügst erhöht den Aufwand für den Angreifer. Irgendwann lohnt es sich nicht mehr. Das ist das Ziel. Nicht unknackbar sein, sondern teurer zu knacken als es wert ist.
In diesem Sinne, viel Spass beim Härten eurer Systeme. Und wenn ihr nachts nicht schlafen könnt weil ihr euch fragt was auf eurem Kernel läuft, dann wisst ihr jetzt zumindest wo ihr anfangen könnt zu suchen.
---
*Dieser Beitrag basiert auf akademischer Forschung, Open-Source-Tools und einer gehörigen Portion Paranoia. Alle erwähnten Tools sind frei verfügbar. Die Meinungen sind meine eigenen und keine Sicherheitsgarantie. Wenn ihr wirklich glaubt kompromittiert zu sein holt euch professionelle Hilfe.*
