Kurzfassung: Das Red Team simuliert einen echten Angreifer mit Auftrag und Ziel, ohne dass das Blue Team davon weiß; das Blue Team erkennt, reagiert und härtet; Purple Team ist die Arbeitsweise, in der beide gemeinsam Technik für Technik prüfen, ob die Erkennung greift, und sie sofort verbessern. Die richtige Reihenfolge: erst Pentests, dann regelmäßige Purple-Übungen, erst danach ein Red Team als Prüfung der Annahme, dass man einen Angriff bemerken würde.
Red Team greift an, Blue Team verteidigt, und das Purple Team? Ist keine dritte Mannschaft, sondern die Antwort auf ein altes Problem: Angriffssimulationen, deren Ergebnisse in einem Bericht verschwinden, statt die Erkennung zu verbessern. In diesem Beitrag erfährst du, was die drei Begriffe wirklich bedeuten, wie sich ein Red-Team-Einsatz von einem Pentest unterscheidet, wie eine Purple-Team-Übung Schritt für Schritt abläuft und welche der drei Übungsformen für deine Organisation gerade die richtige ist.
Red Team: der beauftragte Angreifer
Ein Red Team simuliert einen echten Angreifer, mit Auftrag, Regeln und Ziel. Der Auftrag kommt von der Geschäftsführung oder dem CISO, die Regeln (Rules of Engagement) legen fest, was erlaubt ist und was nicht, und das Ziel ist konkret: Zugriff auf die Kundendatenbank, Domain-Admin-Rechte, ein bestimmtes Fileshare. Der Weg dorthin ist frei. Phishing, gefälschte Anmeldeseiten, physischer Zugang, gestohlene Zugangsdaten, alles, was ein echter Angreifer auch tun würde.
Entscheidend: Das Blue Team weiß im Idealfall nichts vom Einsatz. Nur so lässt sich messen, ob und wann eine Erkennung greift. Das Ergebnis eines Red-Team-Einsatzes ist deshalb weniger eine Liste von Schwachstellen als eine Liste dessen, was unbemerkt blieb: Der Angreifer war zwei Wochen im Netz, hat sich über drei Systeme bewegt, und der erste Alarm kam an Tag zwölf.
Red Team ist nicht Pentest
Ein Penetrationstest prüft ein definiertes System auf Schwachstellen, so vollständig wie möglich, und liefert eine Liste mit Findings und Schweregraden. Ein Red Team prüft die Organisation als Ganzes gegen ein Ziel, so unauffällig wie möglich, und liefert eine Geschichte: So sind wir reingekommen, so weit sind wir gekommen, das habt ihr davon gesehen. Beides hat seinen Platz, aber es beantwortet verschiedene Fragen.
Blue Team: die Verteidigung
Das Blue Team ist alles, was erkennt, reagiert und härtet: SOC-Analysten, Incident Responder, Detection Engineers, Threat Hunter. Was es im Einzelnen tut, steht im Grundlagenartikel Was macht ein Blue Team?. Für diesen Beitrag reicht ein Punkt: Das Blue Team hat einen strukturellen Nachteil. Es muss jeden Angriff erkennen, der Angreifer braucht nur einen Weg, der nicht erkannt wird. Übungen sind die einzige Möglichkeit, diesen Nachteil zu verkleinern, bevor ein echter Angreifer ihn ausnutzt.
Purple Team: keine Farbe, sondern eine Arbeitsweise
Purple Team entsteht, wenn Rot und Blau nicht gegeneinander, sondern gleichzeitig und offen arbeiten. Der Red Teamer führt eine konkrete Technik aus, etwa das Auslesen von Anmeldedaten aus dem Speicher des LSASS-Prozesses. Der Blue Teamer sitzt daneben und prüft: Kommt das im SIEM an? Wenn ja, wie schnell und mit welchem Schweregrad? Wenn nein, welche Logquelle fehlt oder welche Regel greift nicht? Dann wird die Regel angepasst und die Technik erneut ausgeführt.
Der Unterschied zum Red Team liegt in der Rückkopplung. Ein Red-Team-Einsatz liefert einmal im Jahr eine Diagnose; eine Purple-Team-Übung liefert bei jeder Technik sofort eine Verbesserung. Das Purple Team Exercise Framework (PTEF) von SCYTHE hat das Vorgehen als offenen Standard beschrieben: Threat Intelligence liefert die Techniken, das Red Team führt sie aus, das Blue Team misst und verbessert, alles dokumentiert und mit einer abgestuften Bewertung von 0 bis 5 statt einem bloßen „erkannt“ oder „nicht erkannt“.
So läuft eine Purple-Team-Übung ab
- Bedrohung auswählen. Welche Angreifergruppen sind für deine Branche relevant? Aus Threat-Intelligence-Berichten ergibt sich eine Liste von Techniken, sortiert nach MITRE ATT&CK. Für einen Mittelständler in der Fertigung sieht die anders aus als für eine Bank.
- Techniken vorbereiten. Für jede Technik wird festgelegt, wie sie ausgeführt wird und welche Spuren sie erzeugen müsste. Frei verfügbare Testbibliotheken wie Atomic Red Team liefern für hunderte ATT&CK-Techniken fertige, kleine Tests, die sich kontrolliert ausführen lassen. Wie eine solche Übung Schritt für Schritt mit diesem Werkzeug abläuft, steht im Beitrag Purple-Team-Übung mit Atomic Red Team.
- Ausführen und beobachten. Der Red Teamer startet die Technik und sagt es an, der Blue Teamer schaut in SIEM, EDR und Logs. Das Ergebnis pro Technik ist eine von vier Stufen: nicht geloggt, geloggt aber kein Alarm, Alarm aber falsch eingestuft, korrekt erkannt und behandelt.
- Anpassen und wiederholen. Fehlt eine Logquelle, wird sie angebunden. Fehlt eine Regel, wird sie geschrieben. Dann läuft die Technik erneut. Erst wenn sie zuverlässig erkannt wird, kommt die nächste dran.
- Dokumentieren. Was wurde getestet, mit welchem Ergebnis, was wurde geändert. Diese Liste ist die ehrlichste Abdeckungskarte deiner Erkennung, die du bekommen kannst.
Übungsplan für einen Tag: fünf Techniken
Eine erste Purple-Team-Übung braucht keinen externen Dienstleister und keine Woche. Ein Tag, ein Besprechungsraum, ein Analyst mit Zugriff auf SIEM und EDR, ein Administrator oder Pentester, der die Tests ausführt, und ein Testsystem in der Domäne, das nach der Übung neu aufgesetzt wird. Die fünf Techniken decken die Phasen ab, die in fast jedem realen Angriff vorkommen, und jede hat einen fertigen Test in Atomic Red Team.
| Zeit | Technik | Was ausgeführt wird | Was das Blue Team sehen sollte |
|---|---|---|---|
| 09:00 | Vorbereitung | Regeln festlegen, Testsystem und Konto benennen, Snapshot, Uhrzeiten abgleichen, Bewertungsbogen öffnen | |
| 09:30 | T1059.001 PowerShell, kodierter Befehl | Eine PowerShell mit Base64-kodiertem Befehl, der eine Datei aus dem Internet lädt | 4688 mit Befehlszeile, Sysmon 1, PowerShell 4104 mit dem dekodierten Skript, Alarm auf -enc |
| 10:30 | T1003.001 Zugangsdaten aus LSASS | Speicherabbild des LSASS-Prozesses per Bordmittel, danach ein bekanntes Werkzeug | Sysmon 10 mit dem zugreifenden Prozess, EDR-Alarm mit Isolierung; bei beiden Varianten, nicht nur beim Werkzeug |
| 11:30 | T1053.005 Geplante Aufgabe | Aufgabe, die ein Skript aus dem Benutzerprofil bei Anmeldung startet | 4698 mit Aufgabeninhalt, Task-Scheduler 106, Alarm auf Skriptpfad im Benutzerverzeichnis |
| 13:30 | T1021.001 Seitliche Bewegung per RDP | RDP vom Testsystem zu einem zweiten Client mit einem Standardkonto | 4624 Typ 10 auf dem Ziel, TerminalServices 21, 4648 auf der Quelle, Alarm auf Client-zu-Client-RDP |
| 14:30 | T1558.003 Kerberoasting | Diensttickets für alle Dienstkonten mit SPN anfordern | 4769 mit RC4 in Serie auf dem Domain Controller, kerberos.log im Netzwerksensor, Alarm auf Schwelle |
| 15:30 | Nacharbeit | Bewertung abschließen, Regeln anpassen, zwei Techniken erneut ausführen, Testsystem zurücksetzen | |
| 16:30 | Abschluss | Ergebnisse in die Abdeckungskarte, Maßnahmen mit Verantwortlichen, Termin für die nächste Übung |
Pro Technik reicht eine Stunde: zehn Minuten Ausführung, zwanzig Minuten Suche in den Daten, zwanzig Minuten Bewertung und Anpassung, zehn Minuten Wiederholung. Wer nach der Mittagspause merkt, dass die erste Technik schon eine fehlende Logquelle offengelegt hat, streicht die letzte und bindet stattdessen die Quelle an; das ist kein Scheitern der Übung, sondern ihr Zweck.
Die Bewertung: von 0 bis 5
„Erkannt“ oder „nicht erkannt“ ist zu grob, weil zwischen einem Alarm, den niemand sieht, und einer automatischen Isolierung Welten liegen. Die Skala aus dem PTEF, leicht angepasst, macht den Unterschied sichtbar und im nächsten Quartal messbar:
| Stufe | Bedeutung | Beispiel | Nächster Schritt |
|---|---|---|---|
| 0 | Keine Telemetrie | Kerberoasting ausgeführt, kein 4769 im SIEM, weil die Domain Controller nicht angebunden sind | Logquelle anbinden |
| 1 | Geloggt, nicht gefunden | 4769 ist da, aber der Analyst hat es in der Suche nicht gefunden, weil das Feld für den Verschlüsselungstyp nicht geparst wird | Parser und Felder prüfen |
| 2 | Geloggt, per Suche gefunden | Mit der richtigen Abfrage sichtbar, aber keine Regel schlägt an | Regel schreiben |
| 3 | Alarm, falsch eingestuft oder zu spät | Regel greift, Alarm mit Stufe niedrig, erst nach 40 Minuten in der Warteschlange gesehen | Schweregrad und Bearbeitungsweg anpassen |
| 4 | Alarm, korrekt eingestuft und bearbeitet | Alarm mit Stufe hoch, Analyst eskaliert in zehn Minuten | Test im nächsten Quartal wiederholen |
| 5 | Automatisch unterbunden | EDR isoliert den Host beim LSASS-Zugriff, bevor das Abbild geschrieben ist | Prüfen, ob die Automatik auch bei der zweiten Variante greift |
Der Bewertungsbogen hat eine Zeile pro Technik und Variante, mit Stufe vorher, Stufe nachher, dem, was geändert wurde, und dem Verantwortlichen für die Maßnahme. Nach drei Quartalen zeigt er, ob die Erkennung wächst oder ob dieselbe Technik dreimal auf Stufe 2 stand, weil niemand die Regel geschrieben hat. Genau diese Tabelle ist der Bericht für die Geschäftsführung, und sie ist überzeugender als jeder Herstellerprozentsatz zur ATT&CK-Abdeckung.
Pentest, Red Team und Purple Team im Vergleich
| Kriterium | Pentest | Red Team | Purple Team |
|---|---|---|---|
| Leitfrage | Welche Schwachstellen hat System X? | Würde ein Angreifer sein Ziel erreichen, und würden wir es merken? | Erkennen wir Technik Y, und wie machen wir es besser? |
| Wissen des Blue Teams | meist informiert | nicht informiert | vollständig beteiligt |
| Ergebnis | Findings mit Schweregrad | Angriffspfad und Erkennungszeitpunkte | Abdeckungskarte und verbesserte Regeln |
| Dauer | Tage | Wochen | Tage, oder fortlaufend |
| Voraussetzung | keine | funktionierende Erkennung | ein SIEM oder EDR, in das man schauen kann |
Wann welche Übung sinnvoll ist
Die Reihenfolge, die viele Organisationen wählen, ist die falsche: Sie beauftragen ein Red Team, bevor eine Erkennung existiert. Das Ergebnis ist vorhersehbar, teuer und demotivierend: Der Angreifer war drin, niemand hat es gesehen. Das wusste man vorher auch.
Sinnvoller ist ein Aufbau in drei Stufen. Zuerst Pentests für die Systeme, die von außen erreichbar sind, damit die offensichtlichen Lücken geschlossen sind. Dann Purple-Team-Übungen, sobald ein SIEM oder EDR läuft, denn jetzt gibt es etwas, das man verbessern kann, und jede Übung macht die Erkennung messbar besser. Erst wenn das Blue Team davon ausgeht, dass es einen Angriff bemerken würde, ist ein Red Team die richtige Prüfung dieser Annahme. Purple-Übungen wiederholst du danach regelmäßig, etwa quartalsweise oder nach jeder größeren Änderung an der Infrastruktur, ein Red Team einmal im Jahr.
Typische Fehler
- Red Team als Zeugnis. Wird das Ergebnis als Versagen des Blue Teams gewertet statt als Lernstoff, blockt das Blue Team beim nächsten Mal, und die Übung verliert ihren Sinn.
- Purple ohne Dokumentation. Nach der Übung weiß niemand mehr, welche Techniken abgedeckt sind und welche nicht. Die Abdeckungskarte ist das eigentliche Produkt, nicht der Tag im Besprechungsraum.
- Indikatoren statt Verhalten. Den Hash der Testdatei blocken, statt das Verhalten zu erkennen. Beim nächsten Mal andere Datei, gleiches Verhalten, keine Erkennung.
- Einmal und nie wieder. Erkennung altert. Eine Regel, die heute greift, greift nach dem nächsten Agenten-Update oder der nächsten Log-Umstellung vielleicht nicht mehr. Ohne Wiederholung merkt es niemand, bis es darauf ankommt.
Fazit
Red Team und Blue Team beschreiben zwei Rollen, Purple Team beschreibt, wie beide zusammen am schnellsten lernen. Wer eine Erkennung aufbaut, fängt mit Purple an, weil jede Übung sofort eine Verbesserung liefert. Wer wissen will, ob diese Erkennung im Ernstfall hält, lässt sie von einem Red Team prüfen, das nichts ankündigt. Und wer die Ergebnisse beider Übungen ernst nimmt, statt sie abzuheften, hat den größten Teil der Arbeit schon getan.