Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus

Purple Team ist kein vierteljaehrlicher Workshop mit Pizza und huebschen Folien, sondern ein Engineering-Rhythmus, in dem jede vom Red ausgefuehrte TTP innerhalb von 72 Stunden zur Detektionshypothese fuer das Blue wird. Bei Basilisk OffSec fahren wir Zwei-Wochen-Sprints: 10 aus ATT&CK ausgewaehlte Techniken, kontrollierte Ausfuehrung im Unternehmenslabor und Abschluss mit einer in Produktion ausgerollten Sigma-Regel. Der KPI ist nicht, wie viele Shells das Red gepoppt hat, sondern wie viele Techniken von 'nicht erkannt' zu 'alarmiert mit niedriger False-Positive-Rate' wechselten. Wer dieses Delta nicht misst, betreibt teures Security-Theater. Dieser Leitfaden zerlegt den Zyklus in reproduzierbare Schritte, konkrete Werkzeuge und Metriken, die vor dem Vorstand standhalten.

Was Purple Team wirklich bedeutet

Red Team und Blue Team getrennt zu betreiben erzeugt zwei Wahrheiten: Angreifer, die Berichte schreiben, die niemand in Detektion umsetzt, und Verteidiger, die Regeln bauen, die kein realer Angreifer je ausloest. Purple Team loescht die Grenze, indem es beide Seiten an dieselbe Zeitachse und dasselbe Artefakt bindet. Es ist eine Funktion, kein permanentes Team: dieselben Menschen wechseln je Uebung die Rolle. Das operative Ziel ist die Verkuerzung der Feedback-Schleife von Monaten auf Tage. Ein reifer Zyklus produziert pro Sprint mindestens eine versionierte Detektion, ein verlinktes Response-Playbook und eine gemessene Reduktion der Mean Time To Detect fuer die geuebte Technik. Alles andere ist Vorbereitung.

Techniken nach echter Threat Intel priorisieren

Der Ausgangspunkt ist ein Technikkatalog, priorisiert nach echter Threat Intel, nicht nach Konferenz-Hype. Wir nehmen aktuelle Reports (Mandiant M-Trends, CrowdStrike OverWatch, BSI-Lageberichte) und kreuzen sie mit der ATT&CK Enterprise v15 Matrix. Fuer einen Finanzbetrieb landen zum Beispiel T1078.004 (Cloud-Konten), T1558.003 (Kerberoasting) und T1059.001 (PowerShell) ganz oben. Die Priorisierung folgt drei Achsen: Wahrscheinlichkeit gegen unser Sektorprofil, Blast-Radius bei Erfolg und aktuelle Detektionsluecke laut ATT&CK Navigator. Techniken, die wir schon zuverlaessig erkennen, wandern nach unten; die dunklen Flecken der Heatmap bestimmen den Sprint. So bleibt die Uebung an messbarem Risiko statt an persoenlichem Interesse ausgerichtet.

Der schriftliche Vertrag zwischen Red und Blue

Vor der Ausfuehrung dokumentiert das Red die genaue Prozedur, und das Blue skizziert, welche Telemetrie jeden Schritt erfassen sollte. Dieser schriftliche Vertrag toetet das klassische 'haben wir nicht gesehen, weil Splunk diesen Index nicht ingestiert hat'. Der Vertrag nennt pro Technik: erwartete Datenquelle (Sysmon Event ID 1, 4688, 4104, Zeek-Log), erwartetes Feld und Baseline-Rauschen. Fehlt die Datenquelle, ist das bereits ein Befund vor dem ersten Payload. Diese Trockenuebung deckt regelmaessig auf, dass ein Sensor ausgerollt, aber nicht eingesammelt wird, oder dass PowerShell Script Block Logging deaktiviert ist. Genau diese blinden Flecken retten spaeter reale Vorfaelle.

Kontrollierte Ausfuehrung im Zeitfenster

Die Ausfuehrung erfolgt im vereinbarten Fenster, mit Exercise-Flag in den Logs und offenem Slack-Kanal #purple-live. Jede Red-Aktion erhaelt UTC-Timestamp, Ziel-Hostname und Binary-Hash. Wenn wir Kerberoasting via Rubeus fahren, notiert der Operator das exakte extrahierte Ticket und das angegriffene Service-Konto. Parallel versucht der SOC-Analyst, in Echtzeit zu erkennen, ohne zu wissen, welcher Schritt als naechstes kommt, was das reale Szenario abbildet. Erkennt er es in vier Minuten, markieren wir gruen. Rutschte es durch, wird ein Jira-Ticket eroeffnet, dessen Prioritaet nach Kritikalitaet des beruehrten Assets festgelegt wird. Wir fahren bewusst mit deaktivierter OPSEC (laute Flags, Standard-Named-Pipes), damit das Blue die Artefakte ueberhaupt sehen kann.

Vom Befund zur dauerhaften Regel

