Purple Teaming beschreibt die enge Zusammenarbeit zwischen Red Team (Angreiferperspektive) und Blue Team (Verteidigerperspektive), um die Sicherheitslage eines Unternehmens gezielt und messbar zu verbessern. Techniken, Taktiken und Prozesse (TTPs) wie auch Erkenntnisse und Beobachtungen werden direkt und zeitnah geteilt. Die Ausrichtung der Übung soll sich an realen Bedrohungen orientieren, zum Beispiel an MITRE ATT&CK – Enterprise Techniques oder auch konkreten Threat-Actors. Ziel solcher Purple Team Projekte ist es das bereits vorhandene Sicherheitsdispositiv des Unternehmens nachweislich zu verbessern und möglich Lücken in der Überwachung und Reaktion aufzudecken.

Warum Purple Teaming? Ziele und Mehrwert

Purple Teaming ist vor allem dann wirksam, wenn es als Übung verstanden wird und nicht als Prüfung einzelner Teams. Eine der wichtigsten Grundlagen ist die Kooperation zwischen dem Red und Blue Team. Der Fokus liegt auf Detektions- und Response-Fähigkeiten entlang eines realistischen Angriffsflusses (Kill Chain) und/oder TTPs, inklusive sauberer Messbarkeit:

• Was wurde erkannt?
• Wie schnell?
• Mit welcher Qualität (Triage, Kontext, Eskalation, Containment)?

Ebenso zentral sind klar definierte Erfolgskriterien wie gewünschte Telemetrie, neue Detection Use Cases, Playbook-Verbesserungen, verkürzte Mean Time to Repair (MTTR), Scope- und Risk-Governance (Produktionsrisiken, Datenzugriffe, Freigaben), gemeinsames internes Vokabular definieren oder verbessern (TTP Mapping, Severity-Logik, Alert-Definitionen). Die Ziele sollten auf die Firma massgeschneidert werden und den aktuellen Reifegrad des IT-Sicherheitsdispositiv berücksichtigen. Typische Ziele könnten foglende sein:

• Sichtbarkeit und Detektion für definierte TTPs verbessern
• Time-To-Detect und Time-To-Respond prüfen und senken
• Mögliche Blindspots und Detection Gaps identifizieren und adressieren
• Prozess und Kontrollen validieren, funktioniert die Triage, das Incident-Handling, die Übergaben intern/extern? Funktionieren die eingesetzten Kontrollmechanismen wie MFA, Hardening und Block-/Allowlisting?

Ein weiterer Erfolgsfaktor ist die Balance zwischen Realismus und Lernkurve: Purple Teaming soll iterativ sein. So entsteht ein kontinuierlicher Verbesserungsprozess, bei dem Red und Blue Team nicht gegeneinander arbeiten, sondern gemeinsam das Sicherheitsdispositiv verbessern.

Während ein reines Red Teaming primär Schwachstellen demonstriert und ein Blue Teaming häufig reaktiv auf Alerts arbeitet, verbindet Purple Teaming beides zu einem messbaren Verbesserungszyklus

• Detection Engineering mit Realitätsbezug: Detection Use Cases können basierend auf echten TTPs und Kill Chains erstellt werden, anstatt generische Best-Practices-Listen abzuarbeiten
• Verbesserung der Telemetrie: Aufgrund der bereits zuvor definierten Umgebung oder Rahmenbedingungen kann schnell erkannt werden, ob wichtige Datenquellen fehlen
• Alert-Qualität: False Positives reduzieren und dabei den Kontext verbessern wie auch die Priorisierung und Korrelation
• Know-How Transfer und Kultur: Während des Projektes kann ein direkter Know-How-Transfer zwischen den Teams geschehen und Risiken, Machbarkeit wie auch möglicher Aufwand wird sichtbar gemacht

Stolpersteine

