Pentesting Red Team: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Red Teaming ist keine bloße Sammlung aggressiver Techniken, sondern eine kontrollierte Angriffssimulation mit klar definiertem Zielbild. Der Unterschied zum klassischen Schwachstellentest oder zu einem standardisierten Infrastruktur-Pentest liegt vor allem in der Perspektive. Ein normaler Pentest sucht systematisch nach Schwachstellen innerhalb eines vereinbarten Scopes und bewertet deren Ausnutzbarkeit. Ein Red Team hingegen arbeitet zielorientiert, verdeckt, adaptiv und häufig über mehrere Angriffsphasen hinweg. Nicht jede Schwachstelle ist relevant. Relevant ist, ob ein realistischer Angreifer mit vertretbarem Aufwand ein definiertes Ziel erreicht.

Typische Ziele sind der Zugriff auf sensible Daten, die Übernahme kritischer Identitäten, die Kompromittierung eines Active Directory, die Umgehung von Überwachungsmechanismen oder der Nachweis, dass Segmentierung und Schutzmaßnahmen in der Praxis nicht tragen. Damit bewegt sich Red Teaming näher an realen Angreifer-Workflows als ein rein technischer Einzeltest. Wer die Grundlagen des strukturierten Testens vertiefen will, sollte die Methodik aus Pentesting Grundlagen, den Gesamtprozess aus Pentesting Ablauf und die operative Umsetzung aus Pentesting Durchfuehrung sauber beherrschen.

Ein häufiger Denkfehler besteht darin, Red Teaming mit maximaler Heimlichkeit gleichzusetzen. Heimlichkeit ist nur ein Mittel, nicht das Ziel. Wenn das Ziel lautet, die Wirksamkeit von Detection und Response zu prüfen, dann ist es oft sinnvoll, bestimmte TTPs bewusst sichtbar zu machen, um Reaktionsketten zu messen. Wenn das Ziel dagegen die Validierung von Schutzannahmen gegen einen unentdeckten Angreifer ist, dann wird OPSEC deutlich wichtiger. Die Zieldefinition bestimmt also Technik, Tempo, Kommunikationsmodell und Erfolgskriterien.

Red Teaming ist außerdem kein Freifahrtschein für unkontrollierte Kreativität. Ohne belastbare Regeln entstehen unnötige Betriebsrisiken. Ein professionelles Red Team arbeitet mit klaren Freigaben, Eskalationswegen, Abbruchkriterien und technischen Guardrails. Gerade in produktiven Umgebungen ist das entscheidend, weil viele Angriffswege nicht nur Datenzugriff, sondern auch Instabilität verursachen können. Das betrifft etwa Authentifizierungsdienste, Legacy-Systeme, industrielle Netze, E-Mail-Infrastrukturen oder produktionsnahe Datenbanken.

In der Praxis ist Red Teaming besonders wertvoll, wenn Organisationen bereits ein gewisses Reifegradniveau erreicht haben. Wer noch keine belastbaren Grundlagen in It Security Grundlagen, keine klare It Security Sicherheitsarchitektur und kein funktionierendes Monitoring besitzt, profitiert oft zunächst stärker von klassischen Pentests, Hardening und Detection-Basisarbeit. Red Teaming entfaltet seinen Wert dort, wo nicht nur Schwachstellen gefunden, sondern Annahmen über Verteidigung, Prozesse und Reaktionsfähigkeit realitätsnah geprüft werden sollen.

Die Qualität eines Red-Team-Einsatzes steht und fällt mit der Vorbereitungsphase. Technische Exzellenz kompensiert keine unklare Zielsetzung. Wenn Auftraggeber nur formulieren, dass ein realistischer Angriff simuliert werden soll, ist das zu unscharf. Ein Red Team braucht ein präzises Missionsziel. Beispiele: Zugriff auf ein bestimmtes ERP-System, Exfiltration definierter Datensätze, Erlangung von Domain-Admin-Rechten, Umgehung von EDR auf ausgewählten Endpunkten oder Nachweis eines Pfades von externem Zugang bis zu einem Kronjuwel.

