Adversary Emulation stellt threat-informed das Verhalten realer Angreifer nach - ihre Tactics, Techniques und Procedures (TTPs), meist als strukturierten Emulation Plan. Das kann einen konkreten, namentlich bekannten Threat Actor abbilden, muss es aber nicht: Grundlage ist real beobachtete Angreiferaktivität, nicht zwingend eine einzelne Gruppe. Geprüft wird, wie gut die eigene Verteidigung dieses Verhalten verhindert, sichtbar macht, erkennt, untersuchen und beantworten kann - nicht nur die Erkennung allein. Grundlage sind Threat Intelligence und das MITRE-ATT&CK-Framework; Werkzeuge wie Atomic Red Team und MITRE Caldera unterstützen die Durchführung.
Was ist Adversary Emulation?
Adversary Emulation (deutsch etwa Angreifer-Nachbildung) ist ein Ansatz, bei dem ein Sicherheitsteam reales Angreiferverhalten threat-informed nachstellt. Grundlage ist nicht Fantasie, sondern Dokumentation: beobachtete Tactics, Techniques und Procedures werden in einen nachvollziehbaren Ablauf, einen Emulation Plan, übersetzt und kontrolliert ausgeführt. Häufig orientiert sich das an einem konkreten, namentlich bekannten Threat Actor - das ist der wichtigste Anwendungsfall, aber nicht die einzige Form. Ebenso lässt sich das typische Verhalten einer Angreiferklasse oder ein Satz besonders relevanter TTPs nachbilden.
Der Kern ist der Begriff threat-informed. Die getesteten Techniken werden nicht danach ausgewählt, was am leichtesten funktioniert, sondern danach, was ein für die eigene Organisation realistischer Gegner tatsächlich einsetzt. Eine Bank stellt andere Angreifer nach als ein Industrieunternehmen. So wird die Prüfung relevant statt beliebig.
Abgrenzung zu Pentest, Red Teaming und Simulation
Adversary Emulation steht zwischen den anderen Verfahren und wird oft mit ihnen kombiniert.
| Verfahren | Leitidee |
|---|---|
| Penetrationstest | Findet und validiert Schwachstellen und Angriffsmöglichkeiten im definierten Scope. Siehe Penetration Testing. |
| Adversary Emulation | Stellt threat-informed die TTPs realer Angreifer kontrolliert nach und prüft Prevention, Sichtbarkeit, Detection, Investigation und Response. |
| Adversary Simulation | Simuliert allgemeiner realistisches Angreiferverhalten, ohne zwingend einen bestimmten Actor abzubilden. |
| Red Teaming | Objective-orientierte Operation, häufig mit Fokus auf Verdecktheit und die organisatorische Reaktion. Kann Emulation als Baustein nutzen. Siehe Red Teaming. |
| Purple Teaming | Kollaborative Arbeitsweise von Angriff und Verteidigung mit dem Ziel, Erkennung und Abwehr zu verbessern. |
Vereinfacht: Der Pentest fragt nach Schwachstellen, die Emulation fragt "Wie gut kommt unsere Verteidigung mit dem Verhalten dieses Angreifers zurecht?", und das Red Team fragt "Erreicht ein Angreifer sein Ziel, ohne entdeckt zu werden?". Emulation ist dabei besonders eng mit der Verteidigung verzahnt, weil sie die gesamte Verteidigungskette prüft, von Prevention über Detection bis Response.
Die Grundlage: MITRE ATT&CK und TTPs
Adversary Emulation steht und fällt mit einer gemeinsamen Sprache für Angriffsverhalten. Diese Sprache liefert MITRE ATT&CK, eine strukturierte Wissensbasis realer Angriffstechniken, geordnet nach Taktiken (dem Warum) und Techniken (dem Wie).
Das Denkmodell dahinter sind die TTPs:
- Tactics: das taktische Ziel eines Schritts, etwa Initial Access oder Credential Access.
- Techniques: die Methode, mit der das Ziel erreicht wird, etwa Phishing oder das Auslesen von Zugangsdaten.
- Procedures: die konkrete, beobachtbare Umsetzung durch eine bestimmte Gruppe.
Je weiter unten in dieser Kette, desto aussagekräftiger wird der Test. Die Procedures sind das, was eine Emulation von einem generischen Angriff unterscheidet. Die einzelnen Techniken mit kopierbaren Payloads und ihrer Erkennung sammelt die Payload-Sammlung entlang der ATT&CK-Taktiken.
Vom Threat Actor zum Emulation Plan
Eine Emulation entsteht in nachvollziehbaren Schritten, vom abstrakten Bedrohungswissen zum konkreten Ablauf.
Der letzte Schritt ist der eigentliche Zweck. Adversary Emulation ist kein Selbstzweck, sondern liefert pro Technik eine klare Aussage entlang der gesamten Verteidigungskette. Bewährt hat sich ein einfaches Ergebnis-Schema je Technik:
- Prevented: durch eine Schutzmaßnahme verhindert?
- Observed: in der Telemetrie überhaupt sichtbar?
- Detected: hat eine Erkennung angeschlagen?
- Investigated: ließ sich der Vorgang sinnvoll untersuchen?
- Responded: wurde angemessen reagiert?
Jede Technik, die an einer dieser Stufen durchfällt, ist ein konkreter, belegter Befund - und damit eine klare Arbeitsanweisung für Prevention, Telemetrie, Detection oder Response.
Werkzeuge für Adversary Emulation
Mehrere offene Projekte machen Emulation reproduzierbar, statt jede Technik von Hand nachzubauen.
| Werkzeug | Ansatz |
|---|---|
| Atomic Red Team | Kleine, atomare Einzeltests pro ATT&CK-Technik. Sehr gut für Technique Tests und Control Validation, aber für sich genommen noch keine vollständige Adversary Emulation. |
| MITRE Caldera | Automatisierungsplattform mit Agenten, die TTP-Ketten abspielt. Automatisierung beschleunigt die Durchführung, erzeugt aber nicht von allein eine realistische Emulation - die Qualität hängt am zugrunde liegenden Plan. |
| CTID Adversary Emulation Library | Fertige, frei verfügbare Emulation Plans für konkrete Gruppen, gepflegt vom Center for Threat-Informed Defense. |
Welches Werkzeug passt, hängt vom Ziel ab. Für den schnellen Test einer einzelnen Technik genügt ein atomarer Test. Für eine realistische, zusammenhängende Kette lohnt sich ein strukturierter Emulation Plan.
Beispiel: eine TTP-Kette nachstellen
Angenommen, Threat Intelligence nennt eine Gruppe, die typischerweise über Phishing einsteigt, PowerShell zur Ausführung nutzt, Zugangsdaten aus dem Speicher ausliest und sich dann seitlich bewegt. Als Emulation Plan in ATT&CK-Begriffen:
- Initial Access - Spearphishing Attachment (T1566.001). Siehe Initial Access.
- Execution - Command and Scripting Interpreter: PowerShell (T1059.001). Siehe Execution.
- Credential Access - OS Credential Dumping (T1003). Siehe Credential Access.
- Lateral Movement - Remote Services (T1021). Siehe Lateral Movement.
Jeder dieser Schritte wird einzeln ausgeführt und mit der Erkennung abgeglichen. Bleibt zum Beispiel das Credential Dumping unentdeckt, ist das ein konkreter, belegter Detection-Gap - und damit eine klare Arbeitsanweisung für das Verteidigungsteam.
Zusammenspiel mit Detection und Purple Teaming
Adversary Emulation entfaltet ihren Wert erst im Schulterschluss mit der Verteidigung. Jede nachgestellte Technik stellt nicht nur die eine Frage "Wurde sie erkannt?", sondern eine ganze Kette:
- Wurde sie verhindert (Prevention)?
- War sie überhaupt sichtbar (Telemetry / Visibility)?
- Wurde sie erkannt (Detection)?
- Konnte sie untersucht werden (Investigation)?
- Wurde angemessen reagiert (Response)?
So prüft Emulation nicht nur einzelne Erkennungsregeln, sondern die vorhandenen Security Controls und Prozesse als Ganzes. Fehlt an einer Stufe etwas, ist das ein konkreter Ansatzpunkt zur Verbesserung.
Im Purple-Teaming-Modus gehen Angriffs- und Verteidigungsseite die Emulation gemeinsam durch und schließen Lücken direkt. Die Erkennungsseite - welche Telemetrie und welche Regeln eine Technik sichtbar machen - vertieft das Schwesterportal blue-team.net.
Nutzen und Grenzen
Der größte Nutzen von Adversary Emulation ist Fokus: Statt gegen eine endlose Liste theoretischer Bedrohungen zu arbeiten, prüft man gezielt gegen das, was realistisch droht. Das macht Ergebnisse priorisierbar und begründbar.
Die Grenzen sollte man kennen:
- Die Qualität hängt unmittelbar von der zugrunde liegenden Threat Intelligence ab. Bildet man den falschen Angreifer nach, prüft man am realen Risiko vorbei.
- Dokumentierte TTPs können unvollständig oder veraltet sein. Öffentliche Berichte zeigen nur, was beobachtet und veröffentlicht wurde.
- Erkennung im Lab bedeutet nicht automatisch Produktionstauglichkeit. Unter realen, verrauschten Bedingungen kann dieselbe Regel untergehen oder zu viele Fehlalarme erzeugen.
- Technische Emulation testet nicht automatisch Menschen und Geschäftsprozesse. Dafür braucht es Szenarien, die auch organisatorische Reaktion einbeziehen, etwa im Rahmen von Red Teaming.
Häufige Fragen
Was ist der Unterschied zwischen Adversary Emulation und Simulation?
Emulation stellt threat-informed reale TTPs nach, häufig orientiert an einem konkreten Angreifer, aber nicht zwingend. Simulation stellt allgemeiner realistisches Angreiferverhalten nach, ohne an eine bestimmte Gruppe oder konkret dokumentierte TTPs gebunden zu sein.
Braucht man dafür ein Red Team?
Nicht zwingend. Mit Werkzeugen wie Atomic Red Team können auch Blue Teams einzelne Techniken gegen ihre Erkennung testen. Für vollständige, verdeckte Ketten ist ein Red Team oder spezialisiertes Personal sinnvoll.
Wo finde ich fertige Emulation Plans?
Die Adversary Emulation Library des Center for Threat-Informed Defense stellt frei verfügbare Pläne für konkrete Gruppen bereit. Sie sind ein guter Startpunkt und lassen sich an die eigene Umgebung anpassen.
Ist das legal?
Nur in einer freigegebenen Umgebung mit wirksamer Autorisierung. Es gelten dieselben Rahmenbedingungen wie bei Pentest und Red Teaming.