Real World Beispiele: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

In realen Umgebungen ist Purple Teaming kein Show-Angriff und keine reine Tool-Demonstration. Der operative Wert entsteht erst dann, wenn ein Angriffspfad kontrolliert simuliert, sauber beobachtet, technisch ausgewertet und anschließend in konkrete Verbesserungen übersetzt wird. Genau an diesem Punkt scheitern viele Teams. Es wird Payload gegen Zielsystem geschossen, ein paar Alerts werden betrachtet, danach endet die Übung ohne belastbare Erkenntnisse. Ein echter Purple-Teaming-Ansatz verfolgt dagegen ein anderes Ziel: nachvollziehbar prüfen, welche Angriffsaktivitäten sichtbar sind, welche unsichtbar bleiben, welche Telemetrie fehlt und wie Detection, Logging, Response und Härtung verbessert werden können.

Der Unterschied zwischen Theorie und Praxis zeigt sich vor allem in der Vorbereitung. In einer Laborumgebung ist meist bekannt, welche Systeme vorhanden sind, welche Agenten laufen und welche Logs ankommen. In produktiven Netzen sieht das anders aus. Dort existieren Legacy-Systeme, unvollständige Asset-Daten, uneinheitliche Logquellen, Ausnahmen in der EDR-Konfiguration, lokale Administratorrechte auf Einzelgeräten, falsch gesetzte Ausschlüsse und oft auch organisatorische Brüche zwischen SOC, Infrastruktur, Incident Response und Systemadministration. Deshalb muss Purple Teaming immer als abgestimmter Prozess verstanden werden, nicht nur als Angriffssimulation.

Ein realistischer Einstieg beginnt mit einer klaren Hypothese. Beispiel: Ein Angreifer mit initialem Zugriff auf einen Windows-Client versucht Credential Access, Discovery und laterale Bewegung. Dann wird nicht wahllos getestet, sondern entlang eines konkreten Pfades gearbeitet. Das kann an Und Mitre Attack ausgerichtet werden, etwa mit T1059 für Command and Scripting Interpreter, T1003 für OS Credential Dumping oder T1021 für Remote Services. Entscheidend ist, dass jede Aktion mit erwarteter Telemetrie, vorhandenen Kontrollen und Erfolgskriterien verknüpft wird.

In produktiven Übungen ist außerdem die Frage zentral, ob die Maßnahme validierend oder entwickelnd ist. Validierend bedeutet: vorhandene Detection-Regeln und Response-Prozesse werden gegen bekannte Techniken geprüft. Entwickelnd bedeutet: während der Übung werden neue Erkennungslogiken gebaut, Logquellen ergänzt oder Korrelationen angepasst. Viele Teams vermischen beides unkontrolliert. Besser ist eine saubere Trennung mit klarer Zielsetzung, wie sie auch in Workflow und Methodik strukturiert wird.

Ein weiterer Praxisfaktor ist die Sicherheitsgrenze. Nicht jede Technik darf in jeder Umgebung voll ausgeführt werden. LSASS-Zugriffe, Kerberoasting, Pass-the-Hash, WMI-basierte Ausführung oder Änderungen an Gruppenrichtlinien können produktive Risiken erzeugen. Deshalb werden reale Übungen oft in abgestuften Modi gefahren: reine Emulation, eingeschränkte Ausführung, kontrollierte Ausführung mit Rollback oder Vollsimulation in isolierten Segmenten. Wer diese Abstufung ignoriert, produziert unnötige Betriebsrisiken oder erhält umgekehrt nur oberflächliche Ergebnisse.

Real World Beispiele sind deshalb wertvoll, weil sie nicht nur zeigen, was technisch möglich ist, sondern wie Teams unter realen Randbedingungen arbeiten: mit Change-Fenstern, Freigaben, Monitoring-Lücken, Zeitdruck und begrenzter Sichtbarkeit. Genau dort entsteht belastbares Praxiswissen, das über reine Beispiele hinausgeht.

Ein typisches Szenario in Unternehmensnetzen beginnt mit einem Benutzerkontext auf einem Arbeitsplatzsystem. Für Purple Teaming muss dafür nicht zwingend echtes Phishing gegen Mitarbeiter durchgeführt werden. Häufig reicht eine kontrollierte Annahme: Ein Benutzer hat ein präpariertes Dokument geöffnet oder eine Datei aus einem Collaboration-Tool gestartet. Der Fokus liegt dann nicht auf Social Engineering, sondern auf der Frage, welche Folgeaktivitäten sichtbar werden.