Der Scope muss nicht nur Systeme, sondern auch Handlungsräume definieren. Darf Social Engineering eingesetzt werden? Sind Phishing-Kampagnen erlaubt? Ist physischer Zugang Teil des Szenarios? Dürfen Cloud-Ressourcen aktiv angegriffen werden? Sind produktive Benutzerkonten tabu? Welche Systeme gelten als No-Go, etwa medizinische Geräte, OT-Komponenten oder hochsensible Datenbanken? Solche Fragen gehören vor den ersten technischen Schritt. Die rechtliche und organisatorische Absicherung ist dabei kein Nebenthema, sondern Pflicht. Dazu gehören belastbare Freigaben, Ansprechpartner und ein gemeinsames Verständnis der Grenzen, wie es auch in Pentesting Legal und Pentesting Ethik behandelt wird.

Ein professionelles Rules-of-Engagement-Dokument beantwortet mindestens folgende Punkte:

• Welche Ziele sind erlaubt, welche Systeme sind ausgeschlossen und welche Daten dürfen niemals berührt oder exfiltriert werden.
• Welche Angriffsmittel sind zulässig, etwa Phishing, Passwort-Spraying, Exploitation, Cloud-Missbrauch oder physische Tests.
• Wie laufen Eskalation, Notfallkommunikation, Abbruch und Freigaben bei kritischen Funden oder Betriebsrisiken ab.

Besonders wichtig ist die Definition von Erfolg. Ein Red Team muss wissen, wann ein Ziel als erreicht gilt. Reicht der Nachweis eines möglichen Zugriffs? Muss ein Token extrahiert werden? Ist ein Screenshot ausreichend oder wird ein kontrollierter Datenzugriff verlangt? Ohne diese Präzision entstehen später Diskussionen, ob ein Angriffspfad wirklich valide war. In reifen Umgebungen werden Erfolgskriterien oft an geschäftlichen Auswirkungen ausgerichtet, nicht nur an technischen Privilegien.

Ein weiterer kritischer Punkt ist das Kommunikationsmodell. Bei verdeckten Übungen kennt oft nur ein kleiner Kreis den Einsatz. Das erhöht die Realitätsnähe, birgt aber Risiken. Wenn das SOC einen Vorfall korrekt eskaliert, darf der Einsatz nicht durch fehlende interne Abstimmung zu unnötigen Krisenreaktionen führen. Deshalb braucht es White-Cell-Strukturen: wenige autorisierte Personen, die den Einsatz kennen, Risiken bewerten und im Notfall eingreifen können. Diese Trennung zwischen operativer Geheimhaltung und organisatorischer Kontrolle ist ein Kernmerkmal sauberer Red-Team-Arbeit.

Gute Red Teams starten nicht mit Exploits, sondern mit Hypothesen. Welche Eintrittspunkte sind für diese Organisation plausibel? Welche Identitäten sind attraktiv? Welche extern sichtbaren Dienste, Partnerbeziehungen, Cloud-Assets oder Mitarbeiterprofile deuten auf verwertbare Pfade hin? Recon ist dabei nicht nur OSINT, sondern die systematische Reduktion von Unsicherheit. Ziel ist nicht, möglichst viele Daten zu sammeln, sondern die richtigen Annahmen zu bilden.

Ein typischer Fehler unerfahrener Teams ist das Überbewerten technischer Scans und das Unterbewerten organisatorischer Informationen. Stellenanzeigen verraten eingesetzte Technologien. Zertifikatstransparenz zeigt Subdomains. DNS-Metadaten, Git-Repositories, Dokument-Metadaten, Login-Portale, VPN-Gateways und Cloud-Endpunkte liefern Hinweise auf die Angriffsfläche. Wer die externe Sicht sauber aufbaut, arbeitet deutlich effizienter als ein Team, das blind mit Standard-Scannern startet. Für die Einordnung solcher Flächen sind It Security Attack Surface und It Security Angriffsvektoren eng mit Red-Team-Planung verbunden.

Recon muss immer mit einer Priorisierung enden. Nicht jede gefundene Oberfläche ist ein sinnvoller Einstieg. Ein altes Webportal mit geringer Reichweite kann weniger wertvoll sein als ein modernes SSO-Portal mit schwacher Passwortpolitik oder ein Cloud-Service mit fehlerhafter Rollenvergabe. In vielen realen Einsätzen sind Identitäten der schnellste Weg zum Ziel. Deshalb werden Informationen über Authentifizierungsverfahren, Passwort-Reset-Prozesse, MFA-Ausnahmen, Legacy-Protokolle und administrative Workflows besonders hoch gewichtet.

