Diese Simulation zeigt einen typischen Ablauf — von der ersten Recherche bis zum erreichten Ziel. Reale Engagements laufen oft über Tage bis Wochen, nicht Minuten.
Vereinfachte Darstellung eines realistischen Angriffspfads. Tatsächliche Dauer, Reihenfolge und Vektoren hängen vom vereinbarten Scope ab.
Ladet euch einen anonymisierten Beispielbericht herunter und seht selbst, wie detailliert wir eine Angriffskette dokumentieren.
Ein exponierter Account, eine unbewachte Tür, eine Phishing-Mail: einzeln oft 'nur mittel'. Erst die Verkettung zeigt den echten Business Impact — genau den Pfad, den ein echter Angreifer auch wählen würde.
Modul-Pentests sind meist angekündigt. Red Teaming prüft zusätzlich, ob euer SOC oder Blue Team einen echten, unangekündigten Angriff überhaupt bemerkt — und wie schnell reagiert wird.
Module prüfen systematisch die Breite eurer Angriffsfläche. Red Teaming verfolgt ein konkretes Ziel mit allen zur Verfügung stehenden Mitteln — genau wie ein realer, motivierter Angreifer.
| Merkmal | Modul-Pentest | Red Teaming |
|---|---|---|
| Leitfrage | Wo sind Schwachstellen? | Wie weit kommt ein Angreifer? |
| Scope | Einzelnes System / einzelner Vektor | Ganzes Unternehmen, ein definiertes Ziel |
| Ankündigung | Bekannt und geplant | Verdeckt, meist nur C-Level informiert |
| Prüft Erkennung & Reaktion | Nicht im Fokus | Zentraler Bestandteil |
| Ideal für | Compliance-Nachweis, jährlicher Turnus | Sicherheitsreife über Compliance hinaus |
| Physischer Zugang | Nur wenn separat gebucht | Standardmäßig Teil der Angriffskette |
Beides schließt sich nicht aus: die meisten unserer Red-Team-Kunden haben zuvor bereits Modul-Pentests bei uns oder anderen Anbietern durchgeführt und wollen jetzt wissen, ob ihre Erkennung im Ernstfall wirklich greift.
Ein Red Team nimmt den Weg, der funktioniert, und selten den elegantesten. Deshalb planen wir jedes Engagement über mehrere Vektoren gleichzeitig und wechseln, sobald einer nicht weiterführt. Welche davon zum Einsatz kommen, legt der Scope fest.
Gezielte Mails an einzelne Abteilungen, Anrufe im Namen des IT-Supports, präparierte USB-Sticks oder ein QR-Code am Schwarzen Brett. In den meisten Engagements der schnellste Weg zum ersten Zugang.
Prüft: Awareness, Meldeverhalten, MFA-UmsetzungWir kommen am Nebeneingang mit hinein, kopieren eine Zutrittskarte im Vorbeigehen oder lassen im Besprechungsraum ein Gerät zurück, das sich nach außen verbindet. Wie das im Detail abläuft, steht auf der Seite zum Physical Pentest.
Prüft: Zutrittskontrolle, Empfang, Umgang der Belegschaft mit Fremden Zum Physical PentestVergessene VPN-Portale, schwache Passwörter auf Service-Accounts, zu weit gefasste Gruppenrechte. Im internen Netz führt der Weg zum Ziel fast immer über Active Directory.
Prüft: Härtung, Segmentierung, Tiering im AD Zum Active-Directory-PentestEin erbeutetes Passwort ist heute meist ein Cloud-Login. Wir prüfen Conditional-Access-Regeln, MFA-Ausnahmen, Legacy-Protokolle und was ein kompromittiertes Postfach an weiteren Türen öffnet.
Prüft: Conditional Access, MFA-Lücken, Logging in der Cloud
Ziel, Grenzen, autorisierte Kontakte und Eskalationswege werden gemeinsam definiert — inklusive Letter of Authorization.
OSINT, Footprinting und Planung realistischer Angriffspfade — passiv, ohne Spuren zu hinterlassen.
Über Phishing, Vishing oder physischen Zutritt verschaffen wir uns einen ersten, dauerhaften Zugriff.
Lateral Movement bis zum vereinbarten Ziel — mit lückenlosem, protokolliertem Nachweis jedes Schritts.
Vollständige Rekonstruktion der Angriffskette, Business-Impact-Bewertung und priorisierte Maßnahmen.
Gemeinsame Nachbesprechung mit eurem Blue Team — was wurde erkannt, was nicht, und warum.
Ziel ist nicht das bloße 'Reinkommen' — sondern der Nachweis, ob euer Unternehmen einen echten Angriff erkennt und stoppt.
Der klassische Ansatz beginnt ohne Vorwissen von außen. Er ist der realistischste, aber auch der aufwendigste. Je nach Reifegrad und Budget gibt es drei weitere Varianten, die wir regelmäßig durchführen.
Von der Recherche im Internet bis zum Ziel, ohne Vorwissen und ohne Ankündigung. Misst das Gesamtsystem inklusive Erkennung und Reaktion.
Unternehmen mit eigenem SOC oder MDR-Dienstleister, die wissen wollen, ob dieser im Ernstfall greift.
Wir starten mit dem, was ein Angreifer nach erfolgreichem Phishing hätte: ein normaler Mitarbeiter-Account und ein Notebook im Netz. Das spart die Phase des Erstzugriffs und konzentriert das Budget auf den Weg zum Ziel.
Der erste Test der internen Erkennung, oder wenn Phishing bereits separat geprüft wurde.
Angriff und Verteidigung sitzen im selben Raum. Wir führen Technik für Technik aus, euer Team prüft live, ob und wo Alarme auslösen, und die Detection wird direkt nachgeschärft.
Teams, die ein SIEM aufbauen oder nach einem Red Team die gefundenen Lücken systematisch schließen wollen.
Für Finanzunternehmen, die auf ein TLPT nach DORA zusteuern: Red Teaming entlang der TIBER-EU-Phasen mit Threat-Intelligence-Vorlauf, Control Team auf eurer Seite und entsprechender Dokumentation. So sind Abläufe und Rollen vor dem Pflichttest einmal durchgespielt.
Zur DORA-SeiteBanken, Versicherer und Zahlungsdienstleister, die die Aufsicht für ein TLPT ausgewählt hat oder die damit rechnen.
Ein Red Team arbeitet mit den Methoden echter Angreifer, aber nicht mit deren Freiheiten. Bevor die erste Mail rausgeht, steht ein Regelwerk, das beide Seiten unterschreiben. Diese Punkte sind in jedem unserer Engagements enthalten:
Benennt Auftraggeber, Scope, Zeitraum und die autorisierten Operator. Bei jedem physischen Einsatz tragen unsere Leute ihn bei sich, zusammen mit einer Rufnummer, unter der ein Ansprechpartner den Auftrag bestätigen kann.
Ein bis zwei eingeweihte Personen auf eurer Seite, erreichbar während des gesamten Engagements. Sie wissen, was wir tun, können eskalieren und im Zweifel entscheiden, ob ein Alarm echt oder unserer ist.
Beide Seiten können jederzeit stoppen. Wir unterbrechen von selbst, sobald wir auf Spuren eines echten Angreifers stoßen, einen produktiven Prozess gefährden würden oder Personen zu Schaden kommen könnten.
Kein Löschen, kein Verschlüsseln, kein Denial of Service, keine Änderung an Produktionsdaten. Wo ein echter Angreifer Ransomware ausrollen würde, legen wir eine Markerdatei ab und dokumentieren den Zugriff.
Wir kopieren keine echten Kunden- oder Personaldaten heraus. Den Zugriff belegen wir über Screenshots, Hashwerte oder vorab platzierte Testdatensätze. Erbeutete Zugangsdaten werden verschlüsselt gespeichert und nach Projektende gelöscht.
Private Geräte und Privatanschlüsse von Mitarbeitenden, Systeme von Dritten außerhalb des Scopes und sicherheitsrelevante OT-Steuerungen sind ausgeschlossen, sofern ihr sie nicht ausdrücklich freigebt.
Jede Aktion wird mit Zeitstempel, Quelle und Ziel festgehalten. So kann euer SOC im Nachhinein jeden Alarm einem Schritt zuordnen und unsere Aktivitäten von echten unterscheiden.
Meldet euer SOC während des Engagements einen Vorfall, klärt die White Cell mit uns innerhalb von Minuten, ob er von uns stammt. Ist das nicht der Fall, pausieren wir und ihr behandelt ihn als echten Incident.
Die Live-Simulation oben zeigt den Angriff aus unserer Sicht. Für euch zählt die spiegelbildliche Frage: Was davon hat eure Erkennung gesehen, und wann? Deshalb stellen wir im Bericht jede Angriffsphase dem gegenüber, was im SOC angekommen ist.
| Phase | Unsere Aktion | Was das SOC sah | Bewertung |
|---|---|---|---|
| Recon | OSINT, passive Aufklärung, Portscan von außen | Nichts. Bei passiver Aufklärung ist das erwartbar. | Neutral |
| Initial Access | Phishing an sechs Mitarbeitende, zwei Zugangsdaten erfasst | Eine Person meldete die Mail nach 40 Minuten. Das Ticket blieb ohne Folgeaktion. | Erkannt, keine Reaktion |
| Physical Foothold | Tailgating, Rogue Device im Besprechungsraum | Nichts. Das Gerät lief bis zum Debrief. | Nicht erkannt |
| Internal Access | Netzscan, Kerberoasting | SIEM-Alarm zu ungewöhnlichen Kerberos-Anfragen, als False Positive geschlossen | Erkannt, falsch bewertet |
| Privilege Escalation | Lateral Movement auf drei Server | EDR blockierte ein Tool. Der Operator wechselte die Methode, kein Alarm mehr. | Teilweise erkannt |
| Ziel | Domain Admin, Markerdatei abgelegt | Erst im Debrief | Nicht erkannt |
Vereinfachtes, anonymisiertes Beispiel, angelehnt an typische Ergebnisse. Aus dieser Gegenüberstellung entstehen die eigentlichen Maßnahmen. Neben dem Patch stehen dann Punkte wie „Alarm X ernst nehmen“ oder „Besucherprozess anpassen“ auf der Liste.
Der Bericht ist für zwei Leser geschrieben: die Geschäftsführung, die in zehn Minuten wissen will, wie es steht, und das Security-Team, das jeden Schritt nachvollziehen und nachstellen muss.
Anonymisierten Beispielbericht ansehenZwei Seiten: Ziel erreicht oder nicht, auf welchem Weg, was es im Ernstfall bedeutet hätte, die drei wichtigsten Maßnahmen.
Der komplette Weg chronologisch, mit Uhrzeiten, Screenshots und den Entscheidungen, die wir unterwegs getroffen haben. Die Sackgassen stehen auch drin.
Jede Phase gegen die Alarme, Tickets und Reaktionen eures SOC gestellt, wie in der Scorecard oben.
Jede Schwachstelle mit CVSS-Einstufung, aber zusätzlich mit der Frage: Hätte ihre Behebung die Kette an dieser Stelle unterbrochen? Das ordnet die Prioritäten oft anders als der Score allein.
Alle eingesetzten Techniken mit ATT&CK-ID, damit euer Team Detection-Regeln gezielt nachziehen und mit Threat Intelligence abgleichen kann.
Sortiert nach Aufwand und Wirkung, getrennt in Sofortmaßnahmen, organisatorische Änderungen und längerfristige Projekte.
IPs, Domains, Hashes und Hostnamen unserer Infrastruktur, damit ihr eure Logs nachträglich durchsuchen und unsere Spuren von fremden trennen könnt.
durchgeführte Red-Team-Engagements
getestete Vektoren pro Engagement (Mensch, Physisch, Technik)
Engagements mit unentdecktem Zugriff zum Ziel
durchgeführte Physical Tests als Fundament der Angriffskette
Red Teaming ist nirgends für alle vorgeschrieben. An mehreren Stellen ist es aber der Weg, die geforderte Wirksamkeitsprüfung tatsächlich zu belegen.
Art. 26 verpflichtet von der Aufsicht bestimmte Finanzunternehmen alle drei Jahre zu einem Threat-Led Penetration Test nach TIBER-EU. Für alle anderen gilt Art. 25 mit regelmäßigen Tests, für die Red Teaming die anspruchsvollste Form ist.
Zur DORA-SeiteArt. 21 verlangt Konzepte und Verfahren zur Bewertung der Wirksamkeit der Risikomanagementmaßnahmen. Ein Red Team liefert genau diese Bewertung, inklusive des Faktors Mensch und der Erkennung.
Zur NIS2-SeiteKapitel 9 der Norm fordert, die Informationssicherheit zu überwachen, zu messen und zu bewerten. Ein Red-Team-Bericht ist im Audit ein belastbarer Nachweis, dass die Wirksamkeit unabhängig geprüft wurde.
Zur ISO-27001-SeiteBetreiber kritischer Anlagen weisen alle zwei Jahre nach, dass ihre Maßnahmen dem Stand der Technik entsprechen. Red Teaming ersetzt diese Prüfung nicht, ergänzt sie aber um die Angreifersicht auf das Gesamtsystem.
Zur KRITIS-SeiteDie Begriffe aus der Simulation und dem Bericht, ohne Fachchinesisch.