Und Threat Detection: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Threat Detection im Purple Teaming ist kein Nebenprodukt eines Tests, sondern der eigentliche Kern der Zusammenarbeit zwischen offensiver und defensiver Perspektive. Während ein klassischer Penetrationstest oft mit dem Nachweis einer Schwachstelle endet, geht es hier darum, ob ein Angriffsschritt sichtbar wird, wie früh er erkannt wird, welche Telemetrie vorhanden ist und ob daraus belastbare Alarme oder Jagdhypothesen entstehen. Genau an dieser Stelle trennt sich oberflächliche Sicherheitsarbeit von belastbarer Verteidigungsfähigkeit.

Eine Detection ist nicht einfach eine Regel im SIEM. Eine brauchbare Detection besteht aus mehreren Schichten: Datenquelle, Datenqualität, Normalisierung, Kontext, Logik, Priorisierung, Alarmierung, Triage und Rückkopplung in den Betrieb. Wenn nur eine dieser Schichten schwach ist, entsteht entweder Blindheit oder Alarmmüdigkeit. Purple Teaming zwingt dazu, diese Kette unter realistischen Bedingungen zu prüfen. Deshalb ist die Verbindung zu Und Detection Engineering eng: Ohne saubere technische Umsetzung bleibt jede Erkenntnis aus dem Test folgenlos.

In der Praxis beginnt Threat Detection nicht mit einer Regel, sondern mit einer Annahme über Angreiferverhalten. Ein Beispiel: Ein Angreifer nutzt gestohlene Zugangsdaten, bewegt sich per Remote Management lateral und startet anschließend einen Credential-Dump. Die Frage lautet dann nicht nur, ob ein einzelner Prozess erkannt wird, sondern ob die gesamte Aktivitätskette sichtbar ist. Gute Purple-Teams prüfen deshalb nicht nur einzelne Events, sondern Sequenzen, Korrelationen und zeitliche Abfolgen.

Ein häufiger Denkfehler besteht darin, Detection mit Signaturerkennung gleichzusetzen. Moderne Angriffe variieren Werkzeuge, Dateinamen, Pfade und Ausführungsarten. Wer nur nach bekannten Hashes oder Prozessnamen sucht, verliert gegen minimale Anpassungen. Stabiler sind verhaltensbasierte Merkmale: ungewöhnliche Parent-Child-Beziehungen, verdächtige Token-Nutzung, atypische Authentifizierungssequenzen, Missbrauch administrativer Werkzeuge oder seltene Kombinationen aus Host- und Netzwerkereignissen. Diese Sichtweise ist auch für Und Threat Hunting entscheidend, weil Jagd und Detection auf denselben Datenfundamenten aufbauen.

Purple Teaming schafft dabei einen kontrollierten Raum, in dem Angriffe nicht nur simuliert, sondern für die Verteidigung zerlegt werden. Das Red Team oder der Operator erklärt, welche Technik eingesetzt wurde, welche Vorbedingungen nötig waren, welche Artefakte zu erwarten sind und welche Varianten denkbar wären. Das Blue Team prüft parallel, welche Datenquellen vorhanden sind, ob Felder korrekt ankommen, welche Regeln anschlagen und wo Lücken bestehen. So entsteht kein reines Testprotokoll, sondern ein verwertbarer Verbesserungszyklus.

Threat Detection muss außerdem immer in Relation zum Zielsystem betrachtet werden. Eine Office-Workstation, ein Domain Controller, ein Linux-Jump-Host, ein Kubernetes-Cluster oder ein OT-System erzeugen unterschiedliche Telemetrie und erfordern andere Erkennungslogiken. Wer detections ohne Systemkontext baut, produziert entweder blinde Flecken oder Fehlalarme. Purple Teaming ist deshalb besonders wirksam, wenn konkrete Use Cases und reale Betriebsbedingungen zugrunde liegen, nicht abstrakte Laborszenarien.

Der saubere Weg zu einer Detection beginnt mit einer Technik, nicht mit einer Suchabfrage. Ausgangspunkt ist eine klar definierte Angreiferhandlung: etwa PowerShell-Missbrauch, Kerberoasting, LSASS-Zugriff, WMI-Ausführung, Scheduled Tasks zur Persistenz oder Datenexfiltration über legitime Cloud-Dienste. Diese Technik wird dann in beobachtbare Signale übersetzt. Dabei hilft die Zuordnung zu Und Mitre Attack, weil sie Verhalten strukturiert und Vergleichbarkeit schafft. Entscheidend ist aber nicht das Mapping allein, sondern die Frage, welche konkreten Spuren im eigenen Stack tatsächlich entstehen.