Ein realistischer Ablauf kann so aussehen: Ein Office-Dokument startet einen Child-Prozess, dieser lädt ein Script nach oder führt eingebettete Befehle aus, danach beginnt lokale Discovery. In vielen Umgebungen ist der erste interessante Punkt nicht die Ausführung selbst, sondern die Prozesskette. Word startet cmd.exe, powershell.exe oder rundll32.exe. Wenn diese Kette im EDR nicht sauber erfasst oder im SIEM nicht korreliert wird, bleibt der Einstieg trotz vorhandener Sensorik praktisch unsichtbar.

Die technische Auswertung beginnt mit den Basisfragen: Wurde die Parent-Child-Beziehung geloggt? Sind Command-Line-Parameter vorhanden? Gibt es Script Block Logging, AMSI-Telemetrie, PowerShell Operational Logs oder nur grobe Prozessereignisse? Wurde ein Alert ausgelöst oder nur ein Rohereignis erzeugt? Hat das SOC den Kontext gesehen oder nur einen einzelnen Prozessstart ohne Benutzerbezug? Genau diese Fragen trennen operative Detection von bloßer Datensammlung.

Ein häufiger Fehler besteht darin, nur auf Signaturen zu vertrauen. Wenn die Payload leicht verändert wird, Base64-Parameter anders aufgebaut sind oder statt PowerShell ein alternatives LOLBin verwendet wird, bricht die Erkennung weg. Purple Teaming muss deshalb verhaltensbasiert prüfen. Relevant sind nicht nur bekannte Hashes oder Strings, sondern Muster wie Office-Prozess startet Interpreter, Interpreter erzeugt Netzwerkverbindung, danach folgen Discovery-Kommandos und Zugriffe auf sicherheitsrelevante Artefakte.

• Prozesskette inklusive Parent, Child, Command Line und Benutzerkontext erfassen
• Netzwerkverbindungen des gestarteten Prozesses mit Ziel, Port und Zeitbezug korrelieren
• Script- und Speichertelemetrie prüfen, nicht nur klassische AV-Treffer
• Alarmierung gegen Verhalten testen, nicht nur gegen konkrete Payloads

In einem realen Fall zeigte sich, dass Office-Child-Prozesse zwar im EDR sichtbar waren, aber nicht an das zentrale SIEM weitergeleitet wurden. Das Blue Team sah lokal im Endpoint-Portal verdächtige Aktivität, im SOC-Workflow erschien jedoch kein Alarm. Die Folge war eine gefährliche Scheinsicherheit: Sensorik war vorhanden, operative Erkennung aber nicht. Erst durch die gemeinsame Analyse im Purple-Team-Format wurde klar, dass nicht die Detection-Logik, sondern die Pipeline zwischen Endpoint und zentralem Monitoring das Problem war.

Ein sauberer Workflow dokumentiert in diesem Fall mindestens vier Ergebnisse: welche Technik erfolgreich emuliert wurde, welche Telemetrie vorhanden war, welche Detection fehlte und welche konkrete Maßnahme daraus folgt. Das kann eine neue Korrelation, eine Anpassung im Log-Forwarding, eine Härtung von Office-Makros oder eine Priorisierung im SOC sein. Ohne diese Ableitung bleibt das Beispiel technisch interessant, aber operativ wertlos.

Credential Access ist einer der Bereiche, in denen Purple Teaming besonders wertvoll ist, weil viele Teams glauben, hier bereits gut aufgestellt zu sein. In der Praxis zeigt sich jedoch oft das Gegenteil. Ein EDR blockiert bekannte Mimikatz-Binaries, also wird angenommen, dass das Thema beherrscht ist. Ein Angreifer arbeitet aber selten mit Standard-Binaries und noch seltener in genau der Form, die in Produktdemos gezeigt wird.

