Seit dem letzten größeren Lab-Rückblick hat sich vor allem der Betrieb weiterentwickelt. Damals waren bessere Beobachtbarkeit, mehrschichtige Backups und weniger Handarbeit an den Übergängen zwischen Systemen noch offene Aufgaben. Inzwischen erfasst die Logsammlung auch die Control Plane, Backups verlassen die Ausfalldomäne des Clusters, und externe Checks überwachen das Monitoring selbst.

Daneben kamen neue Dienste hinzu. In diesem Rückblick geht es aber vor allem um die Änderungen, die das Lab im Alltag belastbarer machen. Grundlage ist die öffentliche Lab-Konfiguration Anfang Oktober 2026.

Ein Mesh ist auf dem Whiteboard immer gesund. Ein paar Kreise, einige Linien dazwischen, vielleicht noch eine Wolke für „das Internet“ — fertig ist das dezentrale Netz. Interessant wird es, wenn die ersten Linien verschwinden: Ein Knoten zieht um, eine Adresse ist nur aus einem privaten Netz erreichbar oder UDP fällt plötzlich aus. Dann muss sich zeigen, ob die Teilnehmer noch einen Weg zum Ziel finden.

Genau dort beginnt fabric. Das Projekt untersucht, ob wenige, bewusst begrenzte Bausteine für ein Peer-to-Peer-Netz genügen, das neue Teilnehmer sicher aufnimmt und seine Nachbarn selbst entdeckt. Es soll indirekte Wege lernen und veraltete Routen wieder überprüfen. Dabei geht es nicht um ein fertiges Produkt, das jedes kaputte Netz repariert, sondern um eine Machbarkeitsstudie für Discovery und Auto-Healing. Sie ist ausführbar und testbar und gibt auch dort Einblick, wo die Mechanismen noch nicht ausreichen.

Auf meiner Workstation läuft den ganzen Tag Musik. Deshalb soll sich auch das Musik-Setup wie der Rest des Desktops anfühlen: deklarativ konfiguriert, monochrom mit orangen Akzenten und per vim-Tasten bedienbar. cava visualisiert den Sound, roon-tui steuert den Roon Core, und ncmpcpp dient als MPD-Fallback, wenn Roon nicht läuft. Die drei Tools sind in fr0st eingebunden und per Overlay auf ein gemeinsames Theme und dieselben Keybindings angepasst. Eine tmux-Session startet cava im oberen Split und den jeweiligen Player darunter.

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.