
Von Lex Crumpton, MITRE ATT&CK: Sicherheitsverantwortliche weltweit greifen seit Jahren auf das MITRE ATT&CK-Framework zurück, um Angriffsverhalten besser zu verstehen und effektive Erkennungsmechanismen zu entwickeln. Die bisherigen „Detections“ im Framework lieferten dabei wertvolle Informationen – stießen aber zunehmend an ihre Grenzen.
Verhaltensweisen in Textform: ein Modell an der Belastungsgrenze
Das Problem: Die bisherigen Erkennungstexte bündelten oft mehrere Verhaltensweisen in einem einzigen Block. Für Verteidiger bedeutete das viel Interpretationsarbeit – insbesondere in komplexen IT-Landschaften mit unterschiedlichen Plattformen. Relevante Unterschiede zwischen Betriebssystemen und Anwendungen gingen dabei schnell verloren, und die präzise Zuordnung von gegnerischem Verhalten zu Log-Daten geriet zur Herausforderung.
Ein neues Kapitel: ATT&CK denkt Erkennung neu
Mit der Veröffentlichung von ATT&CK v18 läutet das Team nun eine grundlegende Weiterentwicklung ein. Im Zentrum steht die Einführung von drei neuen STIX Domain Objects (SDOs) und eines strukturierten Beziehungsmodells. Die bisherigen „Detection“-Elemente werden durch ein modulares, strategisch orientiertes System ersetzt, das gezielt auf die Verhaltensmuster von Angreifern, die Plattformdiversität und die wachsenden Anforderungen an skalierbare Sicherheitslösungen eingeht.
Zukunftssicher und praxisnah
Die neuen Erkennungsstrategien in ATT&CK dienen als flexible Blaupausen, die sich präzise an unterschiedliche Einsatzszenarien anpassen lassen – und damit sowohl Analysequalität als auch Automatisierungspotenzial erheblich steigern. Für Verteidiger bedeutet das einen wichtigen Schritt hin zu strukturierter, intelligenter Erkennung, die mit den Bedrohungen von heute und morgen Schritt halten kann.
Warum überhaupt eine Änderung?
Die Erkennungsstrategie war schon immer ein zentraler Bestandteil von ATT&CK, aber die Art und Weise, wie wir diese Leitlinien erfasst haben, spiegelte nicht immer die Praxis wider, wie Verteidiger, einschließlich uns, arbeiten. Frühere Versionen verwendeten das STIX-Feld „x_mitre_detection“ innerhalb einer Technik, um Erkennungsvorschläge zu beschreiben. Dadurch wurden Plattformen, Verhaltensweisen und Telemetriequellen in einem einzigen Absatz zusammengefasst, was die Automatisierung oder Anpassung an unterschiedliche Umgebungen erschweren konnte.
Image: T1027 Obfuscated Files or Information v10
„Später sind wir zu dem übergegangen, was derzeit in ATT&CK zu finden ist, wobei die Erkennungslogik so strukturiert ist, dass sie Beziehungen zwischen Datenkomponenten und Techniken erkennt. Dies trug dazu bei, den Zusammenhang zwischen Telemetrie und der Erkennung bestimmter Techniken hervorzuheben, aber die Beziehungen befanden sich in der Regel in unstrukturierten Beschreibungsfeldern, die nicht sichtbar waren und nicht eigenständig versioniert werden konnten. Dies hat zu einer zentralen Herausforderung geführt, da ATT&CK immer ausgereifter wurde: Einige unserer wertvollsten Erkenntnisse zur Erkennung gehen unter“, Lex Crumpton.
Image: T1027 Obfuscated Files or Information v17
Die x_mitre_detection_strategy
Diese Herausforderung hat uns dazu veranlasst, einen Schritt zurückzutreten und zu überlegen, wie wir die Erkennungsstrategie so erfassen können, dass sie tatsächlich widerspiegelt, wie Eindringlinge vorgehen und wie Verteidiger denken. Die meisten Erkennungen basieren auf isolierten Ereignissen: die Erstellung eines Prozesses, das Schreiben einer Datei, eine Netzwerkverbindung.
Aber Angreifer arbeiten nicht mit Einzeilern.
Bei modernen Erkennungsstrategien geht es nicht um Einzeiler, sondern um eine Reihe von Erkennungen. In der Praxis entfalten sich Eindringversuche über mehrere Ereignisse hinweg: Ein Prozess schreibt eine Datei in ein temporäres Verzeichnis -> diese Datei wird über eine bekannte Bibliothek verschlüsselt -> die Datei wird über einen verdächtigen Kanal exfiltriert.
Wir wussten, dass wir eine bessere Methode brauchten, um diese Art von Logik zu erfassen und auszudrücken. Deshalb haben wir das Erkennungsmodell nach einem einfachen Prinzip neu aufgebaut: Eine Erkennungsstrategie ist kein Satz, sondern ein System. Mit diesem neuen System haben wir die Erkennungslogik in modulare STIX-Objekte aufgeteilt, die jeweils über einen eigenen Lebenszyklus und eine eigene Versionskontrolle verfügen, auf bestimmte Plattformen zugeschnitten sind und logisch mit Verhaltensweisen, Telemetrie und Analysen verbunden sind. Die Objekte beschreiben, nach welchem Verhalten zu suchen ist, wo es in den Protokollen zu finden ist und wie die Erkennung an Ihre Umgebung angepasst werden kann.
Erkennungsstrategien erfassen nun diese Ketten von Ereignissen und Ursache-Wirkungs-Zusammenhängen und nicht mehr nur toolspezifische Signaturen. Jede Strategie dient als Blaupause. Sie sagt Ihnen nicht genau, wie Sie eine auf Ihre Umgebung zugeschnittene SIEM-Regel schreiben müssen, sondern gibt Ihnen folgende Informationen:
- Welches Verhalten zu beobachten ist
- Welche Protokolldaten Sie benötigen
- Welche Parameter anpassbar sind
- Welche Teile feststehen und ATT&CK-Techniken definieren
Table 1: New ATT&CK STIX Objects
Wichtige Änderungen an der Erkennungsarchitektur
Das Erkennungsstrategiemodell führt drei wesentliche Änderungen ein:
1. Verknüpfung von Erkennungsstrategien mit Techniken
Jedes x_mitre_detection_strategy-Objekt entspricht einer ATT&CK-Technik oder -Untertechnik und definiert, welches Verhalten des Angreifers es erkennen soll. Es enthält nicht die gesamte Erkennungslogik selbst, sondern verweist auf eine oder mehrere Analysen, die beschreiben, wie das Verhalten in verschiedenen Umgebungen erkannt werden kann.
2. Analysen sind plattformspezifisch und umsetzbar
Bisher wurde in Erkennungshinweisen versucht, das Verhalten unter Linux und Windows in einem einzigen Feld zu erklären. Jetzt ist jede Analyse plattformspezifisch und enthält direkte Verweise auf die erforderlichen Protokollquellen, Datenkomponenten und einstellbaren Erkennungsschwellenwerte. Das bedeutet, dass eine Erkennungsstrategie für T1048.001: Exfiltration über symmetrisch verschlüsseltes Protokoll Folgendes umfassen kann:
· AN-2301: Erkennung verschlüsselter Dateiübertragungen über SFTP unter Linux
· AN-2302: Erkennung von Nicht-C2-TLS-Exfiltration aus PowerShell unter Windows
3. Protokollquellen sind eindeutig und wiederverwendbar
Anstelle von „Sysmon verwenden“ definiert ATT&CK nun formale Protokollquellenobjekte, die plattformspezifische Permutationen enthalten:
Table 2: Log Source Example
Diese Protokollquellen werden dann über formale STIX-Beziehungen mit Datenkomponenten verknüpft, wodurch eine klare Kette vom Verhalten bis zur Telemetrie entsteht.
Jedes neue STIX-Objekt hat eine genau definierte Aufgabe:
Table 3: New ATT&CK STIX Fields
Mit diesen Feldern kann ATT&CK eine plattformspezifische Erkennungslogik für mehrere Ereignisse definieren, die abstrakt genug ist, um wiederverwendet werden zu können, und spezifisch genug, um umsetzbar zu sein.
So funktioniert das neue Erkennungsstrategiemodell in der Praxis, von der übergeordneten Strategie bis hin zu den einzelnen Erkennungskomponenten:
1. Jede Erkennungsstrategie umfasst drei Schlüsselelemente: eine Erkennungsstrategie-ID, einen Erkennungsstrategienamen und eine oder mehrere zugehörige Analyse-IDs.
Table 4: Detection Strategy Elements
2. Jede Analyse umfasst fünf Schlüsselelemente: ihre ID, Plattform, Erkennungsaussage, Protokollquelle und veränderbare Elemente, die plattformspezifische Logik, relevante Telemetriedaten und Optimierungsoptionen erfassen.
Table 5: Analytic Elements
3. Auf der nächsten Ebene definiert jede Protokollquelle ihren Namen, ihren Kanal und die zugehörige Datenkomponente. Mit veränderbaren Elementen können Sie Felder und Beschreibungen festlegen, mit denen Sie die Erkennungslogik an Ihre Umgebung anpassen können.
Table 6: Log Source and Mutable Elements
Jede Analyse umfasst einstellbare Schwellenwerte, Listen verdächtiger Tools oder Zeitfenster, um die Erkennungslogik anzupassen, ohne das Kernverhalten zu verändern.
Beispiel: T1027: Verschleierte Dateien oder Informationen
Tabelle 7: T1027 Verschleierte Dateien oder Informationen – Beispiel
Erkennungsstrategien Anwendungsfall
Angenommen, Ihr Team möchte T1053.002: Geplante Aufgabe/Job: Bei Ausführung unter Windows, Linux und macOS erkennen:
1. Rufen Sie DET-0084 ab, das mit folgenden Elementen verknüpft ist:
· AN-3121 für Windows (EventID 4698 + Dateischreiben in %SystemRoot%\Tasks)
· AN-3122 für Linux (cron-Protokoll + /var/spool/cron/ Dateischreiben)
· AN-3123 für macOS (launchd mit Dateiablage in ~/Library/LaunchAgents)
2. Überprüfen Sie, ob die relevanten Protokollquellen (LS-0033, LS-0037, LS-0039) erfasst sind.
3. Passen Sie die Schwellenwerte nach Bedarf an:
· Erweitern Sie TimeWindow auf 30 Minuten
· Markieren Sie Ausführungen außerhalb der Arbeitszeiten (UserContext: !System)
4. Testen Sie die Erkennungen mit einem Tool zur Emulation von Angreifern oder dem ATT&CK Workbench-Szenario-Runner.
Was Sie wahrscheinlich auch interessiert: Wie wirkt sich das auf mich aus?
Wir wissen, dass Veränderungen störend sein können, aber sie bieten auch die Gelegenheit, überlappende Erkennungslogiken zu bereinigen, Ihre Warnmeldungen zu optimieren und Ihre Erkennungen besser an die Vorgehensweisen von Angreifern in Umgebungen anzupassen. Wenn Sie Integrationen, Dashboards oder automatisierte Pipelines auf Basis von ATT&CK-Daten erstellt haben, sind Sie von diesem Update betroffen.
Wird dies meine bestehenden ATT&CK-Integrationen beeinträchtigen?
Wenn Sie auf x_mitre_detection, Beschreibungen mit einem relationship_type: „detects” oder x_mitre_data_sources angewiesen sind, ja.
Werden Datenquellen verschwinden?
Nicht vollständig. Sie werden in älteren Versionen von ATT&CK weiterhin vorhanden sein, aber nach Oktober 2025 werden wir stattdessen auf Log-Quellen umstellen.
Was passiert, wenn ich die aufgeführten Log-Quellen nicht habe?
Das ist kein Problem. Jede Erkennungsstrategie umfasst anpassbare Felder und plattformspezifische Optionen, sodass Sie die Logik an Ihre vorhandenen Gegebenheiten anpassen können.
Wie wirkt sich dies auf ATT&CK Workbench aus?
Workbench unterstützt standardmäßig die Erstellung und Visualisierung von x_mitre_detection_strategy-Objekten. Sie können die Abdeckung der Erkennungsstrategien über Taktiken, Plattformen und Datenerfassungen hinweg abbilden.
Wann erhalte ich Beispiel-STIX-Dateien zum Testen?
Eine Beispiel-STIX-Datei wird in der Woche vom 4. August verfügbar sein. Diese wird mit derselben Version von Workbench kompatibel sein.
Wo/wann kann ich das vollständige Schema einsehen?
Das vollständige Schema wird in derselben Woche – der Woche vom 4. August – zusammen mit Beispielcode, einer TypeScript-Parser-Bibliothek und Workbench-Updates, die Erkennungsstrategien unterstützen, verfügbar sein.
Abschließende Gedanken
„Wir haben viel aus der Herangehensweise der Community und unserer eigenen Teams an die Erkennung gelernt, und dieses Update spiegelt diese Erkenntnisse wider. Mit dem Übergang von einzeiligen Anleitungen zu strukturierten, verhaltensorientierten Strategien möchten wir ATT&CK benutzerfreundlicher, anpassungsfähiger und besser auf die tatsächlichen Vorgehensweisen von Angreifern abstimmen“, so Lex Crumpton abschließend.
Das neue Modell ist noch in Arbeit, und wir wissen, dass es immer Raum für Verbesserungen gibt. Aber wir glauben, dass es ein weiterer Schritt in die richtige Richtung ist, und wir freuen uns darauf, es mit Ihrem Feedback weiterzuentwickeln.
Wie Sie beitragen können
Dies ist kein Update hinter verschlossenen Türen, wir möchten Ihre Meinung hören!
Ganz gleich, ob Sie Lücken entdecken, großartige Ideen haben oder einfach nur neugierig sind, wie andere über dieses Update denken – Ihre Perspektive hilft uns dabei, die nächsten Schritte zu planen. Wir freuen uns über Ihre Rückmeldung unter attack@mitre.org, in unserem Slack oder besuchen Sie uns ATT&CKing Mondays dort, um Hilfe, Demos oder Unterstützung bei der Migration zu erhalten.
Quelle aller Grafiken: MITRE ATT&CK
Bild/Quelle: https://depositphotos.com/de/home.html
Fachartikel