Ein praxisnaher Planungsansatz arbeitet mit Angriffshypothesen. Beispiel: Externer Zugriff über OWA oder VPN ist möglich, weil Passwort-Spraying gegen wenige privilegierte Konten nicht ausreichend erkannt wird. Oder: Ein Entwickler-Subdomain liefert Zugang zu Build-Artefakten, aus denen Secrets extrahiert werden können. Oder: Eine Cloud-Fehlkonfiguration erlaubt das Auslesen von Metadaten und den Pivot in interne Ressourcen. Jede Hypothese bekommt Indikatoren, Prüfmethoden, Risikobewertung und Abbruchkriterien.

Red Teaming profitiert hier stark von Bedrohungsmodellen. Wer TTPs an reale Gegnerprofile anlehnt, testet nicht nur Technik, sondern auch Verteidigungsannahmen. Ein Angriff, der nur mit exotischen Zero-Days funktioniert, hat oft weniger praktischen Wert als ein Pfad über schwache Identitäten, Fehlkonfigurationen und unzureichende Segmentierung. Genau diese Kombinationen sind in Unternehmensumgebungen häufig entscheidend. Die Verbindung zu It Security Threat Modeling und It Security Mitre Attack ist deshalb operativ relevant, nicht nur konzeptionell.

Ein sauberer Recon-Prozess endet mit einem Operationsplan, der mehrere Pfade enthält: Primärpfad, Alternativpfad, Fallback bei Detection und definierte Stop-Punkte. Das verhindert Aktionismus. Wer ohne Plan in die Durchführung geht, verbrennt schnell Infrastruktur, erzeugt unnötige Alarme und verliert die operative Kontrolle.

Initial Access ist die Phase, in der sich Professionalität besonders klar zeigt. Viele Teams verschwenden Zeit mit spektakulären, aber unplausiblen Einstiegen. In realen Unternehmensumgebungen dominieren meist wenige Kategorien: Identitätsangriffe, externe Fehlkonfigurationen, Web-Einstiege, schwache Remote-Zugänge, Cloud-Missbrauch und Social Engineering. Die Frage lautet nicht, was technisch möglich ist, sondern was unter den gegebenen Rahmenbedingungen glaubwürdig, risikoarm und zielgerichtet ist.

Bei externen Angriffsflächen beginnt die Arbeit oft mit einer präzisen Validierung erreichbarer Dienste. Ein VPN-Gateway, ein Citrix-Portal, ein OWA-Login oder ein SSO-Frontend sind nicht nur Login-Seiten, sondern Kontrollpunkte für Passwortpolitik, MFA-Ausnahmen, Lockout-Verhalten und Telemetrie. Passwort-Spraying kann in einem Red-Team-Szenario legitim sein, wenn Frequenz, Zielkonten und Abbruchkriterien sauber definiert sind. Der Unterschied zwischen professionellem Vorgehen und blindem Lärm liegt in der Disziplin: wenige Kandidaten, kontrollierte Zeitfenster, genaue Beobachtung von Reaktionen und sofortiger Stopp bei unerwarteten Effekten.

Webbasierte Einstiege sind ebenfalls häufig, aber nicht im Stil eines wahllosen Scanner-Laufs. Ein Red Team prüft gezielt, ob ein Webdienst als Brücke in interne Systeme taugt. Eine SSRF in einem Backend mit Cloud-Metadatenzugriff ist operativ oft wertvoller als eine reflektierte XSS ohne Folgepfad. Eine Authentifizierungslogik mit schwachen Recovery-Prozessen kann mehr bringen als eine isolierte Informationspreisgabe. Für diese Phase sind Kenntnisse aus Websecurity Pentesting, Websecurity Ssrf und Websecurity Authentication besonders relevant.

Auch Phishing wird häufig missverstanden. Ein Red Team verschickt nicht einfach generische Mails und zählt Klicks. Ziel ist ein realistischer, kontrollierter Zugangspfad. Das kann ein Device-Enrollment, ein Token-Diebstahl, ein Reverse-Proxy-Angriff auf Authentifizierung oder die Gewinnung eines initialen Benutzerkontexts sein. Entscheidend ist, dass das Szenario zur Organisation passt und nicht nur Awareness testet. Wenn das Ziel technische Wirksamkeit ist, muss die Kampagne an reale Prozesse andocken, etwa Dokumentfreigaben, HR-Kommunikation, Projektplattformen oder interne Support-Abläufe.