Nach der Ausfuehrung beginnt die harte Arbeit: ein Finding in eine dauerhafte Regel zu verwandeln. Wir konvertieren Hypothesen zuerst in Sigma als herstellerneutrale Quelle der Wahrheit, dann in EQL auf Elastic und KQL auf Sentinel. Eine Regel wird nur dann nach main gemerged, wenn sie drei Kriterien erfuellt: sie deckt die Uebungstechnik ab, erzeugt weniger als 5 False Positives pro Woche in Staging und hat ein verlinktes Response-Playbook. Evasionstechniken zwingen das Team, Signaturen zu verlassen und auf Verhaltensdetektion zu setzen, mit Blick auf NtAllocateVirtualMemory-Calls, anomale Parent-Child-Muster und LSASS-Handle-Zugriffe. Eine Regel ohne Testfall, der sie beweislich ausloest, gilt als unfertig.

Auditierbare Uebungsinfrastruktur

Die Uebungsinfra muss auditierbar sein. Das C2 laeuft in einem isolierten VLAN mit vollstaendiger PCAP-Erfassung, und der Traffic wird per Port Mirror in das Staging-SIEM gespiegelt. Lateral Movement folgt einem festen Playbook mit Impacket und Evil-WinRM, immer mit lauten Flags, damit das Blue die Artefakte sieht. Internes Pivoting nutzt Chisel oder Ligolo-ng ueber sauber dokumentierte Tunnel. Alles wird in einem privaten Git-Repo protokolliert: jeder Red-Commit wird vom korrespondierenden Blue-Regel-PR referenziert, was eine Nachvollziehbarkeit schafft, die Auditoren lieben und Manager gern dem Vorstand zeigen. Snapshots der VMs vor und nach der Uebung erlauben saubere Wiederholung, wenn eine Regel nachjustiert werden muss.

Metriken und gemeinsame Sprache

Kommunikation killt mehr Purple-Team-Programme als Tool-Luecken. Wir etablieren gemeinsames Vokabular: 'erkannt' bedeutet, dass ein Alert generiert und triagiert wurde, nicht nur dass ein Log in irgendeinem kalten Index liegt. Retros dauern 60 Minuten mit drei Folien: ausgefuehrte Techniken, ausgelieferte Detektionen, offene technische Schulden. Metriken, die wir tracken: MTTD pro ATT&CK-Kategorie, Prozent der Tactics-Abdeckung in der Umgebung und Anzahl Regeln mit FP-Rate ueber Schwellwert. In sechs Monaten ging ein Kunde von 23% Credential-Access-Abdeckung auf 71%, mit 40% Rueckgang lauter Alerts. Diese Zahlen sind die Sprache, die Budget freisetzt.

Haeufige Fallstricke

Der erste Fallstrick ist der Wettbewerb: sobald das Red 'gewinnen' will, hoert es auf, laut zu spielen, und das Blue lernt nichts. Der zweite ist die Regel ohne Playbook, die um 3 Uhr morgens feuert und niemanden zur Handlung anleitet. Der dritte ist die nie in Staging getestete Regel, die in Produktion 200 False Positives pro Tag erzeugt und binnen einer Woche stummgeschaltet wird. Der vierte ist das Fehlen von Versionierung: eine Detektion, die nur im Kopf eines Analysten lebt, verschwindet mit ihm. Der fuenfte ist das Ueberspringen der Trockenuebung, wodurch fehlende Telemetrie erst mitten in der Ausfuehrung auffaellt und den Sprint sprengt.

Praktische Checkliste

Vor dem Sprint: fuenf sektorrelevante Techniken auswaehlen, schriftlichen Vertrag mit dem SOC schliessen, Datenquellen pro Technik verifizieren. Waehrend des Sprints: im Fenster mit Exercise-Flag und vollstaendigem Logging ausfuehren, jede Aktion mit Timestamp und Hash notieren, Detektionen live in #purple-live markieren. Nach dem Sprint: Sigma-Regel schreiben, in EQL und KQL uebersetzen, in Staging gegen FP-Schwelle testen, Response-Playbook verlinken, in Git mergen, MTTD messen. Kein Sprint gilt als fertig ohne ein einziges versioniertes Artefakt. Genau dieses Artefakt trennt kontinuierliche Detektion von einmaliger Unterhaltung.

Rollen, Rotation und Psychologie

