Adversary Emulation mit Caldera und MITRE ATT&CK im Unternehmenslab

Wenn ein Kunde anruft und sagt, er habe den teuersten EDR am Markt gekauft und wolle wissen, ob das Ding 'taugt', ist die ehrliche Antwort nie ein PowerPoint-Report. Es ist eine Adversary-Emulation-Operation mit geschriebenem Szenario, ATT&CK-Mapping und kalten Metriken: wie viele Schritte unbemerkt blieben, wie viele eine Warnung erzeugten, wie viele in unter 60 Minuten in eine menschliche Reaktion muendeten. Bei Basilisk OffSec haben wir das rund um Caldera 5.x, Atomic Red Team und ein Windows-Domain-Lab mit acht Hosts standardisiert, das die Umgebung des Kunden abbildet, ohne dessen Produktion je zu beruehren. Dieser Text beschreibt den Stack, den Ablauf und die Fehler, fuer die wir teuer bezahlt haben.

Emulation ist kein Pentest: was Adversary Emulation wirklich misst

Ein Pentest sucht Schwachstellen und beweist Ausnutzbarkeit. Adversary Emulation stellt eine andere Frage: Reproduziert man eine konkrete Bedrohung Schritt fuer Schritt, sieht und stoppt die Verteidigung sie rechtzeitig? Das Ergebnis ist keine Liste von CVEs, sondern eine Detection-Bilanz pro Technik. Deshalb ist das Deliverable immer eine Tabelle aus ATT&CK-Technik, Ergebnis (still, alarmiert, geblockt) und Zeit bis zur Reaktion. Wer das mit einem Pentest verwechselt, kauft das falsche Produkt und misst am Ende die falsche Sache.

Der Wert entsteht aus Wiederholbarkeit. Dieselbe Emulation, monatlich gefahren, zeigt, ob neue Sigma-Regeln und EDR-Tuning die Erkennungsrate wirklich verbessern oder ob sich nur das Gefuehl verbessert hat. Ohne Baseline ist jede Aussage ueber 'bessere Sicherheit' Marketing. Ein einmaliger Jahres-Test liefert eine Momentaufnahme; eine monatliche Kadenz liefert eine Kurve, und nur die Kurve beantwortet die Frage, die der Vorstand wirklich stellt: Werden wir mit der Zeit besser oder treten wir auf der Stelle?

Das reproduzierbare Lab: acht Hosts, Proxmox und Terraform

Das Basis-Lab ist einfach und reproduzierbar: ein Windows Server 2022 als DC, zwei Server 2019 (Datei und SQL), drei Windows 11 Enterprise als Workstations mit Defender for Endpoint im Block-Modus und zwei Ubuntu 24.04 mit auditd und Wazuh-Agent. Alles auf Proxmox via Terraform orchestriert, Snapshots pro Szenariophase benannt. Wer die Windows-Seite von null aufbaut, sollte mit Active Directory Pentest: Kerberoasting Schritt fuer Schritt im GOAD Lab starten, das bereits absichtlich chaotische ACLs mitbringt, und dann das Pivoting aus Pivoting mit Chisel und Ligolo-ng: Segmentierte Netze im Pentest-Lab aufsetzen, um realistische VLAN-Segmentierung zu modellieren. Ohne diese Segmentierung ist jede Lateral-Movement-Detection-Metrik von Anfang an verzerrt.

Terraform ist hier kein Selbstzweck. Es garantiert, dass das Lab nach jeder Operation deterministisch aus dem gleichen Zustand hochfaehrt, sodass zwei Laeufe vergleichbar bleiben. Benannte Snapshots pro Phase erlauben es, genau zum Moment vor dem Lateral Movement zurueckzuspringen, wenn eine Detection-Frage offenbleibt. Wer das Lab von Hand aufbaut, kontaminiert unweigerlich den naechsten Lauf mit Resten des vorigen und kann am Ende nicht mehr sagen, ob eine Verhaltensaenderung von der neuen Regel oder vom schmutzigen Zustand kam. Reproduzierbarkeit ist deshalb keine Bequemlichkeit, sondern die Voraussetzung dafuer, dass die Metriken ueberhaupt etwas bedeuten.

Caldera als Gehirn: Adversary-YAML und ATT&CK-Mapping

