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 mündeten. 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 berühren. Dieser Text beschreibt den Stack, den Ablauf und die Fehler, für die wir teuer bezahlt haben.

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-chisel-ligolo-rede-pentest]] aufsetzen, um realistische VLAN-Segmentierung zu modellieren. Ohne diese Segmentierung ist jede Lateral-Movement-Detection-Metrik von Anfang an verzerrt.

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 bündelt. Jeder Adversary in Caldera ist eine YAML-Datei, die ATT&CK-IDs zitiert: T1059.001 für PowerShell, T1021.006 für WinRM, T1003.001 für LSASS-Dump. Wir führen nie ungeprüfte Standard-Adversaries aus; als Benchmark sind sie nützlich, 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.

Die Ausführung 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 über SMB und WinRM unter Ausnutzung schwacher Service-Accounts. Viertens Actions on Objectives, etwa SQL-Datenexfiltration oder simulierte Verschlüsselung eines Shares. Jede Phase hat ein klares Abbruchkriterium: Tötet der EDR den Prozess in unter 90 Sekunden, vermerken wir 'erkannt' und nehmen einen anderen Weg.

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 ausgelöste 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.

Es gibt ethische und operative Fallen, die man benennen muss. Adversary Emulation ist kein Freibrief für EDR-Evasion gegen fremde Produktionsumgebungen; alles rund um Direct Syscalls oder AMSI-Patching bleibt im Lab, und wer die Begründung 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 erhält einen dedizierten Sliver-Teamserver gemäß C2-Infra mit Sliver im Isolierten Lab fur Defensive Forschung Aufbauen. Der finale Report verknüpft jede TTP mit einer konkreten Gegenmaßnahme und füttert den Feedback-Loop aus Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus, damit der Exercise nicht im PDF-Friedhof endet.

Praktisches Takeaway: klein anfangen. Stell ein Caldera hoch, schreib einen Adversary mit fünf ATT&CK-Techniken, die zu deinem echten Threat Model passen, lass ihn gegen drei überwachte Endpoints laufen und miss MTTD pro Technik. Wiederhole monatlich und tausche pro Zyklus eine Technik. In sechs Monaten hast du eine vor der Geschäftsführung verteidigbare Reifekurve, ohne ein einziges teures Tool neu einzukaufen, und dein SOC hört auf zu meckern, dass in den Übungen 'nie etwas passiert'.