Ein realistisches Purple-Teaming-Szenario prüft deshalb nicht nur, ob ein bekanntes Tool erkannt wird, sondern welche Verhaltensmuster rund um LSASS-Zugriffe, Handle-Anfragen, Speicherzugriffe, Debug-Rechte, verdächtige DLL-Ladevorgänge oder Security-Provider-Manipulationen sichtbar sind. Schon die Frage, ob ein Prozess mit ungewöhnlichen Rechten auf LSASS zugreift, kann mehr Erkenntnis liefern als ein einfacher Signaturtest.

Ein häufiger Praxisfehler ist die Verwechslung von Prävention und Sichtbarkeit. Wenn ein Schutzmechanismus den direkten Zugriff blockiert, bedeutet das noch nicht, dass alternative Wege erkannt werden. Ein Team sollte deshalb mehrere Varianten testen: direkte Speicherzugriffe, MiniDump-Erstellung, Missbrauch legitimer Tools, Zugriff über signierte Hilfsprogramme oder indirekte Techniken, die nur Teilaspekte des Credential Access abbilden. Dabei muss jede Variante mit dem Risiko für die Zielumgebung abgestimmt werden.

In einem realen Unternehmensszenario war der direkte LSASS-Zugriff durch EDR-Regeln gut geschützt. Das Team ging deshalb von hoher Reife aus. Während der Purple-Teaming-Übung wurde jedoch sichtbar, dass bereits vorbereitende Schritte wie Privilege Escalation, Token-Kontextwechsel und verdächtige Prozessstarts nicht alarmiert wurden. Das bedeutete: Der eigentliche Dump wurde zwar verhindert, die Angriffskette bis kurz vor den kritischen Schritt blieb aber weitgehend unbeobachtet. Für einen Verteidiger ist das problematisch, weil frühe Erkennung verloren geht und Reaktionszeit verschenkt wird.

Technisch sauber wird dieses Szenario erst, wenn die Kette vollständig betrachtet wird: Wie wurde der Prozess gestartet? Welche Rechte hatte der Benutzer? Gab es UAC-Bypass-Indikatoren? Welche Security-Events, Sysmon-Events oder EDR-Telemetrie lagen vor? Welche Felder fehlten? Wurde der Versuch nur lokal blockiert oder auch zentral gemeldet? Gab es eine Korrelation mit vorheriger Discovery oder Credential Enumeration?

Gerade hier lohnt sich die Verbindung zu Und Detection Engineering. Detection-Regeln sollten nicht nur den finalen Dump adressieren, sondern auch vorbereitende Muster. Dazu gehören ungewöhnliche Prozessbeziehungen, Zugriff auf sensible Speicherbereiche, verdächtige Nutzung administrativer Werkzeuge und Abweichungen vom üblichen Benutzerverhalten. Wer nur auf den letzten Schritt schaut, erkennt den Angriff zu spät oder gar nicht.

Ein belastbares Ergebnis aus diesem Beispiel ist nicht die Aussage, dass Credential Dumping möglich oder unmöglich war. Wertvoll ist die präzise Aussage, an welcher Stelle die Verteidigung sichtbar, unsichtbar, blockierend oder blind war. Genau daraus entstehen Verbesserungen in Logging, Use Cases, EDR-Policies und SOC-Playbooks.

Laterale Bewegung ist in realen Umgebungen selten ein einzelner spektakulärer Schritt. Meist besteht sie aus mehreren unauffälligen Aktionen: Host Discovery, Prüfung erreichbarer Shares, Authentifizierungsversuche, Remote Service Creation, WMI-Aufrufe, geplante Tasks oder Remote Process Execution. Jede Einzelaktion kann für sich harmlos wirken. Erst die Korrelation macht daraus ein Angriffsmuster.

Ein typisches Purple-Teaming-Beispiel startet mit einem kompromittierten Client und gültigen Zugangsdaten. Das Red-Team-Element versucht, auf einen zweiten Host zuzugreifen, dort einen Dienst anzulegen oder per WMI einen Prozess zu starten. Das Blue Team prüft parallel, welche Ereignisse auf Quell- und Zielsystem entstehen, ob Authentifizierungsereignisse mit Prozessdaten verbunden werden können und ob das SIEM die Sequenz als laterale Bewegung erkennt.

