Purple-Team-Übung mit Atomic Red Team: Erkennung testen statt hoffen

Eine Purple-Team-Übung mit Atomic Red Team ist der schnellste Weg, aus der Theorie einer Erkennungsregel die Gewissheit zu machen, dass sie funktioniert. Der Beitrag zu Red, Blue und Purple Team erklärt, warum diese Arbeitsweise die schnellste Rückkopplung liefert; dieser hier zeigt, wie sie konkret abläuft, mit dem Werkzeug, das den Einstieg am leichtesten macht. Du brauchst dazu weder ein externes Red Team noch teure Software, nur die frei verfügbare Testbibliothek, ein Homelab und ein paar Stunden. Der Beitrag beschreibt, was Atomic Red Team ist, wie du es sicher einrichtest, wie ein einzelner Test von der Ausführung bis zur Regel läuft, und wie du aus vielen solchen Tests eine ehrliche Abdeckungskarte baust.

Was Atomic Red Team ist

Atomic Red Team ist ein offenes Projekt von Red Canary: eine Sammlung von mehreren tausend kleinen, dokumentierten Tests, sortiert nach den Techniken von MITRE ATT&CK. Jeder Test, im Projekt „atomic“ genannt, bildet genau eine Technik oder Sub-Technik nach, mit einer klaren Beschreibung, den Voraussetzungen, dem auszuführenden Befehl und einer Aufräumanweisung. Ein Test für T1003.001 liest Zugangsdaten aus dem LSASS-Speicher, einer für T1053.005 legt eine geplante Aufgabe an, einer für T1558.003 führt Kerberoasting aus. Das Prinzip ist bewusst minimal: Ein Atomic tut eine Sache, damit du genau siehst, welche Spur sie erzeugt, statt in einem komplexen Angriffsszenario zu raten, welcher Schritt welchen Alarm ausgelöst hat. Ausgeführt werden die Tests über das PowerShell-Modul Invoke-AtomicRedTeam, das die Atomics auflöst, Voraussetzungen prüft, den Test startet und danach aufräumt.

Wichtig ist die Abgrenzung: Atomic Red Team emuliert Techniken, es ist kein Angriffswerkzeug im eigentlichen Sinn und keine Malware. Die Tests sind so gebaut, dass sie das nachbilden, was ein Angreifer täte, ohne echten Schaden anzurichten, und sie sind vollständig einsehbar. Trotzdem führen einige Tests reale Aktionen aus, etwa das Deaktivieren von Schutzfunktionen oder das Anlegen von Persistenz, und gehören deshalb ausschließlich ins Lab.

Sicher einrichten

• Nur im Lab. Die Tests laufen auf dem Windows-Client der Lab-Domäne aus dem Homelab-Bauplan, nie auf einem Produktivsystem und nie auf einem Rechner mit echten Daten. Das Lab-Netz ist vom Heimnetz getrennt.
• Snapshot vor jedem Test. Manche Atomics verändern das System dauerhaft. Ein Snapshot der VM vor dem Test und ein Rollback danach halten das Lab sauber; allein auf die Aufräumfunktion zu vertrauen reicht nicht, weil nicht jeder Test sie vollständig umsetzt.
• Schutzsoftware bewusst steuern. Wenn ein EDR oder Defender im Lab läuft, wird es manche Tests blockieren, und genau das ist ein Ergebnis: Der Test erreicht die höchste Bewertungsstufe, weil die Technik automatisch unterbunden wurde. Für Tests, bei denen du die reine Telemetrie sehen willst, lässt sich der Schutz gezielt und dokumentiert aussetzen, aber nur im isolierten Lab.
• Telemetrie steht. Bevor der erste Test läuft, müssen Sysmon, die Überwachungsrichtlinie mit Befehlszeile und die Anbindung an das SIEM funktionieren. Sonst testest du nicht deine Erkennung, sondern dein Logging, und das ist ein anderer Schritt.
• Installation. Das Modul Invoke-AtomicRedTeam wird per PowerShell installiert und lädt die Atomics in ein lokales Verzeichnis. Die Installationsanleitung im Projekt-Wiki beschreibt die Schritte; im Lab reicht die Standardinstallation.

Ein Test von Anfang bis Ende

Der Ablauf ist bei jeder Technik derselbe, hier am Beispiel Kerberoasting (T1558.003), dessen Erkennung im Beitrag Kerberoasting erkennen beschrieben ist.

