Sliver von BishopFox: Aufbau, C2-Wege und Einsatz im Lab
Gegner-Emulations-Framework. Die Implantate von Sliver unterstützen C2 über gegenseitiges TLS (mTLS), WireGuard, HTTP(S) und DNS und werden dynamisch mit pro-binären asymmetrischen Verschlüsselungsschlüsseln kompiliert.
Auf einen Blick
- Was ist das?
- Was das Adversary-Emulation-Framework Sliver bietet: Implants mit mTLS, WireGuard, HTTP(S) und DNS, dynamische Codegenerierung, Multiplayer-Betrieb und die Grenzen laut README, geprüft an Version 1.7.6.
- Für wen ist es gedacht?
- Sliver passt für Sicherheitsteams, die Adversary Emulation im Rahmen autorisierter Tests durchführen und eine plattformübergreifende C2-Infrastruktur mit dokumentierten Transporten brauchen. Es ist nicht für den Einsatz ohne schriftliche Genehmigung gedacht, das Framework ist als Werkzeug für legale Sicherheitstests positioniert.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Sliver als Adversary-Emulation-Framework für autorisierte Tests
Sliver beschreibt sich im README als Open-Source-Adversary-Emulation- und Red-Team-Framework, das Organisationen jeder Größe für Sicherheitstests nutzen können. Das Repository ist in Go geschrieben, steht unter GPL-3.0, zählt 11740 Sterne und 1576 Forks, der Standardbranch ist master. Die aktuelle Version v1.7.6 erschien am 28. August 2026, die Vorgänger v1.7.3 und v1.7.2 datieren auf Februar 2026, das Release-Tempo ist also ungleichmäßig.
Die Positionierung ist wichtig für die Einordnung: Das Framework adressiert legitime Sicherheitstests, etwa die Überprüfung eigener Netzwerke gegen reale Angriffsmuster. Server und Client laufen laut README auf MacOS, Windows und Linux, die gleichen Plattformen gelten für die Implants, ergänzt um den Vorbehalt, dass theoretisch jedes Golang-Compiler-Ziel in Frage kommt, aber nicht alle getestet wurden.
Vier C2-Wege in Sliver: mTLS, WireGuard, HTTP(S) und DNS
Die Implants von Sliver unterstützen laut README vier Transporte für die Kommando- und Kontrolleverbindung: Mutual TLS, WireGuard, HTTP(S) und DNS. Diese Auswahl entspricht den Kanälen, die in echten Netzwerken unterschiedlich gut sichtbar sind, und erlaubt es Testteams, ihre Verteidigung gegen mehrere Szenarien zu prüfen.
Zusätzlich nennt das README eine prozedural generierte C2-Kommunikation über HTTP(S) und eine DNS-Canary-Funktion, die ausdrücklich als Erkennungshilfe für blaue Teams dokumentiert ist. Das ist der defensive Kern des Projekts: Nicht nur Angreiferseiten werden simuliert, sondern Detektionswege werden mitgeliefert. Ein Testteam kann damit prüfen, ob der eigene DNS-Monitoring-Ansatz Canary-Signale überhaupt erfasst, ohne eigene Detektionsmechaniken bauen zu müssen.
Dynamische Codegenerierung und per-binary Schlüssel in Sliver
Zwei Mechanismen aus der Feature-Liste bestimmen den Betrieb: dynamische Codegenerierung und Kompilierung zur Laufzeit mit Obfuscation. Jeder Implant wird laut README dynamisch kompiliert und trägt eigene asymmetrische Schlüssel pro Binary, es gibt also keinen gemeinsamen statischen Schlüssel über alle erzeugten Dateien.
Dazu kommen Staged- und Stageless-Payloads, ein Multiplayer-Modus für mehrere gleichzeitige Operatoren, Let's-Encrypt-Integration für TLS-Endpunkte, In-memory-Ausführung von .NET-Assemblies, ein COFF- und BOF-Loader im Speicher sowie TCP- und Named-Pipe-Pivots. Für Windows nennt das README Prozessmigration, Prozessinjektion und Token-Manipulation. Das gesamte Framework ist über Python mit dem separaten Projekt sliver-py scriptbar, was Automatisierung in größeren Testumgebungen erlaubt, etwa wenn Implant-Erzeugung und Ergebnisauswertung in eigene Workflows eingebunden werden sollen.
Sliver installieren: One-Liner, GitHub-Releases und Quellbau
Das README nennt für Linux einen Einzeiler: curl https://sliver.sh/install | sudo bash, danach startet der Befehl sliver die Konsole. Wer pipelineskriptet, sollte sich bewusst machen, dass dieser Weg ein Skript von einer fremden Domain mit Root-Rechten ausführt; der sauberere Weg für kontrollierte Umgebungen sind die fertigen Downloads unter github.com/BishopFox/sliver/releases.
Ein dritter Weg ist der Bau aus dem Quellcode, dessen Anleitung im Wiki unter sliver.sh/docs?name=Compile+from+Source liegt, für den neuesten Stand empfiehlt das README diesen Weg ausdrücklich. Nach der Installation führt das Wiki unter sliver.sh/docs?name=Getting+Started durch die Grundeinrichtung, für Hilfe verweist das Projekt auf das Wiki und auf GitHub Discussions. Die Dokumentation verteilt sich damit auf zwei Orte, README und Wiki, was den Einstieg etwas mühsamer macht als bei Projekten mit nur einer Doku-Quelle.
Erkennungsseite testen: DNS canary und Monitoring gegen Sliver-Implants
Für Verteidigungsteams ist der spannendste Teil der Feature-Liste der Abschnitt, der Detektion direkt adressiert: Die DNS-Canary-Funktion ist als blaue-Team-Erkennung dokumentiert, die Dokumentation dazu liegt unter sliver.sh/docs?name=DNS+C2. Ein Testaufbau sieht pragmatisch so aus, dass ein Implant mit DNS-Transport in einer kontrollierten Testumgebung läuft und das eigene Monitoring beobachtet wird, ob die Canary-Signale ankommen.
Ebenso prüfbar sind die übrigen Transporte: Ein Implant über mTLS und einer über HTTPS erzeugen unterschiedlich sichtbaren Netzwerkverkehr, und die prozedural generierte HTTP(S)-Kommunikation stellt andere Anforderungen an Pattern-Matching als ein konstanter Endpunkt. Wer den eigenen Schutz bewerten will, sollte die vier Transporte einzeln durchspielen statt einen einzigen zu testen, denn die README-Positionierung als Werkzeug für Organisationen zielt genau auf diese Breite.
Grenzen von Sliver: ungeprüfte Golang-Ziele, Lizenz und Support
Das README hält zwei Einschränkungen offen. Erstens sind Implants laut Text auf MacOS, Windows und Linux unterstützt und möglicherweise auf jedem Golang-Compiler-Ziel, aber es wurde nicht alles getestet, für exotische Plattformen gibt es also keine Zusage. Zweitens weist die Lizenz GPL-3.0 aus, wobei einzelne Sub-Komponenten eigene Lizenzen haben können, das README verweist dazu auf die jeweiligen Unterverzeichnisse.
Die Release-Historie zeigt zudem, dass zwischen v1.7.3 im Februar und v1.7.6 im August 2026 vier Monate lagen, Major-Versionen erscheinen also nicht im Wochenrhythmus. Ein formaler Supportvertrag existiert nicht, das Projekt lebt von der Community über Discussions. Für den legalen Rahmen gilt: Das Framework ist ein Testwerkzeug, sein Einsatz setzt eine autorisierte Zielumgebung voraus, das README selbst verweist für Fragen auf Wiki und Discussions, nicht auf einen Enterprise-Support.
Redaktionelles Fazit
Sliver passt für Sicherheitsteams, die Adversary Emulation im Rahmen autorisierter Tests durchführen und eine plattformübergreifende C2-Infrastruktur mit dokumentierten Transporten brauchen. Es ist nicht für den Einsatz ohne schriftliche Genehmigung gedacht, das Framework ist als Werkzeug für legale Sicherheitstests positioniert. Vor dem produktiven Einsatz lohnt ein Aufbau im isolierten Lab: Sliver über die Releases installieren, einen Implant gegen eine eigene VM erzeugen und die C2-Transporte einzeln gegen den eigenen Netzwerkschutz prüfen.
Community-Notizen