Da der Reifegrad der IT-Sicherheit in jeder Firma variiert, ist es wichtig, im Voraus transparent Ziele zu definieren und diese im Team (Red und Blue zusammen) zu besprechen, um bereits zu Beginn mögliche Stolpersteine zu adressieren. Gute Purple-Team-Übungen sind ziel- und messbarkeitsgetrieben. Es wird klar definiert, welche Kill Chain oder TTPs geprüft werden. Somit können keine falschen Erwartungshaltungen entstehen, und alle Beteiligten wissen, was getestet wird. Es ist wichtig, darauf zu achten, den Scope nicht zu gross anzusetzen und die Priorisierung danach nicht zu vernachlässigen. Es sollte eine zuvor definierte Kill Chain oder eine kleine Menge an TTPs, beispielsweise die Top Threats der eigenen Branche, adressiert werden. Während des Projekts können Re-Tests und wenn möglich bereits nachhaltige Gegenmassnahmen/Fixes erstellt werden. Dies ist natürlich nicht möglich, wenn die nötige Telemetrie und Datenqualität nicht vorhanden ist. Damit sind wir bereits beim dritten Stolperstein angelangt. Purple Teaming lohnt sich erst richtig, wenn saubere Datenquellen und Telemetrie vorhanden sind. Hierzu gehören alle Arten von fehlenden Logs, fehlenden Prozess- oder Netzwerkdetails bis hin zu zu kurzen Retention-Times von Daten. Wenn die Datenqualität und Telemetrie gegeben sind, muss anschliessend darauf geachtet werden, dass keine Silos entstehen. Oft ist trotz ausgerolltem EDR auf allen Clients, eingesetztem SIEM und definierten SOC-Prozessen das End-to-End-Ownership und somit die Zuständigkeiten nicht eindeutig geklärt.

Bestimmte TTPs könnten Systeme stören. Die Rahmenbedingungen müssen klar definiert werden. Hierzu gehören erlaubte Payloads, die Durchführung bestimmter Tests während Change- oder Maintenance-Windows sowie Rollback- oder sogar Failover-Pläne. Hier bietet es sich natürlich auch an, solche TTPs in einer Testumgebung zu prüfen oder sie in einem ersten Purple-Team-Projekt komplett auszuklammern. Zum Abschluss noch einer der grössten Stolpersteine einer Purple-Team-Übung: Keine saubere Dokumentation und fehlende Nacharbeit. Die vom Red Team eingesetzten Tools und Techniken müssen genau dokumentiert werden: Auf welchem System wurde mit welchem Benutzer zu welcher Uhrzeit welches Tool oder welche Technik ausgeführt oder gestartet? Diese Informationen müssen dem Blue Team zur Verfügung stehen, damit es bei der Nacharbeit den Mehrwert generieren kann. Detections können nochmals geprüft und bei Bedarf angepasst werden. Fehlende Datenquellen können identifiziert und adressiert werden. Playbooks können verbessert und Retests geplant werden.

Pyramid of Pain

Vor 13 Jahren hat David J. Bianco die Pyramid of Pain in einem Blogpost veröffentlicht und 2022 ein update dazu veröffentlicht. Er beschreibt wie viel schwieriger, oder eben schmerzhafter, es für Angreifer ist erfolgreich zu sein, wenn Verteidiger bestimmte Indikatoren erkennen und blockieren.

Diese Pyramide kann auch heute noch genutzt werden. Wir können versuchen unsere Ziele während des Projektes so zu wählen, um die Pyramide systematisch von trivial bis hin zu herausfordernd anzugehen.

Erste Ebene (Hashes, IPs, Domains) Volatile Indikatoren, durch neue Infrastruktur oder Hashes

• Werden solche IOCs sauber geloggt und verarbeitet (SIEM, Proxy, EDR)?
• Wie schnell werden diese detektiert und wie lange geht es, bis diese geblockt werden, ist dies automatisiert oder muss es von einem SOC-Mitarbeiter manuel bearbeitet werden?
• Wieviele und was für False Positives entstehen?

Mittlere Ebene (Artefakte) Muster, Anomalien oder böswillige Aktivitäten auf einem oder mehreren Hosts

• Prozessketten, Registry-Änderungen, ungewöhnliche Prozesse identifizierbar?
• Bekannte, möglicherweise böswillige Dateien oder Verzeichnisse an bestimmten Orten auf dem Client?
• Anomalien der laufenden Dienste oder neue, nicht bekannte Dienste?

Oberste Ebene (TTPs) Tools aber auch Techniken (Credential Dumping, Privilege Escalation, Lateral Movement), wenn die Tools ändern

• Kann die Technik und nicht das Tool erkannt werden? Wenn ein anderes Tool eingesetzt wird?
• Sind passende Response-Verfahren vorhanden, wurden diese geprüft und können diese eingesetzt werden, beispielsweise Client Isolation oder Token-Revocation?
• Hierbei geht es um das gesamte Vorgehen eines Angreifers, von Reconnaissance bis hin zu der Exfiltration oder Zerstörung/Verschlüsselung von Daten

Der primäre Fokus eines Purple Team sollte sich auf die mittleren bis oberen Ebenen konzentrieren. Die Verteidigung wird verbessert und auf Verhaltensmuster und Taktiken/Techniken ausgerichtet oder erweitert.

Automatisierung und Purple-Teaming-Tools

