Assumed Breach erklärt: Der Angriff beginnt hinter der Firewall

Jede Sicherheitsarchitektur, die wir prüfen, investiert den Großteil ihres Budgets in den Perimeter: Firewalls, E-Mail-Filter, Webproxys, Awareness-Schulungen. Das ist richtig, aber es beantwortet nicht die Frage, die Geschäftsführung und Aufsichtsgremien eigentlich stellen: Was passiert, wenn es trotzdem jemand hineinschafft? Die Statistiken lassen daran wenig Zweifel. Laut Mandiant M-Trends 2026 waren Exploits mit 32 Prozent der häufigste Erstzugriff, gefolgt von Vishing mit 11 Prozent; laut Verizon DBIR 2025 waren Drittparteien an 30 Prozent der Breaches beteiligt. Irgendeiner dieser Wege ist für fast jede Organisation offen.

Der Assumed-Breach-Ansatz zieht daraus die Konsequenz: Er nimmt die Kompromittierung als gegeben an und prüft, was danach geschieht. Das Red Team startet nicht von außen, sondern mit einem bereitgestellten Zugang – so, wie ein Angreifer ihn nach erfolgreichem Phishing, über einen gestohlenen Dienstleister-Account oder über eine ungepatchte Schwachstelle erlangt hätte. Von dort aus arbeitet es sich zu den vereinbarten Zielen vor, verdeckt und mit denselben Methoden wie im Full-Scope Red Teaming.

Dieser Beitrag erklärt die Logik hinter dem Ansatz, beschreibt typische Startpunkte und den Ablauf, zeigt, was gemessen wird, und ordnet ein, wann Assumed Breach die bessere Wahl ist als ein Red Teaming mit vollem Umfang.

Die Logik: Kompromittierung ist eine Frage des Wann

Das Grundprinzip ist älter als der Begriff. Zero-Trust-Architekturen, Netzwerksegmentierung und das Prinzip der minimalen Rechte beruhen alle auf der Annahme, dass einzelne Systeme oder Konten kompromittiert werden und der Schaden begrenzt bleiben muss. Assumed Breach überträgt dieses Prinzip auf die Sicherheitsprüfung: Statt zu testen, ob ein Angreifer hineinkommt, wird getestet, wie weit er kommt und ob er dabei auffällt.

Der Ansatz ist nicht pessimistisch, sondern ökonomisch. Ein Full-Scope Red Teaming verbringt oft ein Drittel bis die Hälfte seiner Zeit mit Reconnaissance, Phishing-Infrastruktur und dem Erarbeiten eines Erstzugriffs. Das ist realistisch und liefert eigene Erkenntnisse – etwa zur Wirksamkeit von Awareness-Maßnahmen und E-Mail-Filtern. Für die Frage nach Erkennung und Reaktion im Inneren ist diese Phase aber kein Erkenntnisgewinn, sondern Aufwand. Wer weiß, dass irgendein Weg hinein existiert, kann ihn überspringen und das Budget auf die Phasen konzentrieren, in denen sich entscheidet, ob aus einem Vorfall ein Schaden wird.

Genau diese Phasen sind in der Praxis entscheidend. CrowdStrike beziffert im Global Threat Report 2026 die durchschnittliche Breakout Time – die Zeit vom ersten kompromittierten System bis zur Bewegung auf das nächste – auf 29 Minuten, im schnellsten Fall auf 27 Sekunden. Was danach geschieht, hängt davon ab, wie das Active Directory konfiguriert ist, welche Rechte ein Standardkonto hat und ob jemand den ersten verdächtigen Schritt bemerkt.

Typische Startpunkte

Der Startpunkt eines Assumed-Breach-Tests wird im Scoping festgelegt und bildet ein konkretes Bedrohungsszenario ab. Drei Varianten decken die meisten Fälle ab:

1. Kompromittierter Client. Das Red Team erhält Zugriff auf einen Standard-Arbeitsplatzrechner mit einem normalen Domänenkonto – das Szenario nach einem erfolgreichen Phishing oder einer schadhaften Datei. Der Client ist wie jeder andere konfiguriert, inklusive EDR und Gruppenrichtlinien. Dieser Startpunkt prüft, ob ein Angreifer von einem normalen Nutzer aus Rechte ausweiten und sich im Netz bewegen kann, und ob EDR und SOC das sehen.
2. Domänenkonto ohne Client. Das Red Team erhält nur Zugangsdaten eines regulären Kontos und Netzwerkzugang, etwa über VPN – das Szenario nach Credential Stuffing oder Password Spraying gegen ein Portal. Hier zeigt sich, was ein Angreifer ohne Fuß auf einem verwalteten Endgerät erreicht und wie gut Zugriffsrichtlinien und MFA greifen.
3. Zugang eines Dienstleisters. Das Red Team arbeitet mit dem Zugang, den ein externer IT-Dienstleister, Wartungspartner oder Softwareanbieter typischerweise hat: Fernwartungszugang, Service-Konto, Jump Host. Angesichts der Verizon-Zahl von 30 Prozent Drittparteienbeteiligung ist das ein Szenario mit hoher Relevanz, das viele Unternehmen bisher nie geprüft haben.

Weitere Varianten sind ein kompromittiertes Cloud-Identitätskonto in Entra ID oder der Zugang eines Mitarbeitenden in einer Tochtergesellschaft mit Vertrauensstellung zur Hauptdomäne. Welche Variante sinnvoll ist, hängt davon ab, welches Risiko Sie als am wahrscheinlichsten oder am wenigsten geprüft einschätzen.

Ablauf eines Assumed-Breach-Tests

Der Ablauf folgt dem des Red Teamings, verkürzt um die ersten Phasen:

1. Scoping und Rules of Engagement. Ziele (Flags), Startpunkt, Ausschlüsse, Zeitfenster, Kommunikationswege, Abbruchkriterien und Notfallkontakte werden schriftlich festgelegt. Ein Control Team aus zwei bis drei Personen wird benannt; alle anderen, insbesondere SOC und Administratoren, bleiben uninformiert.
2. Bereitstellung des Zugangs. Das Control Team legt das Konto oder den Client so an, wie es für jede neue Mitarbeitende geschähe – ohne Sonderrechte, ohne Ausnahmen im EDR. Das Red Team übernimmt den Zugang an einem vereinbarten Termin.
3. Discovery und Situationsaufklärung. Das Red Team ermittelt verdeckt, wo es sich befindet: Domänenstruktur, Gruppenmitgliedschaften, erreichbare Systeme, Freigaben, installierte Sicherheitswerkzeuge. Diese Phase ist bereits aussagekräftig, weil sie zeigt, wie viel ein Standardkonto über die Umgebung erfahren kann.
4. Privilege Escalation und Lateral Movement. Über Fehlkonfigurationen, schwache Dienstkonten, Kerberos-Schwächen, lokale Admin-Rechte oder Zugangsdaten in Skripten und Freigaben weitet das Team seine Rechte aus und bewegt sich Richtung Ziel. Jeder Schritt wird mit Zeitstempel dokumentiert.
5. Zielerreichung und Nachweis. Die vereinbarten Flags werden erreicht und dokumentiert – ohne destruktive Aktionen. Ein Zugriff auf die Kundendatenbank wird durch einen Screenshot der Tabellenstruktur belegt, nicht durch das Abziehen der Daten.
6. Rückbau und Bericht. Alle angelegten Konten, Werkzeuge und Änderungen werden entfernt und dem Control Team übergeben. Der Bericht enthält Angriffs-Narrativ, Findings mit Root Cause, Detection Gaps und einen Maßnahmenplan. Im Replay-Workshop gehen Red Team und Blue Team die Kette gemeinsam durch.

Was gemessen wird

Ein Assumed-Breach-Test liefert konkrete, vergleichbare Kennzahlen – das unterscheidet ihn von einer reinen Schwachstellenliste:

• Zeit bis zur ersten Rechteausweitung. Wie lange brauchte das Team vom Standardkonto bis zu lokalen Admin-Rechten oder einem privilegierten Dienstkonto?
• Zeit bis zum Ziel. Wie viele Arbeitstage lagen zwischen Übernahme des Zugangs und Erreichen der ersten Flag?
• Erkennungsquote. Welcher Anteil der ausgeführten Techniken, gemappt auf MITRE ATT&CK, wurde protokolliert, welcher löste einen Alarm aus, welcher wurde blockiert?
• Zeit bis zum Alarm und zur Reaktion. Wurde das Team bemerkt? Wenn ja, nach wie vielen Tagen, durch welchen Alarm, und was geschah dann? Wurde das Konto gesperrt, der Client isoliert, das Control Team informiert?
• Root Causes. Welche strukturellen Ursachen – etwa fehlende Netzwerksegmentierung, überprivilegierte Dienstkonten oder unverändertes krbtgt-Passwort – haben den Angriffspfad ermöglicht?

Diese Messgrößen lassen sich bei einem Wiederholungstest nach zwölf bis achtzehn Monaten direkt vergleichen. Eine Dwell Time, die von „nicht erkannt“ auf „nach drei Tagen erkannt und eingedämmt“ sinkt, ist ein Fortschritt, den auch ein Aufsichtsrat versteht.

Vergleich mit dem Full-Scope Red Teaming

Der Kosten- und Zeitvorteil ergibt sich unmittelbar aus den entfallenden Phasen. Ein Assumed-Breach-Test liegt im Aufwand typischerweise bei der Hälfte bis einem Drittel eines Full-Scope Red Teamings und liefert für die internen Kontrollen dieselbe Aussagekraft. Was Sie nicht erfahren, ist, ob Ihr Perimeter und Ihre Mitarbeitenden den Erstzugriff verhindert hätten. Diese Frage lässt sich separat und gezielt mit einer Phishing- oder Vishing-Kampagne klären – oft günstiger als im Rahmen eines Red Teamings.

Wann Assumed Breach die richtige Wahl ist

Assumed Breach ist der empfohlene Einstieg für Unternehmen, die zum ersten Mal Erkennung und Reaktion unter Realbedingungen prüfen wollen. Es ist ebenso die richtige Wahl, wenn ein konkretes Szenario geprüft werden soll – etwa die Frage, was ein kompromittierter Wartungszugang eines Dienstleisters ermöglicht, oder was passiert, wenn ein Mitarbeitender mit Standardrechten böswillig handelt. Und es ist eine sinnvolle Ergänzung für Organisationen, die bereits Full-Scope Red Teamings durchführen und zwischen den Zyklen gezielt einzelne Bereiche prüfen wollen, etwa nach einer Migration ins Active Directory einer übernommenen Gesellschaft.

Das Full-Scope Red Teaming bleibt die Wahl, wenn die Frage ausdrücklich lautet, ob ein Angreifer von außen hineinkommt, oder wenn regulatorische Vorgaben wie DORA-TLPT den vollen Umfang verlangen. Für alle anderen gilt: Der Angriff beginnt in der Realität meist mit einem Klick oder einem gestohlenen Passwort. Was danach geschieht, entscheidet über den Schaden – und genau das prüft Assumed Breach.

Fazit

Assumed Breach ist kein abgespecktes Red Teaming, sondern eine bewusste Fokussierung auf die Phasen, in denen sich der Ausgang eines Angriffs entscheidet. Der Test ist schneller, günstiger und liefert für Erkennung und Reaktion dieselbe Aussagekraft wie ein Einsatz mit vollem Umfang. Für den Mittelstand und für den ersten Red-Team-Einsatz ist er in den meisten Fällen die bessere Wahl. Wie wir einen Assumed-Breach-Test aufsetzen, welche Startpunkte wir empfehlen und wie der Bericht aussieht, besprechen wir gern in einem Erstgespräch.

Quellen

• Mandiant, M-Trends 2026 – Verteilung der Erstzugriffsvektoren
• Verizon, Data Breach Investigations Report 2025 – Beteiligung von Drittparteien
• CrowdStrike, Global Threat Report 2026 – Breakout Time
• CISA, Cybersecurity Advisory AA23-059A, 2023 – Root Causes im Active Directory, cisa.gov
• MITRE ATT&CK Enterprise, attack.mitre.org

Häufige Fragen zum Thema