Caldera wird zum Gehirn der Operation. Wir betreiben den Server auf einem isolierten Debian, laden die Plugins 'atomic' und 'stockpile' sowie unseren internen Fork 'basilisk-ttps', der regionale Verhaltensmuster wie AnyDesk-Missbrauch in KMU buendelt. Jeder Adversary in Caldera ist eine YAML-Datei, die ATT&CK-IDs zitiert: T1059.001 fuer PowerShell, T1021.006 fuer WinRM, T1003.001 fuer LSASS-Dump. Wir fuehren nie ungepruefte Standard-Adversaries aus; als Benchmark sind sie nuetzlich, der echte Wert entsteht aber durch Szenarien, die das Threat Model des Kunden abbilden. Ein Einzelhandel mit exponiertem Kassensystem verdient nicht den gleichen Adversary wie ein Fintech mit federiertem Azure AD und starker MFA.

Ein Adversary-Profil ist eine geordnete Sequenz von Abilities, jede mit einer ATT&CK-Referenz, einem Executor und einem Cleanup-Command. Diese Cleanup-Zeile ist nicht optional: Sie stellt sicher, dass der Host nach dem Lauf in einen bekannten Zustand zurueckkehrt, sonst kontaminiert der erste Test den zweiten. Wir versionieren jede YAML in git und reviewen sie wie Produktionscode.

Der Vier-Phasen-Ausfuehrungszyklus

Die Ausfuehrung folgt einem Vier-Phasen-Zyklus, den wir respektieren gelernt haben. Erstens simulierter Initial Access auf einem kontrollierten Endpoint, meist nach dem Playbook aus Initial Access Simuliert: Makros, LNK und ISO im Isolierten Windows-11-Lab mit einem von interner CA signierten Payload. Zweitens Execution und Discovery auf Basis von LOLBins, wobei das Material aus Hunting von Living-off-the-Land-Binaries unter Windows mit KQL dem Blue Team hilft, KQL-Abfragen vor dem Exercise parat zu haben. Drittens Lateral Movement ueber SMB und WinRM unter Ausnutzung schwacher Service-Accounts. Viertens Actions on Objectives, etwa SQL-Datenexfiltration oder simulierte Verschluesselung eines Shares.

Jede Phase hat ein klares Abbruchkriterium: Toetet der EDR den Prozess in unter 90 Sekunden, vermerken wir 'erkannt' und nehmen einen anderen Weg. Dieses harte Kriterium verhindert das haeufigste Selbstbetrugsmuster, bei dem der Operator so lange nachbessert, bis etwas durchgeht, und dann behauptet, die Kette sei durchgelaufen. Erkannt ist erkannt; das ist ein gutes Ergebnis fuer den Kunden, kein Misserfolg fuer das Team.

Blaue Seite: Instrumentierung, Telemetrie und die drei Metriken

Der langweilige, aber entscheidende Teil ist die Instrumentierung auf der blauen Seite. Ohne vergleichbare Telemetrie wird Adversary Emulation zum Theater. Wir rollen Sysmon mit der Olaf-Hartong-Config aus, schicken alles in einen Elastic-8.14-Cluster und wenden konvertierte Sigma-Regeln an, ein Workflow den wir in Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel detailliert beschrieben haben. Jedes von Caldera ausgeloeste Event bekommt einen Custom-Header x-caldera-op-id, sodass in Kibana abfragbar ist, welche Technik welche Events erzeugte und wie lange der Analyst zur Reaktion brauchte.

Die drei Metriken, die wir immer berichten: MTTD pro Technik, Detection Rate pro ATT&CK-Taktik und Anzahl neu geschriebener Sigma-Regeln als direkte Folge. Ohne diese drei Zahlen denkt der Kunde, er habe einen Pentest gekauft, und geht frustriert. Mit ihnen bekommt er eine Reifekurve, die er dem Vorstand zeigen und ueber Quartale verteidigen kann.

Ein konkreter Durchlauf: von der Ability bis zur Detektionsluecke

Ein typischer Lauf: Caldera stellt einen Sandcat-Agent per signiertem LNK zu, fuehrt T1059.001 (PowerShell-Discovery) aus, dann T1003.001 (LSASS-Zugriff ueber ein LOLBin statt Mimikatz, um die Signatur zu variieren), und pivotet per T1021.006 (WinRM) auf den Dateiserver. In einem realen Kundenlauf blieb der LSASS-Zugriff still, weil die vorhandene Sigma-Regel nur auf den Prozessnamen mimikatz.exe zielte statt auf den verdaechtigen Handle-Zugriff auf lsass.exe. Genau diese Luecke ist das Produkt: eine neue, verhaltensbasierte Regel, die am Ende des Berichts steht.