1. Erwartung notieren. Vor dem Test wird aufgeschrieben, was er auslösen sollte: bei Kerberoasting ein Event 4769 mit Verschlüsselungstyp RC4 auf dem Domain Controller und ein Eintrag im kerberos.log des Sensors. Diese Erwartung ist der Maßstab; ohne sie prüfst du nicht, sondern schaust nur.
2. Test ansehen. Mit Invoke-AtomicTest T1558.003 -ShowDetails zeigt das Modul, was der Test tut, welche Voraussetzungen er hat und welchen Befehl er ausführt. Diesen Schritt überspringt man nie, weil man wissen muss, was gleich passiert.
3. Voraussetzungen erfüllen. Invoke-AtomicTest T1558.003 -GetPrereqs lädt oder erzeugt, was der Test braucht, etwa ein Dienstkonto mit SPN. Manches muss man von Hand vorbereiten, etwa mehrere Dienstkonten für den vollständigen Test.
4. Snapshot, dann ausführen. Snapshot der VMs, dann Invoke-AtomicTest T1558.003, und die Uhrzeit notieren. Das Notieren der Zeit ist der Schlüssel, um die Spur später im SIEM eindeutig wiederzufinden.
5. Im SIEM suchen. Kommt die erwartete Telemetrie an? Bei Kerberoasting: Steht das 4769 mit RC4 im Log, und schlägt die Regel an? Das Ergebnis ist eine der Bewertungsstufen aus dem Purple-Team-Beitrag: keine Telemetrie, geloggt aber nicht gefunden, per Suche gefunden aber kein Alarm, Alarm, oder automatisch unterbunden.
6. Regel schreiben oder nachschärfen. Fehlt die Regel, wird sie geschrieben, am besten als Sigma-Regel. Feuert sie nicht, wird geprüft, ob das Feld falsch geparst ist oder die Schwelle nicht passt.
7. Erneut testen. Derselbe Test noch einmal, und diesmal muss der Alarm kommen. Erst dann gilt die Technik als abgedeckt.
8. Aufräumen und eintragen. Invoke-AtomicTest T1558.003 -Cleanup, dann der Rollback des Snapshots, und das Ergebnis mit Datum in den ATT&CK Navigator.

Dieser Durchlauf dauert pro Technik zwanzig bis dreißig Minuten, wenn die Telemetrie steht, und er ist die kleinste vollständige Einheit einer Purple-Team-Übung: eine Technik, eine Messung, eine Verbesserung, eine erneute Messung.

Eine ganze Übung planen

Für eine Übung über einen halben oder ganzen Tag werden nicht wahllos Tests ausgeführt, sondern eine Auswahl, die zur eigenen Bedrohungslage passt. Die Quelle dafür ist die Threat Intelligence: Welche Angreifergruppen sind für die eigene Branche relevant, und welche Techniken nutzen sie? ATT&CK listet pro Gruppe die Techniken, und Atomic Red Team hat für die meisten einen Test. Daraus entsteht eine geordnete Liste, etwa entlang der Kill Chain: eine Technik für den ersten Zugang, eine für Ausführung, eine für Persistenz, eine für Credential Access, eine für seitliche Bewegung. Der Beitrag zu Purple Teaming enthält einen fertigen Tagesplan mit fünf Techniken und der Bewertungstabelle von 0 bis 5, der sich mit Atomic Red Team eins zu eins umsetzen lässt. Wer die Emulation ganzer Angriffsketten statt einzelner Techniken will, schaut sich MITRE Caldera an, das auf denselben Atomics aufsetzen kann; für den Einstieg und für sauberes Messen ist die einzelne Technik aber der bessere Weg.

Auswerten und wiederholen

Das Ergebnis einer Übung ist nicht das gute Gefühl, etwas getestet zu haben, sondern eine Tabelle: pro Technik die Bewertungsstufe vorher, die Maßnahme, die Bewertungsstufe nachher, der Verantwortliche. Diese Tabelle ist die ehrlichste Abdeckungskarte, die ein Blue Team bekommen kann, weil jeder Eintrag durch einen echten Test belegt ist und nicht durch die Annahme, eine Regel werde schon greifen. Über mehrere Übungen hinweg zeigt sie, ob die Erkennung wächst oder ob dieselbe Technik dreimal auf derselben Stufe stand, weil niemand die Regel geschrieben hat. Weil Erkennung altert, gehört jede Technik nach einigen Monaten erneut getestet: Ein Agenten-Update, eine geänderte Log-Konfiguration oder eine neue Softwareverteilung kann eine Regel still außer Kraft setzen, und nur der wiederholte Test findet das, bevor es ein Angreifer tut.

Typische Fehler

• Testen ohne Erwartung. Wer erst ausführt und dann schaut, was im Log steht, findet nicht heraus, was fehlt. Die erwartete Telemetrie gehört vor den Test.
• Testen gegen den Indikator statt das Verhalten. Wenn die Regel nur den Hash oder den Dateinamen des Testwerkzeugs fängt, besteht sie den Test und versagt beim echten Angriff mit anderem Werkzeug. Die Regel muss das Verhalten treffen.
• Nicht aufräumen. Ohne Rollback häufen sich Artefakte, und nach ein paar Übungen erkennt niemand mehr, was echt und was Testrückstand ist.
• Einmal und nie wieder. Eine Übung ist eine Momentaufnahme. Ohne Wiederholung ist die Abdeckungskarte nach dem nächsten Infrastruktur-Update veraltet.
• Ergebnis nicht dokumentieren. Eine Übung ohne Tabelle hinterlässt nichts außer Erinnerungen. Die Abdeckungskarte ist das Produkt.

Fazit

Atomic Red Team macht Purple Teaming für jedes Blue Team zugänglich, auch ohne eigenes Red Team: eine Bibliothek, ein PowerShell-Modul, ein Lab, und aus der Frage „erkennen wir das eigentlich“ wird eine gemessene Antwort. Der Wert liegt in der Disziplin des Ablaufs, Erwartung vor dem Test, Messung, Verbesserung, erneute Messung, und in der Tabelle, die daraus entsteht. Wer die Purple-Team-Übung so einmal im Quartal fährt und die Ergebnisse verfolgt, hat statt eines Bauchgefühls eine belegte Landkarte seiner Erkennung, und für ein Blue Team ist das der Unterschied zwischen hoffen und wissen.