Eine belastbare Detektionshypothese beantwortet mindestens vier Fragen: Welche Aktivität soll erkannt werden, welche Datenquellen sind dafür nötig, welche legitimen Prozesse sehen ähnlich aus und wie wird die Erkennung validiert. Viele Teams überspringen die dritte Frage. Genau dort entstehen später Fehlalarme. Wer etwa jede PowerShell-Ausführung alarmiert, wird im Unternehmensbetrieb scheitern. Wer dagegen nur auf stark obfuskierte Befehle, verdächtige EncodedCommand-Nutzung, ungewöhnliche Elternprozesse oder seltene Benutzerkontexte achtet, nähert sich einer praxistauglichen Detection.

Ein gutes Vorgehen ist die Zerlegung einer Technik in Primär- und Sekundärindikatoren. Primärindikatoren sind direkt mit der Handlung verbunden, etwa ein Prozesszugriff auf LSASS oder die Erstellung eines Scheduled Tasks. Sekundärindikatoren liefern Kontext, zum Beispiel die Herkunft des Prozesses, die Integritätsstufe, der Benutzer, die Session, die Hostrolle oder ein zeitlicher Zusammenhang mit einer verdächtigen Anmeldung. Erst die Kombination beider Ebenen macht eine Detection robust.

• Technik präzise definieren und Scope eingrenzen
• Benötigte Telemetrie und Feldverfügbarkeit prüfen
• Legitime Vergleichsfälle identifizieren und dokumentieren
• Regellogik gegen reale Testfälle und Varianten validieren

In Purple-Workshops zeigt sich oft, dass die Hypothese zwar fachlich korrekt ist, aber an der Datenrealität scheitert. Ein Beispiel: Die Detection soll verdächtige PowerShell-Parameter erkennen, doch im SIEM landet nur ein gekürzter CommandLine-Wert oder die Prozessdaten werden ohne Parent-Prozess ingestiert. Dann ist nicht die Idee falsch, sondern die Pipeline unvollständig. Genau deshalb muss Threat Detection immer mit Datenvalidierung gekoppelt werden. Wer nur Regeln schreibt, ohne die Rohdaten zu prüfen, arbeitet blind.

Ebenso wichtig ist die Variantenbildung. Eine Detection gegen einen einzelnen Proof of Concept ist wertlos, wenn schon kleine Änderungen sie umgehen. Deshalb sollte jede Hypothese mindestens gegen mehrere Ausführungsarten geprüft werden: interaktiv, remote, über Skript, über LOLBins, mit umbenannten Binärdateien oder mit leicht veränderten Parametern. Dieser iterative Ansatz ist eng mit Iteration verbunden und verhindert, dass eine Regel nur auf das Demo-Szenario passt.

Am Ende steht keine perfekte Erkennung, sondern eine bewusst dokumentierte Abdeckung mit bekannten Grenzen. Gute Teams halten fest, was sicher erkannt wird, was nur unter bestimmten Voraussetzungen sichtbar ist und welche Lestelemetrie noch fehlt. Diese Ehrlichkeit ist wichtiger als eine hohe Zahl vermeintlicher Detections, die im Ernstfall nicht tragen.

Jede Detection ist nur so gut wie die Telemetrie, auf der sie basiert. In realen Umgebungen ist die größte Schwachstelle selten die Regelsprache, sondern die Datenqualität. Felder fehlen, Timestamps sind verschoben, Hostnamen inkonsistent, Prozesspfade abgeschnitten, Benutzerkontexte unvollständig oder Events werden durch aggressive Filterung verworfen. Purple Teaming deckt diese Probleme zuverlässig auf, weil ein bekannter Angriffspfad gegen die vorhandene Sichtbarkeit gespiegelt wird.

Für Host-basierte Detection sind Prozessstarts, Parent-Child-Beziehungen, Kommandozeilen, Dateierstellungen, Registry-Änderungen, Treiberladungen, Netzwerkverbindungen, Authentifizierungsereignisse und Speicherzugriffe besonders wertvoll. Auf Netzwerkebene kommen DNS, Proxy, Firewall, NetFlow, TLS-Metadaten und gegebenenfalls IDS-Signale hinzu. In Identitätsdomänen sind Kerberos-, NTLM-, Azure- oder SSO-Logs oft entscheidend. Wer nur eine Ebene betrachtet, erkennt meist nur Fragmente.

Ein klassisches Beispiel ist Credential Access. Ein EDR kann einen verdächtigen Prozesszugriff auf LSASS sehen. Das SIEM korreliert dazu eine vorherige interaktive Anmeldung mit erhöhten Rechten. Netzwerkdaten zeigen parallel eine Verbindung zu einem Administrationssystem, das für den betroffenen Benutzer untypisch ist. Erst diese Zusammenführung ergibt ein belastbares Bild. Genau deshalb ist die Verzahnung mit Und Siem und Und Edr so wichtig.