In Cloud-Umgebungen verschiebt sich Initial Access oft von klassischer Exploitation zu Identitäts- und Konfigurationsmissbrauch. Öffentlich erreichbare Storage-Buckets, schwache IAM-Rollen, geleakte Access Keys oder falsch konfigurierte CI/CD-Pipelines sind operative Goldminen. Wer Red Teaming in hybriden Umgebungen betreibt, muss deshalb klassische Infrastruktur, Web, Identity und Cloud zusammen denken. Ein isolierter Blick auf nur eine Domäne führt fast immer zu unvollständigen Angriffspfaden.

Ein sauberer Einstieg ist nicht der lauteste, sondern derjenige mit dem besten Verhältnis aus Plausibilität, Zielnähe und Kontrollierbarkeit. Genau daran scheitern viele Einsätze: zu frühe Eskalation, zu viele parallele Versuche, zu wenig Hypothesenprüfung und zu geringe Rücksicht auf Detection-Telemetrie.

Nach dem ersten Zugriff trennt sich improvisiertes Vorgehen von echter Operationsdisziplin. Post-Exploitation bedeutet nicht, wahllos Tools auszuführen, Speicher zu dumpen und Hosts zu scannen. Jeder Schritt erzeugt Spuren, verändert Zustände und kann Detection auslösen. Ein professionelles Red Team priorisiert deshalb Informationsgewinn mit minimalem Fußabdruck. Zuerst wird geklärt, in welchem Kontext der Zugriff besteht: Benutzerrechte, Host-Rolle, Netzwerkposition, vorhandene Sicherheitskontrollen, erreichbare Identitäten und potenzielle Pivot-Pfade.

Privilege Escalation ist nur dann sinnvoll, wenn sie einen echten Mehrwert bringt. Lokale Administratorrechte auf einem isolierten Arbeitsplatz sind weniger wert als Zugriff auf ein Servicekonto mit weitreichenden Rechten. In Windows-dominierten Umgebungen sind Fehlkonfigurationen in Diensten, geplanten Tasks, Token-Rechten, lokalen Gruppen oder unsicheren Anmeldedatenablagen oft relevanter als exotische Kernel-Exploits. In Linux-Umgebungen spielen sudo-Regeln, Dateiberechtigungen, Capabilities, Cronjobs, Container-Kontexte und falsch gesetzte Secrets eine große Rolle. Wer diese Pfade systematisch beherrscht, arbeitet effizienter als Teams, die sofort nach lauten Exploits suchen.

Lateral Movement ist kein Selbstzweck. Jeder Pivot muss begründet sein: näher ans Ziel, bessere Identität, höherer Vertrauenskontext oder Zugang zu Management-Ebenen. Besonders wertvoll sind Systeme, auf denen Administratoren interaktiv arbeiten, Jump Hosts, Management-Server, Backup-Systeme, CI/CD-Komponenten und Identitätsdienste. In vielen Umgebungen ist nicht der Domain Controller der erste sinnvolle Schritt, sondern ein System, auf dem privilegierte Sessions, Tokens oder Konfigurationsartefakte zusammenlaufen. Für diese Phase sind Endpoint Security Privilege Escalation, Endpoint Security Lateral Movement und Pentesting Active Directory besonders praxisnah.

Ein häufiger Fehler ist das unkontrollierte Credential Harvesting. Nur weil ein Speicher-Dump technisch möglich ist, ist er nicht automatisch operativ sinnvoll. Manche Methoden sind hochgradig detektierbar, andere destabilisieren Prozesse oder verletzen unnötig Scope-Grenzen. Besser ist ein abgestufter Ansatz: erst vorhandene Kontexte auswerten, dann Konfigurationsdaten, dann Tokens, dann nur bei echtem Bedarf invasive Methoden. Das reduziert Risiko und verbessert die Nachvollziehbarkeit.

In dieser Phase sind drei Prinzipien entscheidend:

• Jeder Schritt braucht einen klaren Zweck, etwa Identitätsgewinn, Netzwerkerweiterung oder Zielannäherung.
• Jede Aktion wird auf Detektionswahrscheinlichkeit, Betriebsrisiko und Rückverfolgbarkeit bewertet.
• Jeder Pivot wird dokumentiert, damit Angriffspfad, Ursache und Verteidigungslücke später belastbar rekonstruiert werden können.