In vielen Umgebungen scheitert die Erkennung nicht an fehlenden Logs, sondern an fehlender Verknüpfung. Security Event 4624 ist vorhanden, Service Creation Events sind vorhanden, Prozessstarts sind vorhanden, Netzwerkdaten sind vorhanden. Trotzdem entsteht kein Alert, weil die Datenquellen in unterschiedlichen Systemen liegen, Zeitstempel nicht sauber synchronisiert sind oder die Regel nur auf einem einzelnen Host statt netzwerkweit denkt. Genau deshalb ist Purple Teaming eng mit Und Log Analyse verbunden.

Ein realer Fehler aus der Praxis: Das SOC hatte eine Regel für verdächtige Service-Erstellung, aber nur auf Servern mit kritischer Klassifizierung. Workstations waren ausgeschlossen, um Rauschen zu reduzieren. Ein Angreifer konnte sich dadurch unauffällig zwischen mehreren Clients bewegen, bevor ein Serverkontakt überhaupt sichtbar wurde. Die Regel war technisch korrekt, operativ aber zu eng gefasst. Purple Teaming deckt solche Designfehler auf, weil nicht nur einzelne Events betrachtet werden, sondern der tatsächliche Bewegungsraum eines Angreifers.

Für dieses Szenario ist es sinnvoll, mehrere Varianten zu testen. SMB-basierte Dateiablage mit anschließendem Remote Start verhält sich anders als WMI oder Scheduled Tasks. Manche EDR-Produkte liefern starke Prozesssicht, aber schwache Remote-Kontextinformationen. Andere Systeme zeigen Authentifizierung gut, verlieren aber die Ausführungskette. Deshalb sollte die Übung nicht mit einer einzigen Technik enden, sondern Varianten vergleichen, wie es auch in Szenarien und Use Cases sinnvoll ist.

Ein sauberer Workflow für laterale Bewegung enthält immer die Perspektive beider Seiten: Was wurde auf dem Quellhost sichtbar, was auf dem Zielhost, was im Netzwerk und was im zentralen Monitoring? Erst wenn diese Ebenen zusammengeführt werden, lässt sich bewerten, ob die Organisation tatsächlich in der Lage ist, eine Bewegung im Netz frühzeitig zu erkennen.

In modernen Umgebungen verlagert sich der Schwerpunkt von Host-zentrierten Angriffen zunehmend auf Identitäten, Tokens, API-Zugriffe und Fehlkonfigurationen in Cloud-Diensten. Purple Teaming in hybriden Infrastrukturen muss deshalb anders geplant werden als klassische Windows-Domänenübungen. Nicht der einzelne Prozess auf einem Endpoint ist entscheidend, sondern die Frage, welche Identitätsereignisse, Rollenwechsel, Consent-Vorgänge, Token-Nutzungen und API-Aufrufe sichtbar sind.

Ein realistisches Beispiel ist der Missbrauch eines kompromittierten Kontos mit Zugriff auf Cloud-Ressourcen. Das Szenario beginnt mit gültigen Zugangsdaten oder einem Session-Token. Danach folgen Enumeration von Ressourcen, Prüfung von Rollen, Zugriff auf Storage, Änderung von Sicherheitsgruppen oder das Anlegen zusätzlicher Persistenzmechanismen. In hybriden Umgebungen kommt hinzu, dass On-Prem- und Cloud-Sicht oft organisatorisch getrennt sind. Das Endpoint-Team sieht den Login auf dem Client, das Cloud-Team sieht API-Calls, aber niemand verbindet beides.

Gerade in Azure-, AWS- oder Kubernetes-nahen Umgebungen ist Purple Teaming nur dann belastbar, wenn Audit-Logs, Identity-Provider-Daten, CloudTrail- oder Activity-Logs, Container-Runtime-Ereignisse und Netzwerkdaten gemeinsam ausgewertet werden. Sonst entsteht eine gefährliche Lücke: Der initiale Zugriff ist sichtbar, die eigentliche Wirkung in der Cloud aber nicht. Wer tiefer in diese Bereiche einsteigen will, findet angrenzende Themen in In Cloud Umgebungen, In Azure und In Kubernetes.

Ein häufiger Fehler in der Praxis ist die Konzentration auf Fehlkonfigurationen ohne Detection-Perspektive. Dann wird zwar geprüft, ob ein Storage-Bucket offen ist oder eine Rolle zu weitreichend berechtigt wurde, aber nicht, ob die Nutzung dieser Fehlkonfiguration überhaupt erkannt würde. Purple Teaming muss genau diese Lücke schließen. Nicht nur die Schwachstelle zählt, sondern die Sichtbarkeit ihrer Ausnutzung.