Ein weiterer kritischer Punkt ist die Normalisierung. Unterschiedliche Datenquellen benennen dieselben Konzepte verschieden. Ein Benutzer kann als user, account, principal oder subject auftauchen. Hostnamen können FQDN, Kurzname oder Asset-ID sein. Wenn diese Unterschiede nicht sauber vereinheitlicht werden, scheitern Korrelationen trotz vorhandener Daten. Purple Teaming sollte deshalb immer auch prüfen, ob dieselbe Aktivität in verschiedenen Quellen konsistent referenzierbar ist.

Besonders problematisch sind stille Lücken. Dazu gehören Systeme ohne Sensor, Server mit veralteter Agent-Version, Container ohne ausreichende Auditierung, Domain Controller mit unvollständiger Event-Konfiguration oder Cloud-Workloads, deren Control-Plane-Logs zwar aktiviert, aber nicht zentral ausgewertet werden. Solche Lücken fallen im Tagesbetrieb oft nicht auf, weil niemand aktiv gegen sie testet. Im Purple-Teaming werden sie sichtbar, sobald eine Technik auf einem System ausgeführt wird und keinerlei verwertbare Spuren erzeugt.

Auch die Aufbewahrung und Suchbarkeit der Daten ist Teil der Detection-Fähigkeit. Wenn Rohdaten nur wenige Stunden verfügbar sind oder Felder im Index nicht durchsuchbar sind, scheitert die Analyse nachträglich. Das betrifft besonders Jagd- und Retrospektivanalysen. Eine Detection, die nur im Live-Moment funktioniert, aber nicht rückwirkend überprüfbar ist, bleibt operativ schwach.

Praktisch bewährt hat sich ein Telemetrie-Review vor jedem Purple-Szenario. Dabei wird nicht nur gefragt, welche Logs theoretisch vorhanden sind, sondern welche Felder konkret für die geplante Technik benötigt werden. Anschließend wird mit Testereignissen geprüft, ob diese Felder vollständig, zeitnah und korrekt ankommen. Erst danach lohnt sich die eigentliche Regelerstellung. Alles andere führt zu unnötigem Tuning auf einer instabilen Datenbasis.

Viele Detection-Programme scheitern daran, dass Regeln als isolierte Objekte behandelt werden. In Wirklichkeit braucht jede Detection eine Logikarchitektur. Dazu gehören Trigger, Filter, Kontextanreicherung, Schweregrad, Suppression, Korrelation und Eskalationspfad. Eine einzelne Query kann ein Signal erzeugen, aber noch keine belastbare operative Detection darstellen.

Ein Beispiel aus Windows-Umgebungen: Eine Regel sucht nach Prozessstarts von rundll32.exe mit ungewöhnlichen Parametern. Das kann sinnvoll sein, erzeugt aber ohne Kontext schnell Rauschen. Wird zusätzlich geprüft, ob der Parent-Prozess aus einem Office-Prozess stammt, ob der Benutzer nicht zur IT gehört, ob der Host kein Build-Server ist und ob kurz zuvor ein verdächtiger Download stattfand, steigt die Qualität deutlich. Detection ist also nicht nur Mustererkennung, sondern Kontextmodellierung.

Ein weiterer Fehler ist die Verwechslung von IOC- und TTP-Erkennung. IOCs wie Hashes, Domains oder Dateinamen sind nützlich, aber kurzlebig. TTP-basierte Logik überlebt Werkzeugwechsel besser. Wer etwa nicht nach mimikatz.exe sucht, sondern nach verdächtigen Speicherzugriffen, SeDebugPrivilege-Nutzung, LSASS-Handle-Öffnungen oder Dump-Artefakten, baut eine Detection, die auch gegen umbenannte oder modifizierte Werkzeuge Bestand hat.

In der Praxis sollten Detections in drei Ebenen gedacht werden. Die erste Ebene sind atomare Signale, etwa ein einzelnes Event. Die zweite Ebene sind zusammengesetzte Verhaltensmuster, zum Beispiel eine Folge aus Login, Prozessstart und Netzwerkverbindung. Die dritte Ebene ist die kampagnennahe Sicht, bei der mehrere Hosts, Identitäten oder Zeitfenster korreliert werden. Viele Teams bleiben auf Ebene eins stehen und wundern sich über hohe Fehlalarmraten oder geringe Aussagekraft.

Saubere Detektionslogik braucht außerdem Ausschlusslogik. Diese darf nicht aus pauschalen Whitelists bestehen, die ganze Benutzergruppen oder Hosts blind ausnehmen. Besser sind begründete Ausnahmen mit enger Bedingung: bestimmter Service-Account auf definierten Systemen, bekannte Wartungsfenster, signierte interne Tools oder klar dokumentierte Admin-Workflows. Zu breite Ausnahmen sind ein beliebter Angriffsraum, weil Angreifer genau dort untertauchen.

