Kurzfassung: Ein Blue-Team-Homelab besteht aus fünf VMs auf einem Rechner mit 16 bis 32 GB RAM: ein Domain Controller, ein Windows-Client mit Sysmon, Wazuh als SIEM, ein Zeek-Sensor am Mirror-Port und Kali mit Atomic Red Team als Angreifer. Der Aufbau dauert ein Wochenende. Der Wert entsteht in der Übungsschleife: Technik ausführen, Spuren in den Logs finden, Regel schreiben, erneut testen, in ATT&CK als abgedeckt markieren.
Ein Blue-Team-Homelab ist der schnellste Weg, Verteidigung wirklich zu lernen: eine kleine Windows-Domäne, ein SIEM, ein Netzwerksensor und ein Angreifer, den du selbst steuerst. Du führst eine Technik aus, schaust nach, was davon in den Logs ankommt, schreibst eine Regel und prüfst, ob sie greift. Diese Schleife ist das, was Detection Engineers und SOC-Analysten im Beruf den ganzen Tag tun, und du kannst sie auf einem einzigen Rechner nachbauen. Dieser Beitrag beschreibt den Bauplan, die fünf Aufbauschritte, die Übungsschleife und die Stolpersteine, die jeden beim ersten Mal erwischen.
Was das Homelab können soll
Das Lab muss drei Fragen beantworten können: Was passiert auf einem Endpunkt, wenn ein Angreifer eine Technik ausführt? Was davon sieht das Netz? Und welche Regel macht daraus einen Alarm? Dafür braucht es eine Umgebung, die einem Unternehmensnetz ähnlich genug ist, also Active Directory, Windows-Clients und echte Anmeldungen, sowie die drei Datenquellen, die in der Praxis zählen: Endpunkt-Telemetrie, zentrale Logs und Netzwerkverkehr. Alles andere ist Ausbau.
Der Bauplan
Ein Hypervisor auf einem Rechner mit 32 GB RAM ist bequem, 16 GB gehen mit Abstrichen. Proxmox auf einem ausrangierten Mini-PC ist die verbreitete Wahl, VirtualBox oder Hyper-V auf dem Arbeitsrechner funktionieren ebenfalls. Alle VMs hängen in einem eigenen, vom Heimnetz getrennten virtuellen Netz.
| VM | Rolle | RAM | Hinweis |
|---|---|---|---|
| Windows Server | Domain Controller, DNS | 4 GB | Evaluationsversion, 180 Tage |
| Windows 10 oder 11 | Client in der Domäne, Ziel der Angriffe | 4 GB | Ein zweiter Client lohnt sich für seitliche Bewegung |
| Ubuntu Server | Wazuh-Server (SIEM, Agenten-Verwaltung, Dashboard) | 8 GB | All-in-one-Installation |
| Ubuntu Server | Zeek-Sensor am Mirror-Port | 4 GB | Zweite Netzwerkkarte im Promiscuous-Modus |
| Kali Linux | Angreifer | 4 GB | Impacket, Responder, ein C2-Framework nach Wahl |
Wer weniger Speicher hat, lässt den zweiten Client weg und führt die Angriffe direkt auf dem Windows-Client aus; Atomic Red Team braucht keinen separaten Angreifer. Wer mehr hat, ersetzt die Zeek-VM durch Security Onion, das Zeek, Suricata und einen Elastic-Stack in einer Installation bündelt, und bekommt dafür eine zweite SIEM-Welt zum Vergleichen.
Netzplan
Ein fester Adressplan spart später Stunden, weil jede Regel, jede Suche und jedes Writeup dieselben Adressen benutzt. Das Lab-Netz ist ein eigenes virtuelles Netz ohne Verbindung zum Heimnetz; Internetzugang bekommt es nur über eine NAT-Schnittstelle des Hypervisors, die sich für Angriffsübungen abschalten lässt.
| System | Hostname | Adresse | Bemerkung |
|---|---|---|---|
| Lab-Netz | 10.10.10.0/24 | Isoliertes virtuelles Netz, Gateway 10.10.10.1 am Hypervisor | |
| Domain Controller | dc01.lab.local | 10.10.10.10 | DNS für alle Domänenmitglieder, Weiterleitung an den Hypervisor |
| Windows-Client 1 | ws01.lab.local | 10.10.10.21 | Ziel der meisten Tests, Benutzer ohne Adminrechte |
| Windows-Client 2 | ws02.lab.local | 10.10.10.22 | Ziel für seitliche Bewegung, optional |
| Wazuh | siem.lab.local | 10.10.10.30 | Dashboard auf Port 443, Agenten melden sich an 1514 und 1515 |
| Zeek-Sensor | sensor.lab.local | 10.10.10.31 | Verwaltungskarte; die Sensorkarte hat keine Adresse |
| Kali | kali | 10.10.10.99 | Nicht in der Domäne, wie ein echter Angreifer |
Der Domain Controller ist DNS für alle Windows-Systeme, sonst funktionieren Kerberos und Gruppenrichtlinien nicht. Der Zeek-Sensor braucht zwei Netzwerkkarten: eine mit Adresse für Verwaltung und Logversand, eine ohne Adresse am Mirror des Lab-Switches, die nur mithört. Wer die Adressen so übernimmt, kann die Beispiele in den anderen Beiträgen dieser Seite ohne Anpassung nachvollziehen.
Schritt 1: Active Directory mit Absicht unsicher
Der Domain Controller bekommt eine Domäne, drei Benutzer mit verschiedenen Rollen und ein Dienstkonto mit registriertem Service Principal Name und schwachem Passwort. Das Dienstkonto ist Absicht: Es ist das Ziel für Kerberoasting, und du willst sehen, wie das im Log aussieht. Dann die Gruppenrichtlinie, ohne die das Lab blind bleibt: erweiterte Überwachungsrichtlinie nach Microsofts Empfehlung, Befehlszeile in Prozessereignissen, PowerShell Script Block Logging. Welche Ereignisse das freischaltet, steht in der Referenz zu den Windows-Event-IDs.
Schritt 2: Sysmon auf jedem Windows-System
Sysmon liefert die Endpunkt-Telemetrie, die Windows selbst nicht schreibt: Netzwerkverbindungen pro Prozess, DNS-Anfragen, Zugriffe auf den LSASS-Prozess, geladene Treiber. Die Kunst liegt in der Konfiguration, und die schreibst du nicht selbst. sysmon-modular von Olaf Hartong ist eine modular aufgebaute, nach ATT&CK-Techniken kommentierte Konfiguration, die sich für das Lab unverändert übernehmen lässt. Installation auf Domain Controller und Clients, dann prüfen, ob Ereignisse 1, 3, 10 und 22 im Log Microsoft-Windows-Sysmon/Operational erscheinen. Wenn ja, steht die wichtigste Datenquelle des Labs.
Schritt 3: Wazuh als SIEM
Wazuh ist für das Homelab die pragmatische Wahl: quelloffen, mit einem Installationsskript für die All-in-one-Variante, mit Agenten für Windows und Linux, mit einem Regelwerk, das Sysmon und Windows-Ereignisse versteht, und mit einer fertigen Zuordnung der Regeln zu ATT&CK-Techniken im Dashboard. Die Wazuh-Dokumentation führt durch Installation und Agentenanbindung. Zwei Dinge musst du nach der Standardinstallation selbst tun: In der Agentenkonfiguration der Windows-Systeme den Sysmon-Kanal und den PowerShell-Kanal als Logquellen eintragen, sonst kommt die Telemetrie nie an. Und die Regel-Schwellen so setzen, dass Sysmon-Ereignisse nicht nur gespeichert, sondern bei Bedarf alarmiert werden.
Der erste Test: Auf dem Client eine PowerShell mit kodiertem Befehl starten und im Wazuh-Dashboard nachsehen, ob Event 4688 mit Befehlszeile, Sysmon 1 und PowerShell 4104 ankommen. Wenn alle drei da sind, funktioniert die Kette von Endpunkt zu SIEM.
Schritt 4: Zeek am Mirror-Port
Der Sensor bekommt eine zweite Netzwerkkarte am virtuellen Switch des Lab-Netzes, und im Hypervisor wird für diese Karte der Promiscuous-Modus erlaubt, sonst sieht Zeek nur seinen eigenen Verkehr. Nach der Installation der Binary-Pakete und einem Start gegen die Sensorkarte füllen sich die Logs; mit JSON als Ausgabeformat liest der Wazuh-Agent sie direkt ein, oder du sammelst sie parallel in einem eigenen Index. Wie die Logs aufgebaut sind und was sich darin erkennen lässt, steht im Beitrag zu Zeek. Erster Test: Vom Client eine Website aufrufen und im dns.log, conn.log und ssl.log die Spur verfolgen, verbunden über die uid.
Schritt 5: Der Angreifer
Für den Einstieg ist Atomic Red Team das Werkzeug der Wahl: eine Bibliothek kleiner, dokumentierter Tests, sortiert nach ATT&CK-Technik, ausführbar per PowerShell-Modul direkt auf dem Client. Vier Techniken, mit denen sich jede Datenquelle des Labs prüfen lässt:
- T1059.001, PowerShell mit kodiertem Befehl. Prüft 4688, Sysmon 1 und 4104.
- T1003.001, Zugangsdaten aus dem LSASS-Speicher. Prüft Sysmon 10 und ist der klassische Testfall für jede Erkennung.
- T1053.005, geplante Aufgabe als Persistenz. Prüft 4698 und den Task-Scheduler-Kanal.
- T1558.003, Kerberoasting. Prüft 4769 auf dem Domain Controller und das kerberos.log im Zeek-Sensor, beide zugleich.
Von der Kali-VM aus kommen danach die Werkzeuge, die echte Angreifer benutzen: Impacket für PsExec- und WMI-Ausführung auf dem Client, sichtbar im dce_rpc.log und in Event 7045, Responder für das Abfangen von Anmeldeversuchen, und ein C2-Framework, um Beaconing im conn.log zu erzeugen. Jeder dieser Angriffe hat ein bekanntes Muster, und das Lab ist der Ort, es einmal selbst gesehen zu haben.
Die Übungsschleife
- Technik in ATT&CK auswählen und die zugehörige Detection Strategy lesen: Welche Ereignisse sollten entstehen?
- Snapshot der VMs anlegen, Technik ausführen, Uhrzeit notieren.
- In Wazuh und in den Zeek-Logs suchen: Ist die Technik sichtbar, und hat eine Regel angeschlagen?
- Fehlt die Regel, schreiben: als Wazuh-Regel oder zuerst als Sigma-Regel, die sich später in jedes SIEM übersetzen lässt.
- Technik erneut ausführen, Alarm prüfen, Technik im ATT&CK Navigator als abgedeckt markieren.
Das ist im Kleinen genau die Purple-Team-Übung, die große Organisationen mit zwei Teams durchführen, und wer die Schleife zwanzig Mal durchlaufen hat, kann im Vorstellungsgespräch über Detection Engineering reden, statt darüber zu lesen. Wer daneben an fremden Vorfällen üben will, findet sie in den Blue-Team-CTFs. Die Logs, die dabei entstehen, sind außerdem das beste Material für erste Threat-Hunting-Hypothesen.
Stolpersteine
- Der Sensor sieht nichts. Fast immer der fehlende Promiscuous-Modus am virtuellen Switch. Bei VirtualBox und Proxmox eine Einstellung der Netzwerkkarte, bei Hyper-V ein Port-Mirroring an der VM.
- Zeitversatz. Wenn Client, Domain Controller und Sensor nicht dieselbe Zeit haben, lassen sich Ereignisse nicht korrelieren. NTP auf allen Systemen, bevor irgendetwas anderes passiert.
- Sysmon zu gesprächig. Eine Konfiguration, die alles loggt, erzeugt auf einem einzigen Client Gigabytes pro Tag. Die modularen Konfigurationen filtern bekannte harmlose Prozesse; das ist Absicht.
- Snapshots vergessen. Manche Tests verändern das System dauerhaft. Snapshot vor dem Angriff, Rollback danach, sonst häufen sich die Artefakte und du erkennst nach einem Monat deine eigene Umgebung nicht mehr.
- Ablaufende Lizenzen. Die Windows-Evaluationsversionen laufen nach 180 Tagen ab. Wer das Lab länger betreibt, plant den Neuaufbau ein, was mit Snapshots und einer Handvoll Skripte in einer Stunde erledigt ist.
Snapshots und Neuaufbau: das Lab am Leben halten
Ein Lab, das nach drei Monaten voller Artefakte, halb entfernter Persistenz und abgelaufener Lizenzen ist, wird nicht mehr benutzt. Drei Regeln verhindern das. Erstens ein sauberer Grundzustand: Nach dem Aufbau und dem ersten erfolgreichen Test der Kette von Endpunkt zu SIEM bekommt jede VM einen Snapshot mit dem Namen „Basis“. Zweitens ein Snapshot vor jeder Übung, benannt nach Technik und Datum, und ein Rollback danach; nur der Wazuh-Server behält seinen Zustand, weil seine Daten die Ergebnisse sind. Drittens ein Export der Regeln, die du geschrieben hast, in ein eigenes Repository, getrennt vom Lab, sodass ein Neuaufbau kein Verlust ist.
Der Neuaufbau selbst kommt spätestens mit dem Ablauf der Windows-Evaluationsversionen nach 180 Tagen. Wer ihn einmal in Skripten festgehalten hat, braucht dafür eine Stunde: Domäne und Benutzer per PowerShell anlegen, Überwachungsrichtlinie als exportierte Gruppenrichtlinie importieren, Sysmon mit Konfiguration per Skript installieren, Wazuh-Agent mit eingebetteter Serveradresse ausrollen. Dieselben Skripte sind nebenbei ein Nachweis für die Bewerbung, weil sie zeigen, dass der Aufbau verstanden und nicht nur zusammengeklickt wurde.
Ausbau
Wenn die Grundschleife läuft, wächst das Lab mit den Fragen. Velociraptor für Endpoint-Forensik und Hunting über alle Clients. TheHive und MISP, um Vorfälle und Indikatoren so zu verwalten, wie ein SOC es tut. MITRE Caldera, um ganze Angriffsketten statt einzelner Techniken zu emulieren. Wie eine strukturierte Purple-Team-Übung mit Atomic Red Team abläuft, steht im eigenen Beitrag. Ein Elastic-Stack neben Wazuh, um zu verstehen, was ein zweites SIEM anders macht. Und irgendwann ein Cloud-Anteil mit einem kostenlosen Entra-ID-Tenant, weil die Hälfte der echten Vorfälle inzwischen dort beginnt.
Der Cloud-Anteil konkret: ein Entra-ID-Tenant im Lab
Ein eigener Microsoft-Entra-ID-Tenant kostet in der Grundstufe nichts und ist in zwanzig Minuten angelegt. Für das Lab braucht er drei Dinge: eine Handvoll Benutzer, davon einer mit Administratorrolle und einer mit einer schwachen Passwortrichtlinie als Testziel, die Anmeldeprotokolle als Logquelle und eine Verbindung zum SIEM. Wazuh bringt eine Integration für Microsoft-Protokolle mit, die Anmelde- und Audit-Ereignisse über die API abholt; Elastic und Security Onion haben Entsprechendes. Danach lassen sich die Vorfälle üben, die im Beruf am häufigsten vorkommen: Password Spraying gegen Cloud-Konten, eine Anmeldung von einem unbekannten Gerät mit bestätigter MFA, eine neu registrierte Authentifizierungsmethode, eine Zustimmung für eine Drittanwendung, eine Postfachregel mit Weiterleitung. Die Erkennung dafür sieht anders aus als bei Windows-Ereignissen, weil die Felder andere sind und der Kontext, etwa Standort und Gerätekonformität, über Anmeldeprotokolle statt Prozessbäume kommt. Wer beides im Lab hat, die Domäne und den Tenant, deckt die zwei Welten ab, in denen sich reale Vorfälle heute abspielen, und kann die Kette nachstellen, die im Phishing-Playbook beschrieben ist: Klick auf dem Client, Anmeldung in der Cloud, Postfachregel, Datenabfluss.
Häufige Fragen zum Blue-Team-Homelab
Reicht ein Laptop mit 16 GB RAM?
Ja, mit drei VMs statt fünf: Domain Controller, ein Client und Wazuh, alle knapp bemessen. Den Zeek-Sensor kann der Wazuh-Server übernehmen, wenn er eine zweite Netzwerkkarte bekommt, und der Angreifer läuft als Atomic Red Team direkt auf dem Client. Komfortabel wird es ab 32 GB, und ein gebrauchter Mini-PC mit 64 GB kostet weniger als ein Zertifizierungskurs.
Ist es legal, im eigenen Lab Angriffe auszuführen?
Auf eigenen Systemen in einem isolierten Netz ja. Die Grenze ist das Netz anderer: Kein Test darf das Lab verlassen, deshalb die Trennung vom Heimnetz und ein Internetzugang, der sich abschalten lässt. Werkzeuge wie Responder oder ein C2-Framework gehören ausschließlich ins Lab-Netz, und Schadsoftware aus der freien Wildbahn hat im Homelab nichts verloren, solange es keine Sandbox-Umgebung mit eigenen Schutzmaßnahmen ist.
Wazuh oder Elastic oder Security Onion?
Für den ersten Aufbau Wazuh, weil die Installation ein Skript ist und die Windows-Regeln fertig mitkommen. Security Onion, wenn das Netzwerk im Mittelpunkt stehen soll und Hardware da ist. Elastic, wenn das Ziel ein bestimmter Arbeitgeber mit Elastic-Stack ist. Wer die Schleife in einem beherrscht, lernt das zweite in einer Woche; die Datenquellen und Regeln sind dieselben.
Wie lange dauert der Aufbau?
Ein Wochenende für die fünf VMs bis zum ersten erfolgreichen Test der Kette von Endpunkt zu SIEM, wenn nichts schiefgeht, und meist geht der Promiscuous-Modus oder die Zeit schief. Wer die Stolpersteine oben vorher liest, spart den halben Sonntag.
Was mache ich mit dem Lab in der Bewerbung?
Drei Writeups aus der Übungsschleife: Technik, Spuren, Regel, Test, mit Screenshots aus dem SIEM. Dazu die Aufbauskripte in einem Repository. Das zeigt mehr als jede Werkzeugliste im Lebenslauf, und im Interview ist es das Material, über das man reden kann. Wie sich das in eine Bewerbung als SOC-Analyst einbaut, steht im eigenen Beitrag.
Fazit
Ein Blue-Team-Homelab kostet einen Rechner, ein Wochenende und die Bereitschaft, Dinge kaputtzumachen. Dafür liefert es das, was kein Kurs und kein Buch liefern kann: die Erfahrung, eine Angriffstechnik ausgeführt, ihre Spuren gefunden und eine Regel geschrieben zu haben, die sie beim nächsten Mal meldet. Wer das mit zwanzig Techniken gemacht hat, versteht, was ein Blue Team tut, besser als die meisten, die es beruflich tun, ohne je eines gebaut zu haben.