• Identitätsereignisse mit Cloud-Aktivitäten und Endpoint-Telemetrie zeitlich verknüpfen
• Rollenwechsel, Token-Nutzung und API-Aufrufe als Angriffskette statt als Einzelereignisse bewerten
• Persistenz in Cloud-Diensten gesondert testen, etwa über neue Schlüssel, Rollen oder Automatisierungen
• Detection-Regeln gegen legitime Admin-Aktivität abgrenzen, um Fehlalarme kontrollierbar zu halten

Ein reales Ergebnis aus solchen Übungen ist oft ernüchternd: Die Organisation verfügt über umfangreiche Cloud-Logs, aber kaum ausgereifte Use Cases. Es existieren Daten, jedoch keine belastbare Erkennung. Oder umgekehrt: Es gibt einzelne Alerts, aber keine Möglichkeit, sie mit On-Prem-Ereignissen zu verbinden. Erst im Purple-Teaming-Format wird sichtbar, dass die technische Grenze nicht im Angriff, sondern in der fehlenden Zusammenführung der Telemetrie liegt.

Der häufigste Fehler ist fehlende Zielschärfe. Wenn eine Übung mit der Vorgabe startet, einfach einmal Angriffstechniken zu testen, endet sie fast immer in einer unsauberen Sammlung von Einzelergebnissen. Gute Purple-Teaming-Arbeit beginnt mit klaren Fragen: Soll eine bestehende Detection validiert werden? Soll ein neuer Use Case entwickelt werden? Soll die Sichtbarkeit einer bestimmten Technikfamilie geprüft werden? Oder geht es um die Reaktionsfähigkeit des SOC? Ohne diese Trennung werden Ergebnisse unpräzise und Maßnahmen beliebig.

Ein zweiter Fehler ist die Vermischung von Pentest-Denken und Purple-Team-Zielen. Ein klassischer Penetrationstest bewertet primär, ob ein Angriffspfad technisch möglich ist. Purple Teaming bewertet zusätzlich, wie sichtbar dieser Pfad ist und wie die Verteidigung verbessert werden kann. Wer Purple Teaming wie einen verkürzten Pentest behandelt, produziert zwar Findings, aber keine belastbare Verbesserung der Detection. Der Unterschied wird besonders deutlich im Vergleich zu Vs Penetrationstest und Vs Red Teaming.

Ein dritter Fehler ist unvollständige Dokumentation. In vielen Teams wird festgehalten, dass eine Technik funktioniert hat oder ein Alert ausgelöst wurde. Es fehlt aber die technische Tiefe: exakte Befehle, Zeitpunkte, Hostnamen, Benutzerkontexte, Logquellen, Event-IDs, EDR-Detections, SIEM-Regeln, Analystenreaktion und Abweichungen vom erwarteten Verhalten. Ohne diese Details ist keine saubere Reproduktion möglich. Detection Engineering wird dadurch unnötig erschwert.

Ebenso problematisch ist die Konzentration auf Tools statt auf Verhaltensmuster. Wenn eine Übung nur prüft, ob Metasploit, Cobalt Strike oder ein bestimmtes Open-Source-Tool erkannt wird, bleibt die Aussagekraft gering. Ein Angreifer wechselt Werkzeuge schnell. Stabiler sind Erkennungen gegen Prozessketten, Rechteausweitung, ungewöhnliche Authentifizierung, Missbrauch legitimer Verwaltungsfunktionen und verdächtige Sequenzen. Tool-basierte Tests sind nützlich, aber nur als Mittel zum Zweck.

Ein weiterer Praxisfehler ist fehlende Abstimmung mit Betrieb und Infrastruktur. Dann werden Logs während der Übung gedrosselt, Agenten aktualisiert, Systeme neu gestartet oder Netzwerkpfade geändert, ohne dass das Purple-Team davon weiß. Die Folge sind falsche Schlussfolgerungen. Eine Detection scheint zu versagen, obwohl nur der Log-Forwarder ausgefallen ist. Oder eine Technik scheint blockiert, obwohl kurzfristig eine Policy geändert wurde. Saubere Übungen brauchen deshalb Change-Transparenz und einen klaren Kommunikationskanal, wie er in Communication und Collaboration organisatorisch verankert wird.