Ein praxistauglicher Workflow ist die Entwicklung einer Detection zunächst als Suchabfrage, dann als Testregel, danach als Alarm mit Triage-Hinweisen und schließlich als produktive Logik mit Metriken. Dieser Übergang wird oft übersprungen. Das Ergebnis sind Alarme ohne Bearbeitungshinweise, ohne Priorisierung und ohne Klarheit darüber, welche Reaktion erwartet wird. Gute Teams verknüpfen Detection deshalb früh mit Und Alerting und dem operativen Workflow.

Ein einfaches Beispiel für die Entwicklung einer atomaren Detection zu einer belastbaren Logik:

Use Case: Verdächtige PowerShell-Ausführung

Atomar:
- Prozessname = powershell.exe
- CommandLine enthält EncodedCommand

Verbessert:
- Prozessname = powershell.exe oder pwsh.exe
- EncodedCommand oder FromBase64String oder IEX
- Parent nicht explorer.exe in Admin-Kontexten allein bewerten
- Parent aus winword.exe, excel.exe, outlook.exe oder wscript.exe höher priorisieren
- Benutzer nicht in definierter Admin-Rolle
- Host ist keine bekannte Automatisierungsmaschine

Operativ:
- Alarm nur bei Kombination aus verdächtiger Kommandozeile + ungewöhnlichem Parent
- Triage-Hinweis: Benutzer, Parent, ScriptBlock, Netzwerkverbindungen, vorherige Downloads prüfen
- Response-Hinweis: Host isolieren nur bei zusätzlichem Netzwerk- oder Credential-Indikator

Diese Denkweise reduziert Rauschen und erhöht gleichzeitig die Aussagekraft. Entscheidend ist nicht die Länge der Query, sondern die Qualität der Annahmen hinter der Logik.

Die meisten Detection-Fehler sind keine exotischen Spezialprobleme, sondern wiederkehrende Muster. Einer der häufigsten Fehler ist die Jagd nach Toolnamen statt nach Verhalten. Das wirkt zunächst effizient, weil bekannte Werkzeuge schnell abgedeckt scheinen. In der Realität reicht eine Umbenennung, ein anderer Loader oder eine alternative Technik, und die Detection fällt aus. Purple Teaming deckt diese Schwäche schnell auf, wenn dieselbe Technik mit leicht veränderten Mitteln erneut ausgeführt wird.

Ebenso verbreitet ist die Annahme, dass vorhandene Logs automatisch brauchbar sind. Viele Teams bauen Regeln auf Feldern, die in Testdaten vorhanden waren, in Produktion aber unvollständig, gekürzt oder anders formatiert ankommen. Das führt zu stillen Ausfällen. Eine Regel kann syntaktisch korrekt sein und trotzdem nie sinnvoll feuern. Deshalb müssen Detections regelmäßig gegen Rohdaten und echte Ereignisse validiert werden.

Ein weiterer Fehler ist fehlende Baseline-Kenntnis. Ohne Verständnis für normales Verhalten lässt sich Anomalie kaum bewerten. Ein PowerShell-Aufruf auf einem Admin-Jump-Host ist etwas anderes als derselbe Aufruf auf einem Buchhaltungsrechner. Ein geplanter Task auf einem Patch-Server ist normal, auf einem Domain Controller unter einem Benutzerkonto dagegen hochverdächtig. Detection ohne Betriebsverständnis produziert entweder Rauschen oder gefährliche Blindheit.

• Regeln werden gegen Laborbedingungen gebaut und nie gegen Produktionsrealität geprüft
• Ausnahmen werden zu breit formuliert und schaffen blinde Zonen
• Alarme enthalten keine Triage-Hinweise und sind operativ kaum nutzbar
• Erfolg wird an Alarmanzahl statt an echter Abdeckung und Reaktionsfähigkeit gemessen

Sehr häufig fehlt auch die Rückkopplung aus dem Incident Handling. Wenn Analysten Alarme wiederholt als harmlos schließen, ohne dass die Detection angepasst wird, bleibt das Problem bestehen. Umgekehrt werden echte Funde oft nicht systematisch in neue Regeln übersetzt. Purple Teaming kann diese Lücke schließen, weil jede simulierte Technik sofort in eine konkrete Verbesserung überführt werden sollte. Das ist der praktische Kern von Detection Verbessern.

