C2-Infra mit Sliver im Isolierten Lab fur Defensive Forschung Aufbauen

Jedes Mal, wenn ein SOC-Analyst ein Ticket fur einen verdachtigen Beacon offnet, besteht die reale Chance, dass niemand im Team je einen Command-and-Control-Kanal mit eigenen Augen in Aktion gesehen hat. Red-Team-Operatoren nutzen Sliver, Mythic und Havoc taglich, doch die meisten Verteidiger kennen diese Frameworks nur aus Mandiant-Report-Screenshots. Diese Lucke ist gefahrlich: Man erkennt zuverlassig nur Verhalten, das man beobachtet hat. Dieser Leitfaden baut ein isoliertes, internetloses Sliver-Lab, dessen einziger Zweck es ist, realistische, kontrollierte und dokumentierte Telemetrie zu erzeugen, damit ein Blue Team Detection-Regeln gegen selbst erzeugte Indikatoren schreibt und validiert. Alles unten passiert in einem air-gapped VLAN und tragt null rechtliches Risiko, weil das Lab mit niemandem ausserhalb von 10.50.0.0/16 spricht.

Was ein C2 ist und warum Sliver fur ein Defensiv-Lab

Ein Command-and-Control-Framework (C2) ist die Operator-Seite der Post-Exploitation: ein Server, der Check-ins von Implants (auch Beacons oder Agents) auf kompromittierten Hosts empfangt, plus ein Tasking-Kanal, der Befehle zuruckschiebt. Sliver, gepflegt von BishopFox, ist in Go geschrieben und bringt plattformubergreifende Implants fur Windows, Linux und macOS uber mTLS, WireGuard, HTTP(S) und DNS mit. Fur ein Defensiv-Lab schlagt es die Alternativen auf drei Achsen: anders als Cobalt Strike ist es kostenlos und sein Quellcode auditierbar, sodass man genau lesen kann, was ein Implant tut; anders als Mythic braucht es deutlich weniger Infrastruktur. Diese Auditierbarkeit zahlt, weil man Verhalten auf Detektionen abbilden will, und eine Blackbox lehrt nichts Verallgemeinerbares.

Bedrohungsmodell: warum Verteidiger das Angreifer-Tooling fahren mussen

Detection Engineering scheitert, wenn es auf Theorie beruht. Hersteller veroffentlichen generische Regeln, Teams importieren sie, und der erste echte Vorfall zeigt, dass die Regel auf einem Feld ausloste, das der Operator nie beruhrt, oder das entscheidende verpasste. Das eigene Fahren des Offensiv-Toolings schliesst diese Schleife. Man lernt Slivers Default-Named-Pipes, seine Process-Injection-Muster, die genauen API-Calls hinter execute-assembly und die Netz-Kadenz eines mTLS-Beacons. Man lernt auch seine Evasion-Schalter, sodass man beim Ausfall einer Regel versteht, welchen Schalter der Gegner gedreht hat. Das Lab greift niemanden an; es ist eine Telemetrie-Fabrik, deren Output Sigma-Regeln, IOCs und Hunting-Hypothesen sind, denen man traut, weil man die Grundwahrheit selbst erzeugt hat.

Lab-Architektur: VLANs, pfSense und volle Egress-Isolation

Die Topologie ist bewusst einfach und streng segmentiert. Eine Debian-12-VM dient als Teamserver mit 4 vCPU und 8 GB RAM. Sie liegt im C2-VLAN 10.50.10.0/24. Die Ziele leben in einem separaten Opfer-VLAN 10.50.20.0/24. Dazwischen steht eine pfSense, deren Regelwerk nur Traffic zwischen diesen beiden Subnetzen erlaubt und null NAT nach draussen anwendet: das Lab hat per Design keine Route ins Internet. Das ist aus zwei Grunden wichtig. Erstens kann ein Implant, das keine echte Adresse erreicht, bei einem Fehler nicht an Dritte leaken. Zweitens zwingt es dazu, das Netz so zu modellieren, wie ein segmentiertes Unternehmen wirklich aussieht. Wer noch kein Basislab hat, findet in Web-Pentest von Null: Ein Sicheres Lab mit DVWA, Juice Shop und Burp Suite Bauen ein solides Fundament zum Wiederverwenden.

Teamserver installieren, Schritt fur Schritt