Schließlich scheitern viele Übungen an fehlender Nachverfolgung. Findings werden aufgenommen, aber nicht priorisiert, nicht umgesetzt und nicht erneut validiert. Purple Teaming ist kein einmaliger Termin, sondern ein iterativer Verbesserungsprozess. Wenn nach der Übung keine Retests stattfinden, bleibt unklar, ob die Organisation tatsächlich besser geworden ist. Genau deshalb sind Iteration, Reporting und belastbare Metriken unverzichtbar.

Ein belastbarer Purple-Teaming-Workflow beginnt nicht mit dem Angriff, sondern mit Scope, Hypothese und Erfolgskriterien. Zuerst wird definiert, welche Technik oder Angriffskette geprüft wird, welche Systeme betroffen sind, welche Sicherheitsgrenzen gelten und welche Telemetrie erwartet wird. Danach wird festgelegt, wer beobachtet, wer dokumentiert, wer Änderungen an Detection-Regeln vornehmen darf und wann ein Test abgebrochen werden muss. Diese Vorarbeit spart später Zeit und verhindert Diskussionen im laufenden Betrieb.

Die eigentliche Durchführung sollte in kontrollierten Schritten erfolgen. Statt eine komplette Kill Chain in einem Durchlauf auszuführen, ist es oft sinnvoller, einzelne Phasen getrennt zu testen. Zuerst Initial Access oder Execution, dann Discovery, dann Credential Access, dann laterale Bewegung. So lässt sich präzise erkennen, an welcher Stelle Sichtbarkeit fehlt. In reifen Teams werden diese Schritte zusätzlich mit einer Live-Beobachtung im SIEM oder EDR kombiniert, damit Blue Team und Detection Engineers sofort sehen, welche Daten tatsächlich ankommen.

Wichtig ist die Trennung zwischen Beobachtung und Verbesserung. Während der ersten Ausführung sollte möglichst wenig verändert werden, um den Ist-Zustand sauber zu messen. Erst danach folgen Anpassungen: neue Regeln, geänderte Logquellen, Tuning von Schwellenwerten, Ergänzung von Kontextdaten oder Härtungsmaßnahmen. Anschließend wird dieselbe Technik erneut ausgeführt. Nur so lässt sich nachweisen, dass die Verbesserung wirksam ist. Dieser Ablauf entspricht einem sauberen Prozess und einem realistischen Lifecycle.

Ein häufiger Streitpunkt ist die Frage, wie tief live optimiert werden darf. In produktiven Umgebungen ist Vorsicht sinnvoll. Detection-Regeln während einer laufenden Übung aggressiv zu verändern, kann Rauschen erzeugen oder andere Use Cases stören. Besser ist ein abgestufter Ansatz: Beobachtung, Entwurf der Verbesserung, Test in kontrollierter Form, Freigabe, Retest. Das ist langsamer, aber deutlich belastbarer.

Zur Workflow-Qualität gehört auch die technische Reproduzierbarkeit. Jede Aktion muss so dokumentiert sein, dass sie später erneut ausgeführt werden kann. Dazu zählen Befehle, Parameter, Hostkontext, Benutzerrechte, Zeitstempel, erwartete und tatsächliche Telemetrie sowie die genaue Regel oder Datenquelle, die geprüft wurde. Nur dann lassen sich Fortschritte über mehrere Iterationen hinweg messen.

In der Praxis bewährt sich ein Ablauf, der eng an Playbook, Dokumentation und Best Practices angelehnt ist. Nicht weil Formalismus Selbstzweck wäre, sondern weil saubere Wiederholbarkeit die Grundlage jeder technischen Verbesserung ist.

Gutes Reporting im Purple Teaming ist kein Management-Sammelbericht mit allgemeinen Aussagen. Es ist eine technische Arbeitsgrundlage. Ein Report muss so präzise sein, dass Detection Engineers, SOC-Analysten, Incident Responder und Systemverantwortliche daraus unmittelbar Maßnahmen ableiten können. Dazu gehört zuerst eine klare Beschreibung des getesteten Szenarios: Technik, Zielsysteme, Benutzerkontext, Vorbedingungen und Sicherheitsgrenzen.