Wir vermerken pro Ability den Zeitstempel des Caldera-Events und den Zeitstempel des ersten korrelierten Alerts in Elastic. Die Differenz ist die MTTD dieser Technik. Aggregiert ueber die Taktik ergibt das die Detection Rate, die wir Quartal fuer Quartal gegen die Vorlaeufe halten.

Ethische und operative Fallen

Es gibt ethische und operative Fallen, die man benennen muss. Adversary Emulation ist kein Freibrief fuer EDR-Evasion gegen fremde Produktionsumgebungen; alles rund um Direct Syscalls oder AMSI-Patching bleibt im Lab, und wer die Begruendung sucht, kann EDR-Umgehung fur Forschung: Direct Syscalls Erklart ohne Romantik und AMSI- und ETW-Bypass fuer Defensive Forschung: Was Blue Teams Wissen Sollten lesen. Wir teilen auch nie C2-Infrastruktur zwischen Kunden; jede Operation erhaelt einen dedizierten Sliver-Teamserver gemaess C2-Infra mit Sliver im Isolierten Lab fur Defensive Forschung Aufbauen.

Jede Operation steht auf einer schriftlichen Autorisierung mit klarem Scope und Rules of Engagement. Ein destruktiver Schritt, etwa die simulierte Verschluesselung eines Shares, laeuft nur gegen dedizierte Lab-Daten und nie gegen Kundenproduktion. Diese Grenze ist nicht verhandelbar, auch nicht 'schnell mal ausprobieren'.

Reporting und der Purple-Team-Feedback-Loop

Der finale Report verknuepft jede TTP mit einer konkreten Gegenmassnahme und fuettert den Feedback-Loop aus Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus, damit der Exercise nicht im PDF-Friedhof endet. Fuer jede unentdeckte Technik liefern wir die vorgeschlagene Detektionslogik, nicht nur die Feststellung, dass es eine Luecke gibt. Das ist der Unterschied zwischen einem Bericht, der abgeheftet wird, und einem, der die Erkennungsrate im naechsten Lauf messbar hebt.

Der Loop schliesst sich, wenn die im Report vorgeschlagenen Regeln im naechsten Zyklus getestet werden. Genau darum ist die monatliche Kadenz wichtiger als ein grosser Jahres-Test: nur die Wiederholung beweist, dass die Verteidigung tatsaechlich dazugelernt hat.

FAQ: Wie unterscheidet sich Caldera von Atomic Red Team?

Atomic Red Team ist eine Bibliothek einzelner Test-Snippets pro Technik, ideal um punktuell zu pruefen, ob eine Detektion fuer T1003.001 existiert. Caldera orchestriert diese Bausteine zu einer zusammenhaengenden Kette mit einem Agenten, Planung und Cleanup, sodass eine ganze Angriffsstory ablaeuft. In der Praxis nutzen wir Atomic fuer schnelle Einzelvalidierung und Caldera fuer die vollstaendige, gescriptete Operation. Sie konkurrieren nicht, sie ergaenzen sich.

FAQ: Braucht man einen teuren EDR, damit das sinnvoll ist?

Nein. Der Sinn der Emulation ist gerade, zu messen, was die vorhandene Telemetrie liefert. Sysmon plus Elastic plus konvertierte Sigma-Regeln ist eine vollstaendig kostenlose Detektionsbasis, gegen die sich sinnvoll emulieren laesst. Ein teurer EDR verbessert oft die Rohdaten, aber ohne getestete Detektionslogik und geuebtes Blue Team bleibt er ein teures Log-Archiv. Wir haben Kunden gesehen, deren kostenloser Sysmon-Stack mit gepflegten Regeln mehr Techniken erkannte als ein sechsstelliger EDR, den niemand getunt hatte.

Praktisches Takeaway: klein anfangen, monatlich iterieren

Praktisches Takeaway: klein anfangen. Stell ein Caldera hoch, schreib einen Adversary mit fuenf ATT&CK-Techniken, die zu deinem echten Threat Model passen, lass ihn gegen drei ueberwachte Endpoints laufen und miss MTTD pro Technik. Wiederhole monatlich und tausche pro Zyklus eine Technik. In sechs Monaten hast du eine vor der Geschaeftsfuehrung verteidigbare Reifekurve, ohne ein einziges teures Tool neu einzukaufen, und dein SOC hoert auf zu meckern, dass in den Uebungen 'nie etwas passiert'.