Ein besonders gefährlicher Fehler ist die Verwechslung von Sichtbarkeit und Erkennung. Nur weil ein Event im SIEM vorhanden ist, bedeutet das nicht, dass ein Angriff erkannt wird. Sichtbarkeit ist Voraussetzung, aber keine Detection. Erst wenn aus Daten eine belastbare, reproduzierbare und bearbeitbare Logik entsteht, kann von Erkennung gesprochen werden. Viele Reifegradbewertungen überschätzen die Verteidigung, weil sie diese Unterscheidung ignorieren.

Auch organisatorische Fehler wirken direkt auf die Detection-Qualität. Wenn Red Team, Blue Team, SOC und Engineering getrennt arbeiten, gehen Erkenntnisse verloren. Das Red Team dokumentiert Artefakte, aber niemand übersetzt sie in Regeln. Das SOC sieht Alarme, kennt aber die Angriffstechnik nicht im Detail. Engineering betreibt die Plattform, erhält aber keine priorisierten Anforderungen. Genau deshalb ist enge Collaboration keine weiche Zusatzdisziplin, sondern technische Notwendigkeit.

Schließlich scheitern viele Programme an fehlender Priorisierung. Nicht jede Technik braucht dieselbe Tiefe. Kritische Identitätssysteme, privilegierte Pfade, Domänenkontrolle, zentrale Managementsysteme und Exfiltrationskanäle verdienen zuerst robuste Detection. Wer Ressourcen gleichmäßig über alle denkbaren Techniken verteilt, erreicht oft nirgends ausreichende Qualität.

Threat Detection wird erst dann belastbar, wenn der Workflow zwischen den beteiligten Rollen sauber definiert ist. In vielen Organisationen endet ein Purple-Test mit einer Liste von Findings. Das reicht nicht. Benötigt wird ein Ablauf, der von der Technikdefinition über die Ausführung bis zur produktiven Detection führt. Jede Rolle hat dabei eine klare Aufgabe.

Das Red Team oder der Operator beschreibt die Technik präzise: Ziel, Voraussetzungen, Ausführungsweg, Varianten, erwartete Artefakte und mögliche Umgehungen. Das Blue Team bewertet Sichtbarkeit und formuliert erste Hypothesen. Das SOC prüft, ob bestehende Alarme anschlagen, wie die Triage abläuft und welche Informationen im Alarm fehlen. Detection Engineering oder Plattformverantwortliche setzen die Logik technisch um, testen sie und bringen sie kontrolliert in Produktion. Ohne diese Kette bleiben Erkenntnisse fragmentiert.

Ein praxistauglicher Ablauf orientiert sich an kurzen Zyklen. Statt einen großen Test über Wochen im Verborgenen laufen zu lassen, werden einzelne Techniken oder kleine Angriffsketten transparent durchgeführt, sofort ausgewertet und direkt nachgebessert. Das beschleunigt Lernen und verhindert, dass Erkenntnisse erst am Ende eines Projekts versanden. Diese Arbeitsweise passt gut zu Prozess und Ablauf, wenn beide auf operative Umsetzung ausgerichtet sind.

Wichtig ist die Trennung zwischen Testdurchführung und Produktionsänderung. Während des Tests kann eine Detection provisorisch als Suchabfrage oder temporäre Regel laufen. Die produktive Übernahme sollte aber denselben Qualitätskriterien folgen wie andere Sicherheitsänderungen: Review, Test gegen bekannte Positiv- und Negativfälle, Dokumentation, Rollout und Nachkontrolle. Sonst entstehen hektisch gebaute Regeln, die später niemand mehr versteht.

Ein sauberer Workflow enthält außerdem feste Übergabepunkte. Nach jeder Technik sollten mindestens folgende Fragen beantwortet sein: Wurde die Aktivität gesehen, wurde sie alarmiert, war der Alarm verständlich, konnte ein Analyst sinnvoll reagieren, welche Daten fehlten, welche Regeländerung ist nötig, wer setzt sie bis wann um und wie wird die Wirksamkeit erneut geprüft. Wenn diese Fragen offen bleiben, war der Test technisch interessant, aber operativ wirkungslos.

Kommunikation ist dabei nicht nur Statusaustausch, sondern Teil der technischen Qualität. Wenn das Blue Team nicht weiß, welche Variante tatsächlich ausgeführt wurde, kann es Fehlinterpretationen geben. Wenn das Red Team nicht erfährt, welche Felder fehlen, kann es keine sinnvollen Alternativpfade testen. Wenn das SOC keine Rückmeldung zur Alarmnutzbarkeit gibt, bleibt die Detection theoretisch. Deshalb muss Communication konkret, zeitnah und artefaktbasiert sein.

In reifen Teams werden diese Übergänge in Playbooks gegossen. Für jede Technik gibt es definierte Testschritte, erwartete Datenquellen, Suchabfragen, Triage-Fragen, Eskalationskriterien und Nachbesserungsaufgaben. Das reduziert Reibung und macht Fortschritt messbar, ohne in starre Bürokratie zu kippen.