Danach folgt die eigentliche Beweiskette. Für jede Aktion sollte dokumentiert werden, wann sie ausgeführt wurde, mit welchem Befehl oder Tool, auf welchem Host, mit welchem Ergebnis und welche Telemetrie dabei entstanden ist. Wenn ein Alert ausgelöst wurde, muss festgehalten werden, durch welche Regel, mit welchem Schweregrad, welcher Verzögerung und welchem Kontext. Wenn kein Alert ausgelöst wurde, ist das ebenso wichtig. Dann muss dokumentiert werden, welche Rohdaten vorhanden waren und warum daraus keine Erkennung entstand.

Ein praxistauglicher Report trennt sauber zwischen Beobachtung und Bewertung. Beobachtung bedeutet: Diese Events, Logs, Prozessketten und Netzwerkdaten wurden gesehen. Bewertung bedeutet: Die Sichtbarkeit war ausreichend, unzureichend oder irreführend. Gerade der letzte Punkt ist kritisch. Irreführende Detection ist gefährlicher als fehlende Detection, weil sie falsches Vertrauen erzeugt. Ein Alert, der zwar anschlägt, aber den falschen Host oder die falsche Ursache benennt, kann im Ernstfall wertvolle Zeit kosten.

Hilfreich ist eine tabellarische oder strukturierte Darstellung pro Technik. Ein Beispiel für die Mindesttiefe:

Technik: Remote Service Creation
Quelle: kompromittierter Client WS-17
Ziel: APP-SRV-03
Benutzerkontext: svc-backup
Zeitpunkt: 2026-04-02 10:14:33
Aktion: Dienst remote angelegt und gestartet
Erwartete Telemetrie:
- Authentifizierung auf Zielhost
- Service Creation Event
- Prozessstart auf Zielhost
- Netzwerkverbindung zwischen Quelle und Ziel
Tatsächliche Telemetrie:
- Authentifizierung sichtbar
- Service Creation sichtbar
- Prozessstart im EDR vorhanden, aber nicht im SIEM
- Kein korrelierter Alert
Bewertung:
- Teilweise Sichtbarkeit
- Fehlende zentrale Korrelation verhindert operative Erkennung
Maßnahme:
- EDR-Prozessdaten an SIEM anbinden
- Korrelation Auth + Service Creation + neuer Prozess auf Zielhost bauen
Retest geplant: ja

Ein solches Reporting ist direkt umsetzbar. Es zeigt nicht nur, dass etwas passiert ist, sondern warum die Verteidigung funktioniert oder versagt hat. Genau deshalb sind Reporting, Dokumentation und Metriken keine Nebenthemen, sondern Kernbestandteile professioneller Purple-Teaming-Arbeit.

Der Erfolg von Purple Teaming lässt sich nicht seriös mit der Anzahl getesteter Techniken messen. Entscheidend ist, ob die Organisation ihre Sichtbarkeit und Reaktionsfähigkeit nachweisbar verbessert. Dafür braucht es Metriken, die technisch belastbar sind und nicht nur Aktivität abbilden. Eine gute Metrik beantwortet Fragen wie: Wurde eine Technik erkannt? Wie schnell? Mit welchem Kontext? Auf welcher Datenbasis? Wie hoch war der manuelle Analyseaufwand? Wurde die Erkennung nach Tuning stabiler oder nur lauter?

Besonders nützlich sind Metriken entlang des Workflows. Dazu gehören Time to Detect, Time to Triage, Qualität der Kontextanreicherung, Anteil korrelierter statt isolierter Events, Abdeckung kritischer ATT&CK-Techniken, Wiederholbarkeit von Tests und Erfolgsquote von Retests nach Verbesserungen. Diese Kennzahlen müssen jedoch immer technisch interpretiert werden. Eine kurze Detektionszeit ist wertlos, wenn der Alert unpräzise ist. Eine hohe Abdeckung ist wertlos, wenn nur Standard-Tools erkannt werden.