Gerade in Active-Directory-Umgebungen entstehen die wertvollsten Erkenntnisse selten durch einzelne Schwachstellen, sondern durch Ketten: schwache Delegation, überprivilegierte Gruppen, ungeschützte Servicekonten, fehlende Tiering-Trennung, unzureichende Segmentierung und mangelhafte Überwachung. Red Teaming macht diese Ketten sichtbar. Genau darin liegt der Mehrwert gegenüber isolierten Einzelbefunden.

Operational Security ist im Red Teaming kein Zusatzthema, sondern Teil der Kernarbeit. Viele Einsätze scheitern nicht an fehlender Exploit-Fähigkeit, sondern an schlechter Infrastruktur, vorhersagbaren Mustern und unnötig lauten Aktionen. Wer dieselben Standard-Profile, bekannte Artefakte, auffällige Beacon-Intervalle oder schlecht getarnte Redirector-Ketten nutzt, wird in reifen Umgebungen schnell erkannt. Moderne Verteidigung arbeitet nicht nur signaturbasiert, sondern korreliert Verhalten, Prozessketten, Netzwerkziele, Authentifizierungsanomalien und Identitätsmissbrauch.

Saubere Red-Team-Infrastruktur beginnt mit Trennung. Redirector, Teamserver, Payload-Hosting, Phishing-Domains und Kollaborationssysteme dürfen nicht unkontrolliert vermischt werden. DNS, TLS, Zertifikate, Domain-Alter, Hosting-Merkmale und Netzwerkpfade müssen zum Szenario passen. Schlechte Infrastruktur verrät sich oft schon vor dem ersten erfolgreichen Zugriff. Ebenso kritisch ist das Timing. Wenn ein Team in kurzer Zeit mehrere Hosts mit identischen Mustern anspricht, erzeugt es Korrelationen, die jedes gute SOC nutzen kann.

OPSEC betrifft aber nicht nur externe Infrastruktur, sondern auch das Verhalten auf kompromittierten Systemen. Prozess-Injection, Speicherzugriffe, LSASS-nahe Aktivitäten, verdächtige Parent-Child-Beziehungen, ungewöhnliche PowerShell-Nutzung, WMI-Muster oder Remote-Service-Erstellung sind klassische Telemetriequellen. Ein Red Team muss wissen, welche Aktionen in welcher Umgebung typischerweise sichtbar werden. Das setzt Erfahrung mit Endpoint Security Edr, Security Monitoring Siem und It Security Detection Engineering voraus.

Ein häufiger Anfängerfehler ist das Verwechseln von Tool-Erfolg mit Operations-Erfolg. Ein Befehl kann technisch funktionieren und trotzdem operativ schlecht sein, weil er einen hochqualitativen Alarm erzeugt. Umgekehrt kann ein langsamerer, manuellerer Weg deutlich wertvoller sein, weil er unauffällig bleibt. Gute Teams denken deshalb in Telemetrie, nicht nur in Kommandos. Sie fragen vor jeder Aktion: Welche Events entstehen? Welche Korrelationen sind wahrscheinlich? Welche Alternativen erzeugen weniger Sichtbarkeit?

Auch Artefaktmanagement ist zentral. Temporäre Dateien, Registry-Spuren, Prefetch, Event Logs, Shell-History, Browser-Artefakte, geplante Tasks, Services und Netzwerkverbindungen hinterlassen Muster. Nicht jede Spur lässt sich oder sollte sich entfernen. Das Ziel ist nicht forensische Unsichtbarkeit um jeden Preis, sondern kontrollierte Exposition. In manchen Übungen ist gerade die Sichtbarkeit bestimmter TTPs gewünscht, um die Verteidigung zu messen. Dann muss aber bewusst entschieden werden, welche Spuren akzeptiert werden und welche nicht.

Wer Red Teaming ernsthaft betreibt, braucht deshalb ein enges Verständnis für Verteidigerperspektiven. Die Brücke zu Pentesting Blue Team und Pentesting Purple Team ist keine organisatorische Formalität, sondern operative Notwendigkeit. Nur wer weiß, wie Detection entsteht, kann sinnvoll entscheiden, wann Heimlichkeit, wann Sichtbarkeit und wann kontrollierte Provokation der bessere Weg ist.

