#rust

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.

Tor-Konnektivität im Cluster hatte ich bisher zusammengesteckt: pro Pod ein client-only tor plus ein oder zwei socat-Sidecars, die lokale TCP-Ports in Onion-Services übersetzten — genau das Setup, das ich im IRC-Bouncer-Beitrag beschrieben habe. Das funktioniert, skaliert aber nicht als Muster: Jeder Workload, der eine .onion erreichen oder selbst eine anbieten wollte, brachte seinen eigenen Tor-Prozess und seine eigene Klebeschicht mit. Also habe ich das Ganze zu dem gemacht, was es im Lab sein sollte: einer Custom Resource. tor-operator ist ein eigener, in Rust geschriebener Kubernetes-Operator, der Tor-Konnektivität in beide Richtungen als CRD anbietet.

Es gibt diesen einen Moment beim Remote-Support, den jeder kennt: Jemand sitzt vor einem kaputten Terminal, beschreibt am Telefon umständlich, was auf dem Schirm steht, und tippt dann doch wieder das Falsche. Was ich in dem Moment will, ist keine 478-MB-Electron-Bildschirm-Sharing-Software — ich will sein Terminal sehen, am besten mitschreiben können, und zwar in dem Augenblick, in dem es brennt. Genau dafür gibt es tmate . tmate ist großartig. tmate ist aber auch ein Stück Software, dem ich nicht mehr blind vertrauen wollte. Dieser Beitrag erzählt, warum ich mir stattdessen mein eigenes Werkzeug gebaut habe — choom¹ —, was es kann, wie man es benutzt, und wo die Grenze liegt.