Retests sind der eigentliche Härtetest. Viele Programme dokumentieren Maßnahmen, prüfen aber nie, ob sie unter realen Bedingungen funktionieren. Ein sauberer Retest verwendet möglichst dieselbe Technik, denselben Kontext und dieselben Erfolgskriterien wie der Ursprungstest. Nur dann lässt sich vergleichen, ob die Änderung tatsächlich Wirkung zeigt. Wenn sich gleichzeitig Logquellen, Agenten oder Policies geändert haben, muss das im Ergebnis berücksichtigt werden.

• Vorher-Nachher-Vergleich immer auf identischer oder bewusst vergleichbarer Testbasis durchführen
• Nicht nur Alert-Auslösung messen, sondern auch Kontextqualität und Analystenaufwand
• Verbesserungen gegen Umgehungsvarianten prüfen, um reine Signaturerfolge zu vermeiden
• Reifegrad nicht an Toolbestand, sondern an nachweisbarer Detection- und Response-Wirkung festmachen

Ein reifes Programm erkennt man daran, dass Ergebnisse in einen kontinuierlichen Verbesserungszyklus einfließen. Detection Engineering erhält präzise Anforderungen, das SOC bekommt angepasste Playbooks, Infrastrukturteams schließen Telemetrie-Lücken, und nach der Umsetzung folgt ein Retest. Genau diese Schleife macht den Unterschied zwischen einmaliger Übung und operativem Sicherheitsgewinn. Wer diesen Zyklus etablieren will, sollte Purple Teaming als festen Bestandteil von Und Threat Detection, Und Threat Hunting und Im Unternehmen verankern.

Am Ende zählt nicht, wie beeindruckend die Angriffssimulation war. Entscheidend ist, ob die Organisation nach mehreren Iterationen Angriffe früher sieht, präziser bewertet und schneller eindämmt. Genau daran misst sich echter Reifegrad.

Reale Purple-Teaming-Einsätze zeigen fast immer dasselbe Muster: Die größten Schwächen liegen selten in der fehlenden Existenz von Sicherheitswerkzeugen, sondern in unvollständiger Telemetrie, schwacher Korrelation, unklaren Zuständigkeiten und mangelnder Wiederholbarkeit. Ein EDR allein schafft keine belastbare Detection. Ein SIEM allein erzeugt keine sinnvollen Use Cases. Ein Red-Team-Szenario allein verbessert keine Verteidigung. Erst die disziplinierte Zusammenarbeit entlang eines klaren Workflows erzeugt verwertbare Ergebnisse.

Die wertvollsten Real-World-Beispiele sind deshalb nicht die spektakulärsten, sondern die präzisesten. Ein Office-Child-Prozess ohne zentrale Alarmierung, ein blockierter LSASS-Zugriff ohne Vorstufen-Erkennung, eine laterale Bewegung ohne Host-Korrelation oder ein Cloud-Rollenwechsel ohne Identitätskontext liefern oft mehr Sicherheitsgewinn als jede aufwendige Komplettsimulation. Sie zeigen konkret, wo Sichtbarkeit endet und wo Verbesserung ansetzen muss.

Sauberes Purple Teaming bedeutet, Angriffe kontrolliert zu emulieren, Telemetrie systematisch zu prüfen, Detection gezielt zu verbessern und Ergebnisse reproduzierbar zu dokumentieren. Dazu gehört auch die Bereitschaft, unbequeme Erkenntnisse zu akzeptieren: Manche Regeln funktionieren nur im Labor, manche Dashboards vermitteln falsche Sicherheit, manche Teams arbeiten mit guten Absichten, aber ohne gemeinsame Datengrundlage. Genau diese Realität muss sichtbar werden, wenn Purple Teaming mehr sein soll als ein technischer Workshop.

Wer den Ansatz strukturiert vertiefen will, sollte die Grundlagen in Purple Teaming, Was Ist Purple Teaming und Strategie mit operativen Themen wie Fehler und Detection Verbessern verbinden. Erst aus dieser Kombination entsteht ein Programm, das nicht nur testet, sondern die Verteidigungsfähigkeit messbar erhöht.

Real World Purple Teaming ist damit keine Marketing-Disziplin und kein Ersatz für andere Sicherheitsmaßnahmen. Es ist ein technischer Verbesserungsprozess unter realen Bedingungen. Genau deshalb liefert es dann den größten Nutzen, wenn sauber gearbeitet, präzise dokumentiert und konsequent nachgetestet wird.