Ein realistisches Beispiel ist die Ausführung von Befehlen über WMI oder PsExec in einer Windows-Domäne. Eine schwache Detection sucht nur nach dem Prozessnamen psexec.exe. Das ist leicht zu umgehen und übersieht alternative Werkzeuge oder native Remote-Management-Wege. Eine bessere Detection betrachtet Service-Erstellung auf Zielsystemen, Remote-Prozessstarts, verdächtige Admin-Freigaben, Logon-Typen, neue Dienste mit ungewöhnlichen Binärpfaden und die zeitliche Nähe zu privilegierten Anmeldungen. Noch besser wird sie, wenn Host- und Identitätsdaten korreliert werden.

Ein zweites Beispiel ist Datenexfiltration. Schlechte Detection alarmiert auf große Datenmengen ins Internet. Das ist zu grob und erzeugt in vielen Umgebungen Rauschen. Gute Detection verbindet Dateizugriffe auf sensible Pfade, Archivierungsaktivitäten, ungewöhnliche Nutzung von Cloud-Sync-Tools, seltene Ziel-Domains, Abweichungen vom Benutzerprofil und gegebenenfalls DLP- oder Proxy-Kontext. Purple Teaming kann hier sehr gezielt prüfen, welche Kombinationen tatsächlich sichtbar sind und welche Exfiltrationswege unbemerkt bleiben.

Auch bei Credential Access zeigt sich der Unterschied deutlich. Eine schlechte Regel sucht nach einem bekannten Toolnamen. Eine brauchbare Detection erkennt verdächtige Handle-Zugriffe auf LSASS, Speicher-Dumps in atypischen Pfaden, Nutzung bestimmter API-Muster, nachgelagerte Dateizugriffe auf Dump-Dateien und die Ausführung unter ungewöhnlichen Benutzerkontexten. Wenn zusätzlich korreliert wird, ob kurz danach neue privilegierte Anmeldungen auftreten, steigt die Aussagekraft weiter.

Ein typischer Purple-Test für solche Szenarien läuft in Stufen. Zuerst wird die Technik in einer einfachen Variante ausgeführt, um Basis-Sichtbarkeit zu prüfen. Danach folgen Varianten mit anderen Parametern, anderen Elternprozessen oder alternativen Werkzeugen. Anschließend wird bewertet, welche Teile der Aktivität erkannt wurden und welche nicht. Daraus entstehen konkrete Verbesserungen für Regeln, Telemetrie oder Triage.

Beispiel für eine einfache Validierung einer verdächtigen Scheduled-Task-Persistenz:

Testziel:
- Erkennen der Erstellung geplanter Tasks durch Benutzerkontext auf Workstations

Zu prüfen:
- Event zur Task-Erstellung vorhanden
- Benutzername vollständig vorhanden
- Taskname und Taskpfad erfasst
- Auszuführender Befehl sichtbar
- Parent-Prozess des auslösenden Tools vorhanden
- Alarm nur auf Workstations, nicht auf bekannten Management-Servern

Varianten:
- schtasks.exe lokal
- schtasks.exe remote
- PowerShell Register-ScheduledTask
- XML-Import eines Tasks

Solche Beispiele zeigen, warum reine Tool-Demos wenig bringen. Erst die Variation und die Auswertung der Datenqualität machen aus einem Test verwertbares Detection-Wissen. Für weitere praktische Angriffspfade sind Use Cases und Beispiele besonders nützlich, wenn sie nicht nur die Technik, sondern auch die Verteidigungsperspektive mitdenken.

Ein guter Indikator für Reife ist, ob ein Team nach dem Test nicht nur sagen kann, dass eine Technik ausgeführt wurde, sondern exakt benennen kann, welche Signale entstanden, welche Regel gegriffen hat, welche Felder im Alarm standen, wie lange die Triage dauerte und welche Verbesserung als Nächstes umgesetzt wird.

Detection Tuning ist kein kosmetischer Schritt nach der Regelerstellung, sondern Teil der eigentlichen Engineering-Arbeit. Ziel ist nicht, möglichst viele Alarme zu erzeugen, sondern ein sinnvolles Verhältnis aus Sensitivität, Präzision und operativer Nutzbarkeit zu erreichen. Eine Detection, die jeden Tag dutzendfach falsch positiv feuert, wird ignoriert. Eine Detection, die nur unter idealen Bedingungen anschlägt, ist ebenso wertlos.

Sauberes Tuning beginnt mit Testdaten. Für jede Detection sollten bekannte Positivfälle, legitime Vergleichsfälle und möglichst auch Umgehungsvarianten vorliegen. Nur so lässt sich beurteilen, ob eine Regel wirklich auf das gewünschte Verhalten reagiert oder nur auf zufällige Begleitmerkmale. Purple Teaming liefert genau diese Testfälle, wenn Angriffe kontrolliert und reproduzierbar ausgeführt werden.

