Nach sechs Wochen verdecktem Angriff, nach Dutzenden Entscheidungen des Control Teams und einem Budget im mittleren fünfstelligen Bereich bleibt von einem Red Teaming genau ein Produkt übrig: der Bericht. Alles, was Ihre Organisation aus dem Einsatz lernt, muss durch dieses Dokument und die zugehörigen Workshops transportiert werden. Ein schlechter Bericht macht aus einem exzellenten Angriff eine Liste von CVE-Nummern, die in der Ablage verschwindet. Ein guter Bericht verändert, wie Vorstand, IT-Leitung und SOC über Sicherheit sprechen.
Wir haben in den vergangenen Jahren viele Berichte gelesen, die Unternehmen uns aus früheren Projekten gezeigt haben, und ein Muster erkannt: Die technische Qualität des Angriffs ist selten das Problem. Das Problem ist, dass der Bericht die falschen Fragen beantwortet. Er listet Schwachstellen, wo er Ursachen zeigen sollte; er beschreibt Werkzeuge, wo er Erkennungslücken benennen sollte; er richtet sich an Administratoren, wo er die Geschäftsführung erreichen müsste.
Dieser Beitrag beschreibt den Aufbau eines Red-Team-Berichts, der seinen Zweck erfüllt, stellt gute und schlechte Berichte gegenüber und gibt konkrete Hinweise, wie Sie die Ergebnisse vor Vorstand oder Aufsichtsrat präsentieren.
Drei Zielgruppen, ein Dokument
Ein Red-Team-Bericht wird von Menschen mit völlig unterschiedlichen Fragen gelesen. Die Geschäftsführung will wissen: Wie groß ist das Risiko, was kostet die Behebung, und sind wir besser oder schlechter als vergleichbare Unternehmen? Die IT-Leitung will wissen: Welche Systeme und Konfigurationen sind betroffen, in welcher Reihenfolge beheben wir was? Das SOC will wissen: Welche Schritte des Angriffs haben wir gesehen, welche nicht, und warum?
Ein guter Bericht bedient alle drei in getrennten Kapiteln, die jeweils eigenständig lesbar sind. Die Management Summary enthält keine Hostnamen; das Angriffs-Narrativ enthält keine Budgetempfehlungen; der Blue-Team-Teil setzt die Kenntnis der SIEM-Regeln voraus. Wer versucht, alles für alle zu schreiben, erreicht niemanden.
Aufbau eines guten Berichts
Management Summary
Ein bis zwei Seiten, geschrieben für Menschen ohne IT-Hintergrund. Sie beantwortet in dieser Reihenfolge: Welche Ziele wurden gesetzt, welche wurden erreicht, in welcher Zeit? Wurde der Angriff bemerkt, und was geschah dann? Welche drei bis fünf Ursachen haben den Angriff ermöglicht? Was muss zuerst getan werden, und was kostet es grob? Eine Gesamtbewertung auf einer verständlichen Skala schließt ab – ohne Zahlenspielerei, aber mit klarer Aussage.
Angriffs-Narrativ mit Timeline
Das Herzstück des Berichts erzählt den Angriff als Geschichte: vom Startpunkt über jede Rechteausweitung und jede Seitwärtsbewegung bis zur Zielerreichung. Jeder Schritt trägt einen Zeitstempel, das betroffene System, die verwendete Technik mit ihrer MITRE-ATT&CK-Kennung und die zugehörigen Indicators of Compromise. Entscheidend ist eine zusätzliche Spalte: Was hat die Verteidigung zu diesem Zeitpunkt gesehen? Die Gegenüberstellung von Angriffs- und Erkennungszeitleiste macht die Dwell Time konkret – nicht als Branchenstatistik, sondern als Ihre eigene Zahl.
Detection Gaps
Ein eigenes Kapitel listet jede Angriffsaktion, die nicht erkannt wurde, und ordnet die Ursache ein: Logquelle fehlt, Logquelle vorhanden aber nicht angebunden, Log vorhanden aber keine Regel, Regel vorhanden aber kein Alarm, Alarm vorhanden aber nicht bearbeitet. Diese Einordnung ist der direkte Arbeitsauftrag an Detection Engineering und SOC. Sie unterscheidet einen Red-Team-Bericht von einem Pentest-Bericht, der diese Dimension gar nicht kennt.
Findings mit Root Cause und Priorität
Jede ausgenutzte Schwachstelle oder Fehlkonfiguration erhält einen eigenen Eintrag mit Beschreibung, Nachweis, betroffenen Systemen, Schweregrad und Behebungsempfehlung. Der Unterschied zum Pentest-Bericht liegt in der Root-Cause-Analyse: Nicht „auf Server X fehlt Patch Y“, sondern „der Patch-Prozess erfasst Systeme außerhalb der Standardinventarisierung nicht“. Nicht „Dienstkonto Z hat Domain-Admin-Rechte“, sondern „es gibt keinen Prozess, der Berechtigungen von Dienstkonten regelmäßig überprüft“. Die CISA hat in ihrem Advisory AA23-059A ein Beispiel dokumentiert: Ein krbtgt-Passwort, das über zehn Jahre unverändert blieb, ist kein Konfigurationsfehler, sondern Ausdruck eines fehlenden Prozesses. Die Priorität richtet sich nach der Rolle im Angriffspfad: Ein mittelschweres Finding, das die gesamte Kette ermöglicht hat, steht vor einem kritischen Finding, das auf dem Weg zum Ziel keine Rolle spielte.
ATT&CK-Heatmap
Eine Matrix aller verwendeten Techniken, farblich markiert nach blockiert, erkannt, nur geloggt oder unentdeckt. Sie zeigt auf einer Seite, wo die Verteidigung stark ist und wo nicht, und bildet den Ausgangspunkt für den nächsten Purple-Teaming-Sprint. Als Zeitreihe über mehrere Einsätze hinweg ist sie das beste Instrument, um dem Aufsichtsrat Fortschritt zu zeigen.
Maßnahmenplan
Priorisierte Liste aller Maßnahmen mit Zuordnung zu Findings und Detection Gaps, grober Aufwandsschätzung, Zeithorizont (sofort, 90 Tage, 12 Monate) und Verantwortlichkeit nach Rolle. Der Plan unterscheidet zwischen Quick Wins, die Administratoren binnen Tagen umsetzen, und strukturellen Maßnahmen, die Budget und Projektorganisation brauchen. Für DORA-TLPT ist ein Remediation-Plan mit Root-Cause-Analyse ausdrücklich vorgeschrieben.
Blue-Team-Report
Nach Abschluss der aktiven Phase dokumentiert das Blue Team aus seiner Sicht, was es wann gesehen, wie es bewertet und was es unternommen hat – noch bevor es den Red-Team-Bericht kennt. Der Abgleich beider Berichte ist aufschlussreicher als jeder einzelne: Oft zeigt sich, dass Alarme ausgelöst, aber als Fehlalarm eingestuft wurden, oder dass das SOC den Angreifer sah, aber nicht die Befugnis hatte, einzugreifen.
Replay-Workshop
Der Replay-Workshop ist kein Anhang des Berichts, sondern sein wichtigster Teil. Red Team und Blue Team gehen die Angriffskette gemeinsam durch, Schritt für Schritt, und klären zu jedem Zeitpunkt: Was haben wir gesehen, was hätten wir sehen können, was ändern wir? Der Lerneffekt entsteht hier, nicht beim Lesen. Die DORA-RTS schreibt Replay und Purple Teaming binnen zehn Wochen nach der aktiven Phase vor; wir empfehlen das Format für jeden Einsatz.
Gute vs. schlechte Berichte
| Merkmal | Schlechter Bericht | Guter Bericht |
|---|---|---|
| Management Summary | Technische Zusammenfassung mit Hostnamen und CVE-Nummern | Geschäftsrisiko, Zielerreichung, drei Ursachen, Maßnahmen mit Kostenrahmen |
| Struktur | Schwachstellenliste nach Schweregrad sortiert | Angriffs-Narrativ mit Timeline, Findings nach Rolle im Angriffspfad |
| Erkennung | Nicht behandelt oder ein Satz („Der Angriff wurde nicht erkannt“) | Eigenes Kapitel Detection Gaps mit Ursachenklassifikation pro Schritt |
| Findings | Symptom und generische Empfehlung („Patch einspielen“) | Root Cause, Nachweis, Priorität nach Angriffspfad, konkrete Maßnahme |
| Zeitachse | Fehlt oder nur Projektdaten | Angriffs- und Erkennungszeitleiste mit Zeitstempeln nebeneinander |
| ATT&CK-Bezug | Fehlt oder Technik-IDs ohne Auswertung | Heatmap mit Erkennungsstatus, vergleichbar über Einsätze hinweg |
| Maßnahmen | Pro Finding eine Empfehlung, keine Priorisierung | Konsolidierter Plan mit Zeithorizont, Aufwand und Verantwortlichkeit |
| Sprache | Werkzeug- und Exploit-Namen, Abkürzungen ohne Erklärung | Verständlich für die jeweilige Zielgruppe, Fachbegriffe erklärt |
| Übergabe | PDF per E-Mail | Replay-Workshop mit Blue Team, Präsentation für die Geschäftsführung |
| Nachverfolgung | Keine | Retest-Angebot und Blue-Team-Report als Vergleichsbasis |
Praxis-Tipp: Fragen Sie den Anbieter vor Beauftragung nach einem anonymisierten Musterbericht und lesen Sie zuerst die Management Summary. Wenn Sie als Nicht-Techniker nach zwei Seiten nicht sagen können, wie groß das Risiko war und was zuerst zu tun ist, wird es Ihrem Vorstand genauso gehen. Prüfen Sie dann, ob der Bericht ein Kapitel zu Detection Gaps enthält – fehlt es, hat der Anbieter ein Red Teaming durchgeführt, aber einen Pentest-Bericht geschrieben.
Den Bericht im Vorstand präsentieren
Die Präsentation vor Geschäftsführung, Vorstand oder Aufsichtsrat entscheidet darüber, ob aus dem Bericht Budget und Handlung werden. Einige Regeln aus unserer Erfahrung:
- Mit dem Ziel beginnen, nicht mit der Methode. Der erste Satz lautet: „Das Red Team hatte den Auftrag, Zugriff auf die Zahlungsfreigabe zu erlangen. Das ist nach elf Arbeitstagen gelungen, unbemerkt.“ Nicht: „Wir haben ein Assumed-Breach-Szenario mit folgenden Rules of Engagement durchgeführt.“
- Die Timeline als Bild zeigen. Eine Zeitleiste mit den Angriffsschritten oben und den Erkennungsereignissen unten – oder deren Fehlen – erklärt in dreißig Sekunden, was ein Red Teaming misst. Markieren Sie die Stelle, an der der Angriff hätte gestoppt werden können.
- Drei Ursachen, nicht dreißig Findings. Fassen Sie die Findings zu den strukturellen Ursachen zusammen: fehlende Segmentierung, zu viele privilegierte Konten, Alarme ohne Bearbeitung. Jede Ursache bekommt eine Maßnahme und einen Kostenrahmen.
- Einordnen statt dramatisieren. Die mediane Dwell Time lag laut Mandiant M-Trends 2026 bei 14 Tagen, nur 52 Prozent der Vorfälle wurden intern erkannt. Wenn Ihr SOC den Angriff am dritten Tag bemerkt hat, ist das ein gutes Ergebnis, auch wenn das Ziel erreicht wurde. Sagen Sie das.
- Das Positive benennen. Jeder Einsatz zeigt auch, was funktioniert hat: ein Phishing-Versuch, der gemeldet wurde, eine Segmentierung, die einen Umweg erzwang, eine EDR-Regel, die ein Werkzeug stoppte. Diese Punkte gehören in die Präsentation, weil sie zeigen, wo frühere Investitionen gewirkt haben.
- Mit einer Entscheidung enden. Die letzte Folie enthält die Maßnahmen, die eine Entscheidung des Gremiums brauchen – Budget, Personal, Priorität gegenüber anderen Projekten – und einen Termin für den Retest, der den Fortschritt belegt.
Lassen Sie das Red Team bei dieser Präsentation anwesend sein. Fragen wie „Hätte ein echter Angreifer das auch geschafft?“ oder „Warum hat unser teures SOC das nicht gesehen?“ beantwortet derjenige am glaubwürdigsten, der den Angriff durchgeführt hat – und zwar sachlich, ohne die interne IT bloßzustellen. Ein gutes Red Team präsentiert Findings als Systemeigenschaften, nicht als persönliches Versagen.
Nach dem Bericht: Vom Dokument zur Veränderung
Der Bericht wirkt nur, wenn er in Prozesse überführt wird. Bewährt hat sich ein dreistufiger Rhythmus: Binnen 90 Tagen werden die Quick Wins umgesetzt und im Purple-Teaming-Sprint die Detection Gaps geschlossen. Binnen zwölf Monaten folgen die strukturellen Maßnahmen. Danach prüft ein Retest oder ein erneuter Einsatz, ob der ursprüngliche Angriffspfad verschlossen ist und ob die Erkennung die damals übersehenen Techniken heute meldet.
Die ATT&CK-Heatmap aus dem ersten Bericht wird dabei zur Vergleichsbasis. Wenn beim zweiten Einsatz dieselbe Matrix mehr Grün und weniger Rot zeigt und die Erkennungszeitleiste näher an die Angriffszeitleiste rückt, haben Sie einen Nachweis für den Aufsichtsrat, den keine Zertifizierung liefert: Die Organisation ist messbar widerstandsfähiger geworden.
Fazit
Ein Red-Team-Bericht ist dann gut, wenn er drei Zielgruppen getrennt bedient, den Angriff als Geschichte mit Zeitleiste erzählt, Erkennungslücken als eigenes Kapitel behandelt, Findings auf ihre Ursachen zurückführt und in einem priorisierten Maßnahmenplan mündet. Der Replay-Workshop und die Präsentation vor der Geschäftsführung sind kein Zusatz, sondern der Ort, an dem der Bericht Wirkung entfaltet. Fordern Sie vor Beauftragung einen Musterbericht an und prüfen Sie ihn gegen die Tabelle in diesem Beitrag. Wie unsere Berichte aufgebaut sind und wie wir den Replay-Workshop gestalten, zeigen wir Ihnen gern – Details finden Sie unter Red Teaming, oder Sie nehmen Kontakt auf.
Quellen
- Mandiant, M-Trends 2026 – mediane Dwell Time, Anteil intern erkannter Vorfälle
- CISA, Cybersecurity Advisory AA23-059A, 2023 – Root Causes eines Red-Team-Einsatzes, cisa.gov
- Delegierte Verordnung (EU) 2025/1190 (RTS zu TLPT) – Fristen für Red-Team-Report, Blue-Team-Report, Replay und Purple Teaming, eur-lex.europa.eu
- MITRE ATT&CK Enterprise, attack.mitre.org
Häufige Fragen zum Thema
Wie lang sollte ein Red-Team-Bericht sein?
Was ist der Unterschied zwischen Finding und Detection Gap?
Wann bekommen wir den Bericht?
Was ist ein Replay-Workshop?
Sollte der Bericht an den Vorstand weitergegeben werden?
Begriffe aus diesem Beitrag
Redaktion Gruppe RotDieser Beitrag wurde vom Red-Team von Gruppe Rot verfasst und fachlich geprüft. Er ersetzt keine Rechtsberatung. Zahlen und Quellen sind im Text genannt; bei Fragen oder Korrekturhinweisen freuen wir uns über eine Nachricht.