Im vorigen Beitrag über Rootkits lief alles auf eine These hinaus: das moderne Rootkit sieht nicht mehr wie ein Rootkit aus, sondern wie legitime Admin-Infrastruktur — ein signierter Treiber, ein eBPF-Programm, ein Scheduled Task. Wer in der Forensik nach den alten Mustern sucht, findet nichts. Dieser Beitrag nimmt die andere Hälfte desselben Phänomens in den Blick: die Persistenz. Denn die Frage „wie bringt man eine Reverse Shell gut getarnt beim Systemstart zum Laufen?" ist im Grunde die Fortsetzung desselben Gedankens — nur eine Schicht weiter oben, im Userspace, und mit einem Artefakt-Set, das man in der Forensik wirklich täglich findet.

Wieder die gleiche Regel wie vorher: Das hier ist konzeptionell, nicht operational. Keine Schrittfolgen, keine Payloads. Wer forensisch arbeitet, muss ahnen, wie die Werkzeuge gedacht sind, ohne sie 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.

DNS ist das Protokoll, das jeder Firewall durchlässt. Nicht aus Konfigurationsfehler, sondern aus Notwendigkeit: Ohne Namensauflösung funktioniert in einem modernen Netz schlicht nichts — also bleibt Port 53/udp offen, fast immer sowohl Richtung des rekursiven Resolvers des Hauses als auch, häufig genug, Richtung beliebiger öffentlicher Resolver im Internet. Genau das ist der Spalt, durch den sich Exfiltration und Command-and-Control seit drei Jahrzehnten quetschen. dnscat2 hat das 2014 vorgemacht; das Tool ist in die Jahre gekommen, das Prinzip nicht.

Dieser Beitrag stellt wisp (ursprünglich dc - für dnscat) vor — ein Projekt, das ich als Machbarkeitsstudie gebaut habe, um zwei Dinge zu zeigen: erstens, dass ein modernes, kryptografisch hartes DNS-Tunnel-Tool heute ohne viel Aufwand möglich ist, und zweitens — und das ist mir mindestens genauso wichtig —, dass die Verteidigungsseite das nur erkennt, wenn sie es aktiv sucht. wisp ist zugleich Angriffs-POC und Argument für DNS-Firewalling, Response-Rate-Limiting, Egress-Filtering freier Resolver und DoH-Blocking. Wer nur eines davon macht, verliert schon. Zur Reverse-Shell kommt eine !get-Exfiltration über denselben E2E-Kanal — und ein Bootstrap-Modell, das kein PSK jemals ausliefert: jedes gestempelte Binary trägt sein eigenes Token, das beim ersten Frame verbraucht wird.

Lange hat Vault in meinem Lab die internen Zertifikate ausgestellt — eine PKI-Engine, ein cert-manager-ClusterIssuer namens vault, fertig. Bequem. Und ein Single Point of Failure mit Ansage: Ist Vault sealed, abgelaufen oder beim Bootstrap, stellt niemand mehr ein Cert aus. Genau dieses Henne-Ei hat mich schon einmal in eine Break-Glass-Recovery gezwungen. Also habe ich die PKI von Vault gelöst und auf das gestellt, wofür X.509 eigentlich gedacht ist: eine Offline-Hierarchie, deren teuerste Schlüssel nie online sind.

Mein Lab ist ein öffentliches GitOps-Repo — über meinen Radicle -Seed-Node seed.this-is-fine.io kann es jeder klonen. Daraus folgt eine harte Regel: kein Klartext-Secret, niemals, nirgends in Git. Und trotzdem braucht jeder Workload im Cluster seine Passwörter, API-Tokens und Signing-Keys. Diesen Widerspruch löse ich in drei Schichten, von denen jede genau eine Aufgabe hat.

Im Beitrag über die pre-commit-Hooks ging es darum, wie ich verhindere, dass ein Secret versehentlich in Git landet. Hier geht es um den geplanten Weg: wie ein Secret absichtlich von meiner Maschine bis in einen Pod fließt, ohne je unverschlüsselt das Repo zu berühren.