Wichtig ist die Unterscheidung zwischen False Positives, False Negatives und Low-Value Alerts. False Positives sind harmlose Ereignisse, die fälschlich als verdächtig markiert werden. False Negatives sind verpasste Angriffe. Low-Value Alerts liegen dazwischen: technisch korrekt, aber ohne ausreichenden Kontext für eine sinnvolle Reaktion. Gerade diese dritte Kategorie wird oft übersehen, obwohl sie Analystenzeit bindet und Vertrauen in die Detection schwächt.

• Jede Detection braucht definierte Positiv- und Negativtestfälle
• Alarmtexte müssen Triage-relevante Felder und nächste Prüfschritte enthalten
• Änderungen an Regeln sollten gegen historische Daten und neue Testläufe geprüft werden
• Metriken müssen Abdeckung und Bearbeitbarkeit messen, nicht nur Alarmvolumen

Bei Metriken sind einfache Zahlen oft irreführend. Eine hohe Zahl neuer Regeln sagt nichts über Qualität aus. Auch Mean Time to Detect ist nur begrenzt aussagekräftig, wenn die Detection zwar schnell feuert, aber unklar oder unbrauchbar ist. Sinnvoller sind Metriken wie: Anteil getesteter Techniken mit verwertbarer Detection, Anteil der Detections mit dokumentierten Testfällen, Zeit bis zur produktiven Umsetzung einer Verbesserung, Anteil der Alarme mit ausreichendem Kontext für Ersttriage und Wiederholungsrate identischer Fehlalarme nach Tuning.

Validierung sollte außerdem regelmäßig wiederholt werden. Plattformupdates, Parseränderungen, neue Agent-Versionen, geänderte Log-Policies oder Infrastrukturmigrationen können funktionierende Detections unbemerkt beschädigen. Reife Teams führen deshalb Regressionstests für kritische Detections durch. Das kann manuell, skriptbasiert oder über kontrollierte Emulation geschehen. Entscheidend ist, dass Detection nicht als einmaliges Projekt verstanden wird.

Auch die Dokumentation gehört zum Tuning. Für jede produktive Detection sollte nachvollziehbar sein, welche Technik sie abdeckt, welche Datenquellen nötig sind, welche bekannten Schwächen existieren, welche Ausnahmen gelten und wie die Wirksamkeit zuletzt geprüft wurde. Diese Transparenz ist die Grundlage für belastbares Reporting und sinnvolle Metriken.

Wer Tuning ernst nimmt, akzeptiert auch, dass manche Detections bewusst nur als Jagd-Query oder Kontextsignal betrieben werden sollten. Nicht jedes Muster eignet sich für einen produktiven Alarm. Diese Entscheidung ist kein Scheitern, sondern Ausdruck technischer Reife.

In hybriden Umgebungen wird Threat Detection deutlich komplexer, weil sich Angriffe über mehrere Ebenen bewegen. Ein initial kompromittierter Endpunkt kann zu einem Identitätsmissbrauch führen, der wiederum Cloud-Ressourcen betrifft. Wer Detection nur lokal auf dem Host oder nur zentral im SIEM betrachtet, verpasst die Übergänge. Purple Teaming ist hier besonders wertvoll, weil es genau diese Ketten sichtbar macht.

Auf Endpunkten liefern EDR-Sensoren oft die feinste Telemetrie. Sie sehen Prozesse, Module, Speicherzugriffe, Registry, Dateisystem und Netzwerkverbindungen. In Identitätssystemen sind Anmeldemuster, Token-Nutzung, MFA-Ereignisse, Rollenwechsel und ungewöhnliche Zugriffsorte entscheidend. In Cloud-Umgebungen kommen API-Aufrufe, Rollenannahmen, Policy-Änderungen, Storage-Zugriffe und Control-Plane-Ereignisse hinzu. Gute Detection verbindet diese Ebenen, statt sie getrennt zu behandeln.

Ein Beispiel: Ein Angreifer stiehlt auf einem Endpunkt Browser-Tokens oder Session-Artefakte, nutzt diese für Cloud-Zugriffe und legt dort Persistenz über Rollen oder App-Registrierungen an. Eine rein hostbasierte Detection sieht nur den Diebstahlversuch, eine rein cloudbasierte Detection nur die Folgeaktivität. Erst die Korrelation ergibt das Gesamtbild. Deshalb muss Threat Detection in modernen Umgebungen immer auch Integrationsarbeit sein.