Ein Red-Team-Einsatz ist dann besonders wertvoll, wenn er nicht in einer isolierten Erfolgsmeldung endet, sondern Verteidigungsfähigkeit messbar verbessert. Genau hier kommt das Zusammenspiel mit Blue Team und Purple Team ins Spiel. Ein reines Gegeneinander erzeugt oft mehr Ego als Erkenntnis. Das Ziel ist nicht, Verteidiger bloßzustellen, sondern reale Lücken in Detection, Triage, Eskalation und Reaktion sichtbar zu machen.

In verdeckten Übungen ist die erste Frage: Wurde der Angriff erkannt, korrekt priorisiert und angemessen eskaliert? Dabei zählt nicht nur der erste Alarm, sondern die gesamte Reaktionskette. Wurde der Vorfall als zusammenhängender Angriff verstanden oder nur als lose Event-Sammlung? Wurden Identitäten, Hosts und Netzwerkpfade korreliert? Wurden containment-fähige Maßnahmen eingeleitet? Genau an diesen Punkten zeigt sich die Reife von Monitoring und Incident Response. Themen wie Security Monitoring Alerting, Security Monitoring Use Cases und Defense Incident Response sind deshalb direkt mit Red Teaming verknüpft.

Purple Teaming ist besonders dann sinnvoll, wenn aus einem Red-Team-Befund konkrete Verbesserungen abgeleitet werden sollen. Dabei werden TTPs gezielt nachgestellt, Telemetrie gemeinsam analysiert und Detection-Regeln verfeinert. Der Mehrwert liegt in der Präzision. Statt allgemein zu sagen, dass Lateral Movement nicht erkannt wurde, wird exakt herausgearbeitet, welche Datenquelle fehlte, welche Korrelation nicht existierte oder welche Regel zu viele False Positives erzeugte. So entsteht aus einem Angriffspfad ein belastbarer Verbesserungsplan.

Ein häufiger Fehler ist das Vermischen von Übungszielen. Wenn ein Einsatz gleichzeitig verdeckt, maximal realistisch, umfassend dokumentiert, sofort auswertbar und parallel als Schulung für das SOC dienen soll, entstehen Zielkonflikte. Besser ist eine klare Trennung: erst verdeckte Validierung, dann kontrollierte Purple-Phase zur Nachbearbeitung. So bleibt die Aussagekraft der Übung erhalten, ohne auf Lerngewinn zu verzichten.

Auch die Sprache im Debriefing ist entscheidend. Gute Red Teams berichten nicht in Tool-Namen, sondern in Verteidigungsrelevanz. Nicht wichtig ist, welches Framework genutzt wurde. Wichtig ist, dass ein kompromittiertes Benutzerkonto über unzureichend segmentierte Management-Pfade zu privilegierten Sessions führte und dass diese Kette weder auf Endpoint- noch auf SIEM-Ebene zuverlässig erkannt wurde. Diese Übersetzung von Technik in Verteidigungswirkung macht den Unterschied zwischen Show und Substanz.

Viele Fehler im Red Teaming sind keine Technikprobleme, sondern Denkfehler. Der erste große Fehler ist Scope-Drift. Ein Team findet einen interessanten Pfad außerhalb des eigentlichen Missionsziels und verliert Fokus, Zeit und Kontrolle. Das Ergebnis sind viele technische Notizen, aber keine belastbare Aussage zum eigentlichen Risiko. Red Teaming braucht Disziplin. Nicht jeder mögliche Angriff ist relevant.

Der zweite Fehler ist Tool-Zentrierung. Wer sich an ein bevorzugtes Framework klammert, passt die Operation an das Tool an statt umgekehrt. Das führt zu vorhersehbaren Mustern, unnötiger Telemetrie und schlechter Anpassungsfähigkeit. Professionelle Teams denken in Fähigkeiten: Zugriff, Ausführung, Persistenz, Credential Access, Pivot, Exfiltration, Nachweis. Welche Werkzeuge dafür genutzt werden, ist zweitrangig.

Der dritte Fehler ist mangelhafte Dokumentation während der Durchführung. Viele Teams verlassen sich auf spätere Rekonstruktion. Das funktioniert selten. Ohne zeitnahe Notizen gehen Kontext, Kausalität und genaue Bedingungen verloren. Dann lässt sich später zwar sagen, dass ein Ziel erreicht wurde, aber nicht mehr präzise, warum der Pfad funktionierte. Für belastbare Gegenmaßnahmen ist das zu wenig.