Der schnelle Weg ist curl https://sliver.sh/install | sudo bash, aber in einer isolierten Umgebung leitet man nie ein Remote-Skript nach root. Stattdessen ladt man das signierte Release-Binary auf einer verbundenen Maschine, verifiziert es mit cosign verify-blob gegen den veroffentlichten Key von BishopFox, berechnet den SHA-256 und tragt es uber einen dedizierten USB-Stick hinein. Auf der Debian-VM legt man das Binary nach /usr/local/bin/sliver-server, erstellt ein Non-root-Servicekonto sliver und fahrt den Server unter systemd mit einer gehartete Unit (NoNewPrivileges, ProtectSystem=strict, privates WorkingDirectory). Die Konsole startet man mit sliver-server und erzeugt eine Operator-Config mit new-operator --name analyst --lhost 10.50.10.5. Ein auf die C2-VLAN-Adresse begrenztes Operator-Profil verhindert, dass ein versehentliches Implant je ein Management-Interface erreicht.

Implants generieren und Profile abstimmen

Erstelle ein erstes Implant mit generate --mtls 10.50.10.5:8443 --os windows --arch amd64 --skip-symbols --save ./payloads. Das Flag --skip-symbols entfernt die Go-Symboltabellen, verkleinert das Binary um rund 40% und erschwert schnelles Reverse Engineering, lasst aber genug fur das Debugging des eigenen Labs. Legt man dieses unobfuskierte Implant auf eine Windows-11-21H2-VM mit aktivem Defender Real Time, stirbt es typisch in etwa 12 Sekunden. Das ist kein Fehlschlag, sondern eine Messung. Man hat jetzt ein sauberes Signal dafur, was Defender fangt, und eine Baseline zum Vergleich, wenn man gezielt Evasion hinzufugt. Um die Delivery-Kette vor dem Beacon zu studieren, kombiniere dies mit Initial Access Simuliert: Makros, LNK und ISO im Isolierten Windows-11-Lab.

Vom Beacon-Check-in zu Detection-Regeln

Der lehrreiche Teil beginnt in dem Moment, in dem der Beacon eincheckt. Jedes Operator-Kommando erzeugt eine eigene Spur: getsystem beruhrt Token-Duplizierung, execute-assembly spawnt einen Opferprozess und ladt die CLR, sideload mappt eine unbacked DLL. Instrumentiere die Opfer-Hosts mit Sysmon in der SwiftOnSecurity-Config, verschicke Events per Elastic Agent in einen lokalen Cluster und korreliere gegen Sigma-Regeln. Uber drei fokussierte Sprints kann ein kleines Team dutzende neue Detections kartieren, von Slivers Default-Named-Pipe-Namen bis zu rundll32-Spawns ohne Command Line. Die ganze Pipeline vom IOC zur wartbaren Regel ist in Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel dokumentiert und passt direkt zu den Events dieses Labs.

Lateral Movement in einem Mini-Active-Directory

Lateral Movement ist, wo sich das Lab rechnet. Ziehe ein Mini-AD mit zwei Domain Controllern, vier Workstations und einem File Server hoch, das die Topologie eines mittelgrossen Kunden spiegelt. Mit dem initialen Sliver-Implant auf einem Low-Privilege-Host nutzt du Rubeus fur Kerberoasting und pivotest dann uber einen WireGuard-Tunnel zum Domain Controller, ohne ihn je direkt vom Teamserver zu beruhren. Die Techniken in Active Directory Pentest: Kerberoasting Schritt fuer Schritt im GOAD Lab und Pivoting mit Chisel und Ligolo-ng: Segmentierte Netze im Pentest-Lab sind dieselbe Logik mit anderem Tooling. Jeder Hop hinterlasst Spuren: 4624 Type 3, 4769-Tickets mit schwachem RC4, ungewohnliche WMI-Verbindungen. Jede davon wird zu Hunting-Material mit einem Known-good- und einem Known-bad-Sample.

Detections harten und die Schleife schliessen

Ein Lab ohne Feedback-Schleife ist eine Demo. Behandle nach jedem Lauf jede geschriebene Detection als Hypothese und versuche, sie zu umgehen. Schalte Slivers Evasion-Features einzeln ein (Traffic-Reshaping, Jitter, alternative Transports) und beobachte, welche Regeln uberleben. Regeln, die nur einen Default-String matchen, sind brittle; Regeln, die auf Verhalten verankert sind (eine unbacked Speicherregion, die ausfuhrt, eine Parent-Child-Kette, die nie vorkommen darf), uberstehen das Tuning. Fuhre zusatzlich eine Metrik fur False Positives: eine Regel, die im normalen Lab-Betrieb standig grundlos feuert, ist in Produktion wertlos und erzeugt nur Alert-Mudigkeit. Versioniere deine Sigma-Regeln in git, tagge jede mit der ATT&CK-Technik, die sie abdeckt, und halte das genaue Implant-Profil fest, das die Quell-Events erzeugte, damit ein Kollege das Signal reproduzieren kann. Notiere zu jeder Regel auch die erwartete Datenquelle (Sysmon Event ID, Kanal) und die getestete Sliver-Version, denn Frameworks andern ihr Verhalten zwischen Releases und eine gestern valide Regel kann morgen still versagen. Diese Reproduzierbarkeit ist der Unterschied zwischen einer Regel, der man in Produktion traut, und einer, von der man hofft, dass sie greift.