Wenn Angreifer selbst zum Ziel werden: Wie Forscher eine Infostealer-Infrastruktur kompromittierten

Mehr Gesetze, mehr Druck: Was bei NIS2, CRA, DORA & Co. am Ende zählt

WinDbg-UI blockiert beim Kopieren: Ursachenforschung führt zu Zwischenablage-Deadlock in virtuellen Umgebungen

RISE with SAP: Wie Sicherheitsmaßnahmen den Return on Investment sichern

Jailbreaking: Die unterschätzte Sicherheitslücke moderner KI-Systeme
Studien

Deutsche Unicorn-Gründer bevorzugen zunehmend den Standort Deutschland

IT-Modernisierung entscheidet über KI-Erfolg und Cybersicherheit

Neue ISACA-Studie: Datenschutzbudgets werden trotz steigender Risiken voraussichtlich schrumpfen

Cybersecurity-Jahresrückblick: Wie KI-Agenten und OAuth-Lücken die Bedrohungslandschaft 2025 veränderten
![Featured image for “Phishing-Studie deckt auf: [EXTERN]-Markierung schützt Klinikpersonal kaum”](https://www.all-about-security.de/wp-content/uploads/2025/12/phishing-4.jpg)
Phishing-Studie deckt auf: [EXTERN]-Markierung schützt Klinikpersonal kaum
Whitepaper

ETSI veröffentlicht weltweit führenden Standard für die Sicherung von KI

Allianz Risk Barometer 2026: Cyberrisiken führen das Ranking an, KI rückt auf Platz zwei vor

Cybersecurity-Jahresrückblick: Wie KI-Agenten und OAuth-Lücken die Bedrohungslandschaft 2025 veränderten

NIS2-Richtlinie im Gesundheitswesen: Praxisleitfaden für die Geschäftsführung

Datenschutzkonformer KI-Einsatz in Bundesbehörden: Neue Handreichung gibt Orientierung
Hamsterrad-Rebell

Cyberversicherung ohne Datenbasis? Warum CIOs und CISOs jetzt auf quantifizierbare Risikomodelle setzen müssen

Identity Security Posture Management (ISPM): Rettung oder Hype?

Platform Security: Warum ERP-Systeme besondere Sicherheitsmaßnahmen erfordern

Daten in eigener Hand: Europas Souveränität im Fokus

















