fabric: Eine Machbarkeitsstudie für ein selbstheilendes P2P-Mesh

Wie finden sich Knoten, wenn Adressen wechseln, Verbindungen abbrechen und kein zentraler Dienst die Topologie kennt? fabric ist meine Forschungsplattform für Peer-Discovery, Route-Healing, mehrstufige Transportwege und klar begrenztes Vertrauen. Dieser Beitrag beschreibt, was bereits funktioniert, wo die Selbstheilung heute endet und warum gerade diese Grenze interessant ist.

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 erst, wenn man eine Linie wegradiert. Oder drei. Wenn ein Knoten umzieht, eine Adresse nur aus einem privaten Netz erreichbar ist, UDP plötzlich verschwindet und niemand mehr zuverlässig sagen kann, welcher Weg zum Ziel noch existiert.

Genau dort beginnt fabric. Das Projekt untersucht, ob sich aus wenigen, bewusst begrenzten Bausteinen ein Peer-to-Peer-Netz zusammensetzen lässt, das neue Teilnehmer sicher aufnimmt, seine Nachbarn selbst entdeckt, indirekte Wege lernt und veraltete Routen wieder überprüft. Nicht als fertiges Produkt und nicht als Versprechen, jedes kaputte Netz magisch zu reparieren, sondern als Machbarkeitsstudie für Discovery und Auto-Healing: ausführbar, testbar und offen genug, dass auch die Lücken sichtbar bleiben.

Musik im Terminal: cava, roon-tui und ncmpcpp — deklarativ, monochrom, vim-navigiert

Drei Musik-Tools, ein Flake: cava visualisiert den Sound in einem 8-stufigen Orange-Gradienten mit gepatchten ▄-Blöcken, roon-tui steuert den Roon Core mit vim-Keybindings und einem monochromen Theme, und ncmpcpp ist der MPD-Fallback mit derselben Navigation. Dazu ein Overlay, das roon-tuis hartkodierte Farben und Keybindings per sed/substituteInPlace umschreibt, ein RoonBridge- und squeezelite-Setup, das sowohl bit-perfektes ALSA als auch PipeWire für cava bedient, und ein Musik-Profil, das zur Build-Zeit zwischen Roon und MPD wählt. Alles in einer tmux-Session, die cava im oberen Split und den Player darunter startet.

Musik auf der Workstation ist für mich kein Nebenbei — sie läuft den ganzen Tag, und das Setup soll sich so anfühlen wie der Rest des Desktops: deklarativ, monochrom mit orangen Akzenten, vim-navigiert. Drei Tools teilen sich die Bühne: cava visualisiert den Sound, roon-tui steuert den Roon Core, und ncmpcpp ist der MPD-Fallback, wenn Roon nicht läuft. Alle drei leben in fr0st , alle drei sind per Overlay auf dasselbe Theme und dieselben Keybindings gepatcht, und alle drei starten in einer tmux-Session , die cava im oberen Split und den Player darunter aufbaut.

cava (oben, ▄-Blöcke im Orange-Gradient) und roon-tui (unten, monochrom mit orangen Akzenten und ▮-Progressbar) in einer tmux-Session auf Workspace 9.

Gut getarnte Autostart-Methoden — warum moderne Persistenz aussieht wie ein Admin, der zur Arbeit kommt

Autostart-Mechanismen auf Windows und Linux im forensischen Blick, und was gut getarnte Persistenz konzeptionell von der naiven Run-Key-Reverse-Shell unterscheidet

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.

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

Wie aufwändig sind moderne Rootkits wirklich — und warum kommen sie in der Forensik heute kaum noch vor?

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.

wisp: eine Reverse-Shell über DNS — und warum das Protokoll immer noch ein Sicherheitsproblem ist

DNS als C2-Kanal ist kein Relikt: dnscat2 stammt aus den 2010ern, aber das Grundproblem — fast jedes Netz lässt DNS raus — ist ungelöst. wisp ist eine Machbarkeitsstudie in Rust, die das Konzept auf modernen Stand bringt: E2E-verschlüsselte Reverse-Shell über DNS, X25519/Ed25519/ChaCha20-Poly1305, Forward Secrecy, Wordlist-Encoding statt Base32, DoH-CDN-Egress — und ein Bootstrap-Modell ohne jemals geliefertes PSK: jedes gestempelte Binary trägt sein eigenes Token, das beim ersten Frame verbraucht wird. Dazu `!get`-Exfiltration über denselben Tunnel, ein IRC-Betreiberkanal über Tor, daemonisierte Linux-Clients (fork+setsid, Self-Delete), Dead-Drop-Schlafmodus mit `!sleep`/`!wake`, A-Record-Transport zur S3-Mimikry, System-Introspektion (!top, !ps, !netstat) und Session-Management mit !alias, !note, !attach und !wipe. Ein Vergleich mit dnscat2 — und konkrete SNORT-Regeln, mit denen ein SOC genau solche Tunnel aufspürt.

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.

POC — nur für autorisierte Systeme. wisp ist eine Machbarkeitsstudie für Security-Research und autorisierte Red-Team-Demonstrationen. Es darf ausschließlich in Netzen und an Systemen betrieben werden, die man selbst besitzt oder für die man ausdrücklich autorisiert ist. Unerlaubter Einsatz ist illegal. E2E verschlüsselt den Inhalt des Tunnels, nicht seine Existenz — wer einen solchen Kanal aufbaut, erzeugt messbaren DNS-Verkehr, und genau dieser Verkehr ist, wie der zweite Teil des Beitrags zeigt, erkennbar.