Rootkits sind nicht verschwunden — sie sehen nur nicht mehr so aus

Ich beschäftige mich viel mit IT-Forensik, und mir ist in den letzten Jahren etwas aufgefallen: Rootkits kommen mir zur Analyse kaum noch unter. Früher war das ein fester Bestandteil des Bedrohungsbilds — ein versteckter Prozess hier, ein gepatchter System Call dort, ein Treiber, der sich aus der Modulliste verabschiedet hat. Heute? Fast nichts mehr. Das hat mich neulich zu einem reinen Gedankenspiel angeregt: Wie aufwändig wäre so etwas mit modernen Mitteln eigentlich noch, speziell in Rust ? Und ist das heutzutage überhaupt noch sinnvoll möglich?

Wichtig vorab: Das hier ist keine Bauanleitung, keine Umsetzung, nichts Operationalisierbares. Es ist ein Gedankenspiel aus der Perspektive jemandes, der Verteidiger-Werkzeuge verstehen will, indem er sich überlegt, wie die andere Seite denkt. Genau das macht Forensik übrigens aus — man muss die Werkzeuge nicht gebaut haben, aber man sollte ahnen, wie sie gedacht sind, um ihre Spuren zu lesen.

Die kurze Antwort vorweg

Ein Rootkit in Rust zu schreiben ist kein Sprachproblem mehr, sondern eines der Umgebung. Der eigentliche Code, der das Verstecken bewirkt, ist fast das kleinste Stück des Ganzen. Was ein modernes Vorhaben teuer macht, ist alles drumherum: Signing, Persistenz, Versionsstabilität über Kernel-Updates hinweg und das Ausbleiben vor EDR-Sensoren. Und die Erklärung, warum man die Dinger in der Forensik nicht mehr so häufig auffindet, hängen eng damit zusammen: Die Angreifer sind zu demselben Schluss gekommen und investieren ihr Budget woanders.

Gehen wir das mal schichtweise durch.

Schicht 1: Wo lebe ich?

Konzeptionell zerfällt ein Rootkit-Vorhaben zuerst in die Frage nach der Schicht, in der es residieren soll — und das ist gleichzeitig die forensische Taxonomie, nach der man später sucht:

• Userland: Ein eigener Prozess, der die Systembibliotheken anderer Prozesse modifiziert — Hooking von ntdll.dll auf Windows bzw. libc.so auf Linux. Einfach zu bauen, aber von jedem halbwegs ernsthaften Prozess-Introspection-Tool sichtbar.
• Kernel-Mode: Ein WDM/WDF-Treiber auf Windows oder ein Loadable Kernel Module auf Linux. Tiefere Sichtbarkeit, größere Macht — aber Signing-Zwang, und jeder Absturz ist ein Bluescreen bzw. Kernel-Panic.
• Unterhalb des OS: Hypervisor-, UEFI- und Bootkits. Höchste Persistenz, weil sie vor dem Betriebssystem liegen, aber auch der höchste Aufwand — und paradoxerweise genau da, wo moderne Forensik am ehesten noch Spuren findet: in UEFI-Variablen, Option ROMs, Boot-Logs.