Für saubere, gut vorbereitete und strukturiert durchgeführte Purple-Team-Übungen sind genügend Ressourcen erforderlich. Benötigt werden ein Red Team (intern oder extern), ein Blue Team sowie aktuelle IT-Systeme und deren Überwachung. Auch die Planungsphase, Dokumentation, Testing und alles, was dazugehört, können ressourcenintensiv werden. Deshalb wäre es naheliegend, Tools oder eine Automatisierung einzusetzen, um beispielsweise den technischen Test oder einen Teil davon zu automatisieren. Es gibt eine Vielzahl an Tools, die jedoch meistens kein gesamtes Purple-Team-Protokoll in kurzer Zeit automatisieren können.

Ein Beispiel ist Atomic Red Team, eine Open-Source-Bibliothek von Tests, um die eingesetzten Sicherheitsmechanismen zu prüfen. Die Tests sind gemäss MITRE ATT&CK Techniques abgebildet und zugewiesen. Wenn beispielsweise geprüft werden soll, ob neue Detection Rules oder SOC-Use-Cases bei der Technik OS Credential Dumping anschlagen, kann mithilfe der T-Nummer von MITRE, in diesem Fall wäre das T1003, ein passender Test ausgewählt und ausgeführt werden. Als Voraussetzung gilt wie bei allen Tests, das Bewusstsein und das Verständnis muss vorhanden sein bezüglich was ausgeführt oder heruntergeladen wird. Es ist unerlässlich, eine Prüfung der auszuführenden Scripts oder Tools durchzuführen. Das Clean Source Principal darf nicht vernachlässigt werden. Einige Tests dieser Open-Source-Bibiliotheken verwenden den PowerShell Befehl Invoke-WebRequest um ein weiteres Tool oder DLL-Dateien herunterzuladen, die wir nicht in einer produktiven Umgebung haben möchte. Es gibt auch Anbieter, die Purple-Team-Projekte als automatisierte Dienstleistung in Form von Tools oder Ähnlichem anbieten. Auch hier gilt wieder das Clean Source Principal, wenn sich eine Firma dafür entscheidet, ein solches Tool einzusetzen, vertraut sie dem Anbieter und dessen Tools. Alternativ setzt sie ein Code-Review der eingesetzten Tools voraus, was die durch einen solchen Dienst erzielte Einsparung von Ressourcen aber mit höchster Wahrscheinlichkeit zunichtemacht.

Zusammenfassung

Purple Teaming ist eine sehr effektive Methode, um Security nicht nur zu testen, sondern nachweislich zu verbessern. Durch enge Zusammenarbeit von Red und Blue Team, realitätsnahe TTP-Auswahl, schnelle Feedback-Loops und klare Messkriterien kann das bereits vorhandene Sicherheitsdispositiv geprüft und weiter ausgebaut werden. Die grössten Stolpersteine liegen selten in der Technik selbst, sondern in Scope, Telemetrie, Zuständigkeiten, Governance und fehlender Nacharbeit. Die Pyramid of Pain bietet ein nützliches Denkmodell: Purple Teaming hilft, Detektionen von fragilen IOCs hin zu verhaltens- und technikbasierten Erkennungen zu verschieben – wo es für Angreifer wirklich teuer wird. Tools und Automatisierung können Purple Teaming skalieren und Regressionen sichtbar machen. Der nachhaltige Mehrwert entsteht jedoch erst durch saubere Dokumentation, Reviews, kontinuierlicher weiterentwicklung von Detection Rules und Use-Cases, deren Prozessverbesserungen und konsequente ReTests und Validierung.

Über den Autor

Eric Maurer hat eine IT-Ausbildung im Finanzsektor absolviert und konnte danach Erfahrungen in den Rollen Administrator, Engineer und Consultant sammeln. Dabei war er involviert in Entwicklung, Aufbau und Betrieb eines Enhanced Security Administrative Environment und dem internationalen Rollout von Active Directory Services. Zudem hat er Erfahrung mit Microsoft Entra ID mit Fokus auf Security.

Links

• https://attack.mitre.org/techniques/T1003/
• https://attack.mitre.org/techniques/enterprise/
• https://detect-respond.blogspot.com/
• https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
• https://github.com/redcanaryco/atomic-red-team
• https://github.com/redcanaryco/atomic-red-team/tree/master/atomics/T1003
• https://specterops.io/blog/2025/10/08/the-clean-source-principle-and-the-future-of-identity-security/
• https://vuldb.com/?actor
• https://www.atomicredteam.io
• https://www.scip.ch/?defense
• https://www.scip.ch/?labs.20220407
• https://www.scip.ch/?labs.20241114
• https://www.scip.ch/?offense
• https://x.com/DavidJBianco