In Cloud- und Containerlandschaften kommt hinzu, dass klassische Hostartefakte teilweise fehlen oder kurzlebig sind. Container starten und verschwinden, Serverless-Funktionen erzeugen andere Spuren als klassische Server, API-Missbrauch hinterlässt keine typischen Prozessketten. Hier müssen Detections stärker auf Identität, Konfiguration, API-Verhalten und Laufzeitmetadaten setzen. Wer nur traditionelle Windows- oder Linux-Muster überträgt, erkennt wenig.

Auch in hybriden Landschaften bleibt die Frage nach Datenqualität zentral. Unterschiedliche Zeitzonen, verschiedene Identitätsquellen, wechselnde Asset-Bezeichner und asynchrone Log-Lieferung erschweren Korrelationen. Purple Teaming sollte deshalb gezielt Übergänge testen: Endpunkt zu Identität, Identität zu Cloud, On-Prem zu SaaS, Admin-Workstation zu Managementsystem. Genau dort liegen oft die größten Erkennungslücken.

Für Teams, die ihre Detection-Fähigkeit ausbauen wollen, lohnt sich die enge Verzahnung mit Und Xdr, In Cloud Umgebungen und Und Log Analyse. Entscheidend ist aber nicht das Produktlabel, sondern die Fähigkeit, Ereignisse über Domänengrenzen hinweg technisch sauber zusammenzuführen.

Reife Detection in realen Umgebungen erkennt nicht nur einzelne verdächtige Aktionen, sondern Übergänge zwischen Kontrollbereichen. Genau diese Übergänge sind für Angreifer attraktiv, weil dort Verantwortlichkeiten, Datenmodelle und Sichtbarkeiten oft auseinanderfallen.

Ein reifes Detection-Programm im Purple Teaming zeichnet sich nicht durch möglichst viele Regeln aus, sondern durch nachvollziehbare Abdeckung, reproduzierbare Validierung und klare operative Nutzbarkeit. Für kritische Angriffspfade existieren definierte Techniken, bekannte Datenquellen, getestete Detections, dokumentierte Grenzen und feste Verantwortlichkeiten für Pflege und Verbesserung. Das Ziel ist nicht Vollständigkeit auf dem Papier, sondern belastbare Erkennung dort, wo ein Angreifer realen Schaden anrichten würde.

Ein gutes Zielbild umfasst mehrere Ebenen. Erstens gibt es priorisierte Angriffspfade, etwa Identitätskompromittierung, laterale Bewegung, Privilegienausweitung, Persistenz auf Schlüsselservern und Exfiltration sensibler Daten. Zweitens sind für diese Pfade die relevanten Telemetriequellen technisch abgesichert. Drittens existieren Detections mit Testfällen, Triage-Hinweisen und dokumentierten Ausnahmen. Viertens werden diese Detections regelmäßig durch Purple-Übungen, Emulation oder Regressionstests überprüft. Fünftens fließen Ergebnisse systematisch in Engineering und Betrieb zurück.

Wichtig ist auch die Fähigkeit, Grenzen offen zu benennen. Manche Techniken lassen sich nur mit zusätzlicher Telemetrie erkennen, andere nur mit hohem Rauschanteil, wieder andere eher über Jagd als über Alarmierung. Reife bedeutet, diese Unterschiede zu kennen und bewusst zu steuern. Unrealistische Vollabdeckungsversprechen schaden mehr, als sie nützen.

Ein belastbares Zielbild beinhaltet außerdem die Trennung von drei Fragen: Was ist sichtbar, was ist erkennbar und was ist bearbeitbar. Sichtbar bedeutet, dass Daten vorhanden sind. Erkennbar bedeutet, dass eine Logik daraus ein Signal erzeugen kann. Bearbeitbar bedeutet, dass ein Analyst aus dem Alarm heraus sinnvoll handeln kann. Erst wenn alle drei Ebenen erfüllt sind, entsteht echte Verteidigungsfähigkeit.

In der Praxis hilft ein wiederkehrender Zyklus: priorisieren, emulieren, messen, verbessern, erneut testen. Dieser Zyklus ist die operative Form von Methodik und Best Practices. Er verhindert, dass Threat Detection zu einer Sammlung statischer Regeln verkommt, die mit der Umgebung nicht mitwächst.

Wer Threat Detection im Purple Teaming ernst nimmt, betrachtet jede erkannte oder verpasste Technik als Lernsignal über die eigene Verteidigung. Nicht die einzelne Regel ist der eigentliche Wert, sondern die Fähigkeit, aus kontrollierten Angriffen schnell robuste Erkennung zu bauen. Genau daraus entsteht mit der Zeit ein Sicherheitsprogramm, das nicht nur auf bekannte Muster reagiert, sondern Angreiferverhalten systematisch in sichtbare, priorisierte und bearbeitbare Signale übersetzt.