Fallstricke und Lab-OPSEC

Lab-OPSEC zahlt mehr, als viele glauben. Selbst air-gapped sind VM-Snapshots mit aktiven Implants schon in offentliche Repos geleakt, weil jemand sie versehentlich hochgeladen hat. Die Regel ist einfach: Lab-VMs liegen auf einem LUKS-verschlusselten Datastore, Snapshots verlassen den Host nie, und jedes Artefakt, das raus muss (Sigma-Regel, IOC, Demo-Video), durchlauft zuerst manuelle Review. Das passt zur Disziplin aus OPSEC fuer Security-Researcher: Persoenliches Bedrohungsmodell und Metadaten-Hygiene: EXIF, PDF und Office vor der Veroffentlichung saubern. Der klassische Eigenschaden ist ein Report-PDF, dessen Metadaten dem Gegner Username, Hostname und den Dateipfad auf dem privaten Laptop des Forschers verraten.

Deployment-Checkliste

Bevor du das Lab als fertig bezeichnest, bestatige jeden Punkt: pfSense erzwingt Subnet-only-Regeln mit null Outbound-NAT; das Teamserver-Binary wurde cosign-verifiziert und lauft unter einer geharteten Non-root-systemd-Unit; Operator-Configs sind auf das C2-VLAN begrenzt; Windows-Ziele fahren Sysmon (SwiftOnSecurity-Config) mit Versand an einen lokalen Elastic-Cluster; das Mini-AD spiegelt eine realistische Topologie; jede Sigma-Regel ist versioniert mit ATT&CK-Tag und reproduzierbarem Quell-Profil; Snapshots liegen auf LUKS und verlassen den Host nie; und jedes exportierte Artefakt lief durch Metadaten-Review. Ist eine Zeile ungehakt, ist deine gesammelte Telemetrie noch keine vertrauenswurdige Grundwahrheit.

FAQ: Ist der Betrieb eines C2-Frameworks im Lab legal?

Ja, sofern der C2-Server und jedes Implant innerhalb einer Infrastruktur bleiben, die dir gehort und die du kontrollierst, ohne Route zu Drittsystemen. Das rechtliche Risiko im Offensiv-Tooling entsteht durch das Beruhren von Maschinen, fur die man keine Autorisierung hat. Ein air-gapped VLAN mit null Outbound-NAT beseitigt dieses Risiko vollstandig: das Implant hat schlicht kein Ziel. Halte schriftlichen Scope fur das Lab fest, labele die VMs und hange nie ein echtes Produktions-Credential oder echte Kundendaten an die Umgebung.

FAQ: Sliver, Mythic oder Cobalt Strike fur ein Defensiv-Lab?

Fur ein Defensiv-Telemetrie-Lab ist Sliver meist der beste Startpunkt: kostenlos, open source und auditierbar, sodass man jedes Verhalten zur Quelle zuruckverfolgen und Detektionen verallgemeinern kann. Mythic glanzt, wenn man ein diverses Agent-Okosystem modellieren will, kostet aber mehr Aufbau. Cobalt Strike steht fur einen grossen Anteil realer Einbruche, weshalb reife Teams es spater erganzen, um die Abdeckung zu verbreitern; seine Lizenzierung und geschlossene Natur machen es aber zu einem schlechten ersten Lernwerkzeug. Starte mit Sliver, verstehe die Grundlagen, erweitere dann.

Fazit

Wenn du eine Organisation verteidigst und noch nie einen Sliver-Beacon auf einem Bildschirm gesehen hast, den du selbst kontrollierst, ist deine Detection theoretisch. Blockiere dir einen kompletten Tag, bau das Lab mit pfSense plus Debian plus zwei Windows-Zielen, generiere ein unobfuskiertes Implant, lass es 30 Minuten Befehle ausfuhren und offne Sysmon. Du nimmst mehr konkretes Hunting-Material mit als aus mehreren bezahlten Kursen zusammen, und das mit null rechtlichem Risiko, weil alles im VLAN 10.50.0.0/16 passiert, das mit niemandem draussen spricht. Es geht nicht darum, Angreifer zu werden; es geht darum, die Verteidigung empirisch statt aspirativ zu machen.