Purple Team funktioniert nur, wenn die Rollen rotieren und niemand einen dauerhaften Gewinnerposten besetzt. In der Praxis wechselt ein Analyst, der drei Sprints lang Blue gespielt hat, bewusst auf die Red-Seite, um zu verstehen, wie fragil seine eigenen Detektionen unter leichter Variation sind. Diese Rotation baut Empathie auf und zerstoert die Silo-Mentalitaet, in der das Red die Verteidiger fuer langsam haelt und das Blue die Angreifer fuer Show-Offs. Der Facilitator, oft ein Detection Engineer, haelt die Uebung ehrlich: keine Gotcha-Momente, keine verheimlichten Payloads, kein Nachtreten in der Retro. Wenn eine Technik durchrutscht, ist das ein Systemfehler in der Telemetrie, kein persoenliches Versagen des Analysten. Genau diese Kultur bestimmt, ob das Programm nach dem dritten Sprint noch lebt oder in gegenseitigen Schuldzuweisungen erstickt. Ein Vorstand finanziert messbare Reifung, keine Schlammschlacht zwischen zwei Teams.

Automatisierung mit Atomic Red Team und CI

Sobald der manuelle Zyklus sitzt, automatisieren wir die Regression. Atomic Red Team liefert atomare, per YAML beschriebene Tests pro ATT&CK-Technik, die sich in einer Pipeline gegen eine Wegwerf-VM ausfuehren lassen. Nach jedem SIEM-Content-Update feuern wir die relevanten Atomics erneut und pruefen, ob die zugehoerige Sigma-Regel weiterhin ausloest; bricht sie, schlaegt der Build fehl, genau wie bei einem Unit-Test. So verhindern wir Detection-Drift, bei dem eine funktionierende Regel durch ein Feld-Rename im Log-Schema still verstummt. Die Ergebnisse landen als Abdeckungsbericht im selben Git-Repo, versioniert neben den Regeln. Wichtig bleibt die Grenze: Automatisierung ersetzt nicht die menschliche Hypothese, sie schuetzt nur das bereits Erreichte. Neue Techniken entstehen weiter aus Threat Intel und manueller Emulation; die CI haelt lediglich fest, dass keine bestehende Detektion unbemerkt zerfaellt, waehrend die Umgebung sich weiterentwickelt.

Der Uebergang von der Uebung zur echten Bedrohungsjagd

Ein reifes Purple-Team-Programm speist seine Ergebnisse direkt in proaktives Threat Hunting ein. Jede in einem Sprint gehaertete Sigma-Regel wird zur Hypothese fuer eine retrospektive Suche ueber historische Logs: Wenn wir Kerberoasting jetzt zuverlaessig erkennen, war die Technik vielleicht schon vor drei Monaten aktiv, als der Sensor noch schwieg. So verwandelt sich Detektion in Entdeckung bereits erfolgter Kompromittierungen. Wir dokumentieren jede Jagd mit ihrer leitenden Hypothese, dem abgefragten Zeitraum, dem Ergebnis und einer Entscheidung: neue Regel, Verfeinerung einer bestehenden oder bestaetigte Abwesenheit. Diese Rueckkopplung schliesst den Kreis zwischen Emulation, Detektion und Jagd und macht aus dem zweiwoechigen Sprint einen kontinuierlichen Reifeprozess, dessen Fortschritt sich an der schrumpfenden Zahl unentdeckter historischer Treffer messen laesst, nicht nur an der Live-Abdeckung von heute.

FAQ: Wie oft sollte ein Purple-Team-Zyklus laufen?

Zwei-Wochen-Sprints sind der Sweet Spot fuer die meisten Teams: kurz genug, um Momentum zu halten, lang genug, um eine Regel wirklich in Produktion zu haerten. Woechentlich brennt das Team aus und liefert halbfertige Detektionen; monatlich verliert die Feedback-Schleife ihre Schaerfe. Fuenf bis zehn Techniken pro Sprint sind realistisch, wenn jede mit einer versionierten Regel endet.

FAQ: Braucht man teure Tools fuer Purple Team?

Nein. Sysmon mit einer gehaerteten Konfiguration, der ELK-Stack oder Wazuh, Atomic Red Team fuer die Ausfuehrung und Sigma fuer portable Regeln reichen fuer einen kompletten Zyklus ohne Lizenzkosten. Der Engpass ist nie das Werkzeug, sondern die Disziplin, die Schleife zu schliessen und jede Technik in ein versioniertes Artefakt zu verwandeln.

Fazit

Praktischer Takeaway: klein und messbar starten. Waehlen Sie fuenf fuer Ihre Branche relevante Techniken, formulieren Sie einen schriftlichen Vertrag mit dem SOC, fuehren Sie in kurzem Fenster mit vollstaendigem Logging aus und schliessen Sie den Sprint nicht ohne in Git versionierte Sigma-Regel. Purple Team, das kein versioniertes Artefakt hinterlaesst, hat nicht skaliert, sondern nur unterhalten. Der Zyklus Red-baut-Hypothese, Blue-validiert-Telemetrie, Team-merged-Regel-in-Produktion muss in zwei Wochen passen. Dauert es laenger, managen Sie ein Projekt, statt kontinuierliche Detektion zu betreiben. Wiederholen Sie den Zyklus, bis die dunklen Flecken der ATT&CK-Heatmap zu gemessener Abdeckung werden.