Weitere typische Fehler treten immer wieder auf:

• Zu frühe Nutzung lauter Techniken, bevor passive oder unauffällige Wege ausgeschöpft wurden.
• Unterschätzung von Identitäts- und Cloud-Pfaden zugunsten klassischer Host-Exploitation.
• Fehlende Abbruchdisziplin bei instabilen Systemen, unerwarteten Seiteneffekten oder Scope-Grenzen.

Ein besonders kritischer Punkt ist die falsche Bewertung von Erfolg. Wenn ein Team Domain-Admin erreicht, aber dafür unrealistische Annahmen, unzulässige Schritte oder hochgradig detektierbare Methoden brauchte, ist der Befund operativ schwächer als ein unauffälliger Zugriff auf ein geschäftskritisches System mit normalen Benutzerrechten. Erfolg muss immer im Kontext von Plausibilität, Aufwand, Sichtbarkeit und Geschäftswirkung bewertet werden.

Ebenso problematisch ist das Ignorieren von Verteidigerrealität. Manche Red Teams bewerten eine Umgebung als schwach, obwohl das Blue Team den Angriff korrekt erkannt und eingedämmt hat. Andere feiern Heimlichkeit, obwohl sie nur deshalb unentdeckt blieben, weil das Szenario an den tatsächlichen Bedrohungen der Organisation vorbeiging. Wer Red Teaming sauber betreibt, bewertet nicht nur technische Ausnutzung, sondern auch Detection, Reaktion und organisatorische Robustheit. Ergänzend lohnt der Blick auf Pentesting Typische Fehler und It Security Typische Fehler, weil viele operative Schwächen dort bereits im Grundmuster sichtbar werden.

Ein Red-Team-Report ist kein Sammelalbum einzelner Findings. Er muss den Angriff als Kette erklären. Entscheider brauchen eine klare Aussage, wie ein realistischer Gegner vom Einstieg bis zum Ziel gelangt ist. Technische Teams brauchen reproduzierbare Details, um Ursachen zu beheben. Das bedeutet: Chronologie, Kontext, Voraussetzungen, genutzte Schwächen, betroffene Kontrollen, Detektionslage, Geschäftsauswirkung und priorisierte Maßnahmen.

Wirklich gute Reports unterscheiden zwischen Symptom und Ursache. Wenn ein Servicekonto missbraucht wurde, ist die Ursache oft nicht nur das Konto selbst, sondern eine Kombination aus übermäßigen Rechten, fehlender Segmentierung, unzureichender Secret-Verwaltung und mangelnder Überwachung. Wenn Lateral Movement möglich war, liegt das Problem selten nur in einem offenen Port, sondern in Vertrauensbeziehungen, Administrationsmodellen und fehlendem Tiering. Diese Ursachenkette muss sichtbar werden, sonst werden nur Symptome geflickt.

Ein belastbarer Report enthält typischerweise eine Management-Zusammenfassung, eine technische Angriffschronologie, eine Analyse der Verteidigungswirkung und konkrete Maßnahmen. Die Maßnahmen sollten nicht als lose Liste erscheinen, sondern entlang des Angriffspfads priorisiert werden. Was unterbricht den Pfad früh? Was reduziert Reichweite? Was verbessert Detection? Was senkt die Wahrscheinlichkeit einer Wiederholung? Genau diese Struktur macht Reporting verwertbar. Wer den formalen Prozess vertiefen will, findet ergänzende Aspekte in Pentesting Reporting und bei Bedarf auch in Forensik Reporting.

Ein kurzes Beispiel für die Darstellung eines Angriffspfads kann so aussehen:

1. Externer Zugriff über schwach geschütztes SSO-Konto
2. Nutzung gültiger Benutzeridentität ohne MFA-Zwang auf Alt-System
3. Zugriff auf internes Portal mit hinterlegten Konfigurationsdaten
4. Extraktion eines Service-Secrets aus Deployment-Artefakten
5. Anmeldung an Management-System mit überprivilegiertem Servicekonto
6. Seitliche Bewegung auf Administrationshost
7. Zugriff auf privilegierte Sitzungstokens
8. Erreichen des Zielsystems und kontrollierter Nachweis des Datenzugriffs