Rust ändert an dieser Entscheidung nichts, aber es macht die Userland-Variante erstaunlich ergonomisch. Mit windows-rs hat man direkten Zugang zur NT-API samt der undokumentierten Strukturen rund um PEB/TEB/EPROCESS, und man bekommt Memory-Safety gratis — was bei der Pointer-Arithmetik, die in C-Kernel-Code traditionell für Abstürze sorgt, ein echter Gewinn ist. Für den Kernel-Modus wird es hingegen dünn: Kernel-Rust existiert (#![no_std], eigener Panic-Handler, ein Panic bedeutet Bugcheck), aber das Ökosystem ist klein und das Tooling auf beiden Plattformen hakelig. Auf Linux hilft immerhin, dass Rust im Kernel mittlerweile Mainline-Realität ist — man kann legitime Modul-Skelette als Ausgangspunkt nehmen, auch wenn die tiefen Hooks, die ein LKM-Rootkit bräuchte, davon nicht abgedeckt sind.

Schicht 2: Was verstecke ich?

Das ist der klassische Rootkit-Werkzeugkasten, konzeptionell festgehalten — nicht weil man es nachbauen sollte, sondern weil man danach suchen muss:

• Dateien und Verzeichnisse durch Hooking der Directory-Enumeration (NtQueryDirectoryFile / getdents / VFS-Operation-Table)
• Prozesse via DKOM — Direct Kernel Object Manipulation, also das Aushängen aus ActiveProcessLinks auf Windows bzw. der task_struct-Liste auf Linux. Der Prozess läuft weiter, taucht aber in keiner Auflistung mehr auf.
• Registry- und Config-Einträge, Netzwerkverbindungen (Hook der TCP-Query-IOCTLs bzw. tcp_seq_show) und das Modul selbst, das sich aus PsLoadedModuleList bzw. der /proc/modules-Liste austrägt.

DKOM ist dabei der konzeptionell eleganteste und zugleich fragilste Ansatz: Er patcht keine Bytes, sondern manipuliert direkt die Kernel-Datenstrukturen. Hook-Scanner sehen ihn schlecht, aber bei jedem Kernel-Update, das die Offsets dieser Strukturen verschiebt, stirbt er — oder schlimmer, er korruptiert Speicher und es gibt einen Bugcheck. Genau diese Versionsfragilität ist einer der Gründe, warum klassische Kernel-Rootkits betriebswirtschaftlich unattraktiv geworden sind.

Schicht 3: Wie hooke ich?

Hier lohnt sich ein Blick auf die historische Evolution, weil jede Hooking-Generation eine forensische Gegenmaßnahme geboren hat — und man als Forensiker genau diese Evolution im Kopf haben muss, um zu wissen, wo man in welchem Fall sucht:

• Inline-Hooking (Bytes in einer Funktion patchen) → erkennbar durch Memory-Integrity-Scans.
• SSDT- und IAT-Hooking → auf Windows seit PatchGuard (Kernel Patch Protection, ab Vista) praktisch tot; auf Linux via kprobes/ftrace-Ops noch in Grenzen möglich, aber stark observierbar.
• Object Callbacks (PsSetCreateProcessNotifyRoutine, CmRegisterCallback) — das ist der moderne Sweet Spot. Diese Mechanismen sind legitim und werden von EDRs selbst genutzt. Ein Rootkit, das hier mitmischt, sieht aus wie ein Verteidiger-Werkzeug.
• eBPF auf Linux — das ist die vielleicht spannendste Entwicklung der letzten Jahre. eBPF -Programme können nahezu beliebige Tracepoints, Kprobes und Uprobes hooken, laufen isoliert und werden von der Verifier-Schicht kontrolliert. Weil eBPF historisch als “gutartig” galt, haben forensische Scanner lange nicht danach gesucht. Konzeptionell ist das ein enorm attraktiver Vektor — das Werkzeug, das man zur Observanz nutzt, lässt sich auch zur Täuschung nutzen. Die Defense-Community hat das erkannt; Werkzeuge wie eBPF-basierte Detection und die Diskussion um eBPF als Angriffsfläche sind mittlerweile ein festes Thema.

Der konzeptionelle Clou, den man sich als Forensiker merken sollte: Das beste moderne Rootkit sieht nicht wie ein Rootkit aus, sondern wie legitime Admin-Infrastruktur. Ein signierter Treiber, ein eBPF-Programm, ein WMI-Permanent-Subscriber, ein Scheduled Task mit SYSTEM-Rechten. Der Angreifer nutzt das gleiche Toolkit wie der Verteidiger — und genau deshalb ist es so schwer zu erkennen.

Schicht 4: Persistenz und Evasion

Das ist heute, ganz bewusst überschlagen, 60–80 % des Aufwands. Driver Signature Enforcement auf Windows, CONFIG_MODULE_SIG_FORCE und Kernel Lockdown auf Linux, Secure Boot auf beiden Plattformen — all das zwingt dazu, sich legitim auszuweisen, oder aber eine Schicht tiefer anzusetzen (Bootkit). Und dann das Ausbleiben vor Sensoren: ETW Threat Intelligence Provider, Kernel-Callbacks, Memory Scanning und vor allem behavioral Detection machen klassisches Hooking laut. Das investment verschiebt sich vom “Ich verstecke mich” zum “Ich sehe aus, als gehörte ich dazu, und ich blinde die Telemetrie, ohne den Sensor selbst zu patchen” — denn ein gepatchter EDR-Sensor fällt sofort auf.

Wie viel Aufwand ist das nun wirklich?

Reines Gedankenspiel, ohne jede Operationalisierung: Ein Userland-Rootkit in Rust für eine einzelne, wohldefinierte Zielplattform ist für jemanden, der die NT-/libc-Internals kennt, ein Projekt in der Größenordnung von Wochen — nicht Tagen, aber auch nicht Jahren. Ein Kernel-Rootkit, das über mehrere Kernel-Versionen hinweg stabil läuft und nicht sofort von gängigen EDRs geblitzt wird, ist hingegen ein Team-Monats- bis -Jahresprojekt. Und der größte Teil davon ist nicht Hooking-Code, sondern das, was ich oben unter Persistenz und Evasion zusammengefasst habe: so tun, als gehörten wir dazu.

Rust verschiebt die Kostenkurve ein Stück — Memory-Safety im Userland, ein brauchbares no_std-Skelett im Kernel —, aber es ändert nichts am grundlegenden Befund, dass der Code nicht der Flaschenhals ist.

Und warum sehe ich die in der Forensik kaum noch?

Das ist die eigentlich interessante Frage, und die Antwort hat mehrere, konvergierende Gründe, die sich alle in einem Satz zusammenfassen lassen: Rootkits sind nicht verschwunden, sie sind woanders hingezogen.

Erstens: EDR hat den Boden dünn gemacht. Kernel-Callback-Sensoren, ETW-TI , Memory Scanning und behavioral Detection machen klassische Hooking-Rootkits laut. Der Return on Investment für einen Angreifer ist gefallen — das gleiche Geld bringt woanders mehr.

Zweitens: Das Problem hat sich nach oben verlagert. Warum sich die Mühe machen, NtQueryDirectoryFile zu hooken, wenn das gleiche Ziel — Persistenz und C2 — mit einem Scheduled Task, dem Missbrauch eines legitimen Remote-Management-Tools (Atera, ConnectWise, AnyDesk), einem Dienst mit SYSTEM-Rechten oder Living-off-the-Land-Binaries erreichbar ist? Die Rootkit-Funktionalität wird ersetzt durch LOTL plus signierte Binaries plus Remote-Admin-Abuse. Das sieht auf den ersten Blick legitim aus, hinterlässt aber mehr Forensik-Spuren — Event Logs, Scheduled-Task-History, Login-Events —, nur eben unauffällige. Als Forensiker sucht man heute nicht mehr nach versteckten Prozessen via DKOM-Detektion, sondern nach Legitimacy Abuse: anomalen WMI-Subscribern, verdächtigen Scheduled Tasks, ungewöhnlichen Remote-Management-Logins, OAuth-Token-Abuse, Identity-Anomalien. Das ist nicht weniger forensisch, es ist nur ein anderes Artefakt-Set.

Drittens: Die Bedrohungslandschaft hat sich differenziert. Massen-Malware nutzt fast keine Kernel-Rootkits mehr — zu teuer, zu versionsfragil, zu laut. Wo man Kernel- und Bootkits heute noch findet, ist fast ausschließlich bei staatlichen Akteuren und gezielter Espionage, etwa in Form von UEFI-Bootkits , oder — und das ist de facto das aktivste „Rootkit gegen Rootkit"-Feld — im Bereich Anti-Cheat versus Cheat. Kernel-Anti-Cheat-Treiber und DMA- bzw. Hypervisor-basierte Cheats liefern sich dort einen permanenten Katz-und-Maus-Krieg auf Höhe, die im normalen Unternehmens-Alltag gar nicht auftaucht. Wer in Standard-Unternehmensforensik unterwegs ist, sieht diese Fälle schlicht nicht, weil die Zielgruppe eine andere ist.

Viertens: Persistenz ist nicht mehr das primäre Ziel. Viele moderne Vorfälle sind ransomware- oder datenexfiltrationsgetrieben mit kurzer Dwell-Time. Da wird gar nicht mehr im klassischen Sinne persistiert — ein Rootkit wäre kontraproduktiv, weil es die Angriffsfläche für Entdeckung vergrößert, ohne den Mission-Outcome zu verbessern. Wer eine Organisation in 48 Stunden ausraubt und dann verschwindet, braucht keine dauerhafte Tarnung.

Fünftens: Der Cloud-Shift. Wo der Endpoint nur noch ein Entra-ID-joined Client ist und die Workloads in Azure oder AWS laufen, gibt es keinen lokalen Kernel mehr zum Hooken. Die Angriffsebene ist Identity und Control Plane, nicht EPROCESS. Entsprechend verschiebt sich auch die Forensik — hin zu Cloud-Audit-Logs, Identity-Anomalien, Token-Lifetime-Analyse.

Was man sich für die Praxis merken sollte

Wenn man rootkit-technisch für die Forensik wieder up-to-date sein will, sind drei Konzepte es wert, sich vertieft anzueignen:

1. eBPF als Doppelrolle — Defense-Werkzeug und zugleich Angriffsvektor. Wer eBPF nur als „gutartige Observanz-Plattform" begreift, hat einen blinden Fleck.
2. DMA- und Hypervisor-Angriffe unterhalb des OS — dahin hat sich der Katz-und-Maus-Krieg bewegt, weil dort die Kernel-Hardening der OS-Hersteller nicht greift.
3. Legitimacy Abuse als de-facto-Rootkit — das ist, was man heute in Fällen eigentlich findet, auch wenn es niemand mehr so nennt. Ein signierter Treiber, der genau das tut, was ein Rootkit früher tat, nur mit gültigem Zertifikat und plausibler Persistenz, ist das moderne Äquivalent.

Fazit

Rootkits sind nicht tot, sie sind nur unpopulär geworden — für die breite Masse der Angreifer, weil der ROI gefallen ist, und für den Verteidiger, weil sich das Artefakt-Set gewandelt hat. Die Technik existiert weiter, sie ist nur in Nischen abgewandert: in APT-Espionage, in die Anti-Cheat-Wars, unterhalb des Betriebssystems. Wer in der Forensik nach den alten Mustern sucht, findet nichts — nicht weil nichts da wäre, sondern weil man an der falschen Stelle schaut. Das moderne Rootkit sieht aus wie ein EDR, wie ein Remote-Admin-Tool, wie ein Scheduled Task. Und genau das macht die Forensik heute schwerer als früher: Man sucht nicht mehr nach dem Verborgenen, sondern nach dem Legitimen, das es nicht sein sollte.

Ein schönes Gedankenspiel — und, finde ich, eine nützliche Denkübung für jeden, der forensisch arbeitet. Man muss die Werkzeuge nicht bauen. Aber ahnen, wie sie gedacht sind, gehört zum Handwerk.