#edr

Im vorigen Beitrag über Rootkits ging es um eine zentrale These: Das moderne Rootkit sieht aus wie legitime Admin-Infrastruktur. Es begegnet uns als signierter Treiber, eBPF-Programm oder Scheduled Task. Die alten Suchmuster greifen bei dieser Form der Tarnung nicht mehr. Dieser Beitrag betrachtet die andere Hälfte desselben Phänomens: die Persistenz. Die Frage, wie eine gut getarnte Reverse Shell beim Systemstart ausgeführt wird, führt den Gedanken eine Schicht höher in den Userspace. Dort hinterlässt sie Artefakte, die zum forensischen Alltag gehören.

Wie im vorigen Beitrag bleibt die Betrachtung konzeptionell, ohne Schrittfolgen oder Payloads. Für die forensische Arbeit muss man verstehen, wie solche Werkzeuge gedacht sind, ohne sie selbst gebaut zu haben.

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.