Diese Form ist deutlich wertvoller als zehn isolierte Schwachstellenbeschreibungen. Sie zeigt Ursache, Reihenfolge und Verteidigungsversagen in einem Bild. Zusätzlich sollte der Report immer festhalten, welche TTPs erkannt wurden, welche nicht und wo Reaktionsprozesse versagt oder funktioniert haben. So wird aus dem Red-Team-Einsatz nicht nur ein Angriffsnachweis, sondern ein echter Reifegradtest für Technik und Organisation.

Wichtig ist auch die Trennung zwischen reproduzierbaren Details und sensiblen Operationsinformationen. Nicht jede Infrastruktur- oder OPSEC-Entscheidung gehört in einen breiten Report-Verteiler. Technische Tiefe ist notwendig, aber sie muss zielgruppengerecht verteilt werden. Management braucht Wirkung und Priorisierung, Engineering braucht Ursachen und Maßnahmen, Security Operations braucht Telemetrie und Detection-Lücken.

Professionelles Red Teaming lebt von wiederholbaren Workflows. Nicht starre Checklisten, sondern belastbare Abläufe, die unter Druck funktionieren. Ein sauberer Workflow beginnt mit Missionsklärung, Scope, Freigaben, White-Cell-Struktur und Risikobewertung. Danach folgen Recon, Hypothesenbildung, Infrastrukturvorbereitung, technische Dry-Runs und ein abgestufter Operationsplan. Erst wenn diese Basis steht, beginnt die eigentliche Durchführung.

Während der Durchführung braucht es ein striktes Logbuch. Jede Aktion, jeder Host, jede Identität, jede Beobachtung und jede Reaktion der Verteidigung muss zeitnah dokumentiert werden. Das dient nicht nur dem späteren Reporting, sondern auch der operativen Sicherheit. Wer den Überblick über genutzte Konten, gesetzte Artefakte oder erreichte Systeme verliert, erhöht das Risiko von Scope-Verletzungen und unbeabsichtigten Seiteneffekten. Gerade in längeren Einsätzen mit mehreren Pfaden ist diese Disziplin unverzichtbar.

Ein weiterer Kernpunkt ist Entscheidungslogik. Gute Teams definieren vorab, wann sie von einem Pfad abweichen. Beispiel: Wenn ein Initial-Access-Versuch zu stark detektiert wird, wird nicht reflexartig eskaliert, sondern bewertet, ob das Missionsziel mit einem alternativen Pfad besser erreichbar ist. Wenn ein Host instabil wirkt, wird nicht weiter getestet, sondern gestoppt und über die White Cell entschieden. Wenn ein privilegierter Kontext erreicht ist, wird geprüft, ob das Ziel bereits nachweisbar ist, statt unnötig weiter zu expandieren.

Zur Nachbereitung gehört mehr als ein Report. Artefakte müssen identifiziert, temporäre Infrastruktur zurückgebaut, gesetzte Konten oder Regeln entfernt und verbleibende Risiken transparent gemacht werden. In manchen Fällen ist zusätzlich eine forensische Abstimmung sinnvoll, insbesondere wenn produktionsnahe Systeme betroffen waren oder Verteidiger während der Übung echte Incident-Prozesse gestartet haben. Die Verbindung zu Forensik Incident Response und It Security Chain Of Custody wird relevant, sobald Nachvollziehbarkeit und Beweissicherung eine Rolle spielen.

Ein praxistauglicher Workflow für Red Teams umfasst typischerweise diese Phasen:

Phase 1: Zieldefinition und Rules of Engagement
Phase 2: Recon und Angriffshypothesen
Phase 3: Infrastruktur- und OPSEC-Vorbereitung
Phase 4: Initial Access mit kontrollierter Validierung
Phase 5: Post-Exploitation und zielgerichtete Expansion
Phase 6: Zielnachweis mit minimal notwendiger Wirkung
Phase 7: Debriefing, Reporting und Verbesserungsplanung

Wer diese Phasen sauber trennt, reduziert Fehler, verbessert Reproduzierbarkeit und erhöht den tatsächlichen Nutzen des Einsatzes. Red Teaming ist dann nicht nur ein technischer Härtetest, sondern ein Instrument zur realistischen Bewertung von Sicherheitsarchitektur, Detection und organisatorischer Reaktionsfähigkeit. Genau darin liegt der eigentliche Wert für Unternehmen, die ihre Verteidigung nicht auf Annahmen, sondern auf überprüfbare Realität stützen wollen.