MITRE ATT&CK für Verteidiger: Taktiken, Techniken und wie du damit Erkennungslücken findest

MITRE ATT&CK ist die gemeinsame Sprache der Verteidiger: ein frei verfügbarer Katalog der Taktiken und Techniken, die Angreifer in echten Vorfällen tatsächlich verwendet haben. Wer ihn beherrscht, kann Threat-Intelligence-Berichte lesen, Alarme einordnen, Erkennungsregeln priorisieren und vor allem eine Frage beantworten, die sich sonst niemand traut: Welche Angriffstechniken würden wir überhaupt sehen? In diesem Beitrag erfährst du, wie ATT&CK aufgebaut ist, was sich mit Version 18 für Verteidiger geändert hat, wie Blue Teams damit arbeiten und wie du in fünf Schritten zu einer ehrlichen Abdeckungskarte kommst.

Was MITRE ATT&CK ist

ATT&CK steht für Adversarial Tactics, Techniques and Common Knowledge. Die gemeinnützige MITRE Corporation pflegt die Wissensbasis seit Mitte der 2010er-Jahre gemeinsam mit der Community, sie ist kostenlos und wird zweimal im Jahr aktualisiert. Der Kern ist eine Matrix: Spalten sind die Taktiken, also die Ziele eines Angreifers in den einzelnen Phasen, Zeilen darunter die Techniken, mit denen er diese Ziele erreicht. Es gibt drei Matrizen: Enterprise (Windows, Linux, macOS, Cloud, Netzwerkgeräte, Container), Mobile und ICS für industrielle Steuerungssysteme. Für die meisten Blue Teams ist Enterprise die relevante.

Der entscheidende Unterschied zu anderen Modellen wie der Cyber Kill Chain: ATT&CK beschreibt nicht, was Angreifer theoretisch tun könnten, sondern was in dokumentierten Vorfällen beobachtet wurde. Jede Technik ist mit Quellen belegt, mit den Gruppen, die sie einsetzen, und mit der Software, die dafür verwendet wird.

Der Aufbau: Taktiken, Techniken, Prozeduren

Die Enterprise-Matrix kennt 14 Taktiken. Sie lesen sich grob wie der Ablauf eines Angriffs, wobei ein echter Angriff selten alle durchläuft und oft zwischen ihnen springt:

Unter jeder Taktik hängen Techniken mit einer ID, etwa T1003 für OS Credential Dumping unter Credential Access. Viele Techniken haben Sub-Techniken, die konkreter werden: T1003.001 ist das Auslesen von Zugangsdaten aus dem Speicher des LSASS-Prozesses. Die Prozeduren beschreiben schließlich, wie eine bestimmte Gruppe oder ein bestimmtes Werkzeug diese Technik ausführt. Dazu kommen Gruppen (G-IDs), Software (S-IDs) und Mitigations (M-IDs), also Gegenmaßnahmen, die eine Technik erschweren.

Diese Hierarchie ist der Grund, warum ATT&CK für Verteidiger so brauchbar ist: Eine Erkennungsregel, die auf das Verhalten hinter T1003.001 zielt, erkennt die Technik unabhängig davon, welches Werkzeug der Angreifer benutzt. Wer nur den Hash von Mimikatz blockt, verliert beim nächsten umbenannten Binary.

Was sich mit Version 18 für Verteidiger geändert hat

Bis Version 17 stand bei jeder Technik ein kurzer Absatz „Detection“ mit allgemeinen Hinweisen und einer Liste von Datenquellen. Für Detection Engineers war das zu vage. Mit Version 18 vom Oktober 2025 hat MITRE die Erkennungsseite komplett umgebaut. Zwei neue Objekte ersetzen die alten Hinweise: Detection Strategies beschreiben, welches Verhalten zu beobachten ist, oft als Kette mehrerer Ereignisse über Taktiken hinweg; Analytics beschreiben pro Plattform, wie sich dieses Verhalten in der Telemetrie zeigt, und verweisen auf konkrete Logquellen und Datenkomponenten.

Für die Praxis heißt das: Statt „Prozesserstellung überwachen“ steht bei einer Technik jetzt, welche Ereignisse in welcher Reihenfolge auf welcher Plattform auffällig sind und welche Parameter du an deine Umgebung anpassen musst. Das ist keine fertige SIEM-Regel, aber der Bauplan dafür. Wer heute Erkennungsregeln schreibt, sollte mit der Detection Strategy der jeweiligen Technik anfangen, nicht mit einem leeren Editor.

Wie Blue Teams mit MITRE ATT&CK arbeiten

• Gemeinsame Sprache. Alarme, Threat-Intelligence-Berichte, Pentest-Ergebnisse und Vorfallberichte tragen Technik-IDs. Wenn der Bericht „T1566.001“ sagt, weiß jeder im Team, dass es um Phishing mit Anhang geht, und kann prüfen, ob es dafür eine Regel gibt.
• Priorisieren mit Threat Intelligence. Welche Gruppen greifen deine Branche an, und welche Techniken nutzen sie? ATT&CK listet das pro Gruppe. Aus der Schnittmenge ergibt sich, welche Techniken zuerst erkannt werden müssen.
• Erkennung planen. Sigma-Regeln und die meisten SIEM-Inhalte sind mit ATT&CK-IDs getaggt. So lässt sich für jede Technik nachvollziehen, ob und womit sie im SIEM abgedeckt ist.
• Üben. Testbibliotheken wie Atomic Red Team sind nach Techniken sortiert. Eine Purple-Team-Übung nimmt sich eine Technik nach der anderen vor und prüft, ob die Erkennung greift.
• Vorfälle beschreiben. Eine Zeitlinie, in der jeder Schritt einer Technik zugeordnet ist, zeigt im Incident-Response-Prozess sofort, wo die Erkennung hätte greifen müssen und wo die Lücke liegt.

In fünf Schritten zur Abdeckungskarte

Das Werkzeug dafür ist der ATT&CK Navigator, eine freie Webanwendung, in der du die Matrix einfärben, kommentieren und als Layer speichern kannst.

1. Logquellen auflisten. Welche Daten hast du wirklich: Domain Controller, Endpunkt-Telemetrie, Cloud-Identität, Netzwerk? Was nicht geloggt wird, kann nicht erkannt werden, egal was der Hersteller verspricht.
2. Sichtbarkeit einfärben. Für jede Technik: Liefern deine Quellen die nötige Telemetrie? Ab Version 18 steht das bei den Analytics der Technik. Das ist der erste Layer.
3. Erkennung einfärben. Für jede sichtbare Technik: Gibt es eine Regel, und wurde sie getestet? Das ist der zweite Layer, und er ist fast immer kleiner als der erste.
4. Mit der Bedrohung abgleichen. Die Techniken der für dich relevanten Gruppen als dritter Layer darüber. Wo Bedrohung ohne Erkennung liegt, ist die Prioritätenliste.
5. Lücken schließen und wiederholen. Fehlende Logquelle anbinden oder Regel schreiben, per Übung prüfen, Layer aktualisieren. Nach jeder größeren Änderung an der Infrastruktur von vorn.

Der Navigator Schritt für Schritt

Die fünf Schritte oben werden im Navigator zu Handgriffen, die nach einer halben Stunde sitzen. Der Navigator läuft im Browser, speichert nichts auf einem Server und lässt sich für den internen Gebrauch auch selbst hosten.

1. Layer anlegen. „Create New Layer“, Domäne Enterprise, aktuelle Version. Der Layer bekommt einen Namen wie „Sichtbarkeit 2026-09“ und eine Beschreibung mit dem Stand der Logquellen.
2. Bewertung festlegen. Eine einfache Skala, die das ganze Team versteht: 0 für keine Telemetrie, 1 für Telemetrie vorhanden, 2 für Regel vorhanden, 3 für Regel getestet. Im Navigator wird die Skala über die Farbverläufe („Color Setup“) auf die Werte gelegt, sodass die Matrix von Rot nach Grün geht.
3. Techniken bewerten. Technik anklicken, Score eintragen, Kommentar mit der Begründung: welche Logquelle, welche Regel, wann getestet. Der Kommentar ist der Teil, der in sechs Monaten den Unterschied macht. Techniken, die für die Umgebung irrelevant sind, etwa alles unter macOS in einer reinen Windows-Welt, werden ausgeblendet statt bewertet.
4. Bedrohung als zweiten Layer. Unter „Multi-Select“ lassen sich alle Techniken einer Gruppe oder Software in einem Zug auswählen und einfärben. Zwei oder drei Gruppen, die für die eigene Branche belegt sind, ergeben den Bedrohungslayer.
5. Layer verrechnen. „Create Layer from other layers“ mit einer Formel wie a*b, wobei a der Bedrohungslayer mit Wert 1 und b der Sichtbarkeitslayer ist: Das Ergebnis zeigt nur die Techniken, die relevante Gruppen nutzen, mit dem eigenen Reifegrad als Farbe. Rot in diesem Layer ist die Prioritätenliste.
6. Exportieren und versionieren. Als JSON speichern und in dasselbe Repository legen wie die Sigma-Regeln. Ein Layer pro Quartal, und die Veränderung von Rot zu Grün ist der Fortschrittsbericht für die Geschäftsführung.

Ein Layer ist eine JSON-Datei, die sich auch aus dem Regelbestand erzeugen lässt: Wer seine Sigma-Regeln mit ATT&CK-Tags pflegt, kann per Skript für jede getaggte Technik einen Eintrag schreiben. Das Gerüst sieht so aus:

{
  "name": "Erkennung 2026-09",
  "versions": { "attack": "18", "navigator": "5.1.0", "layer": "4.5" },
  "domain": "enterprise-attack",
  "description": "Stand der Erkennungsregeln, Skala 0-3",
  "techniques": [
    { "techniqueID": "T1003.001", "score": 3, "comment": "Sysmon 10 auf lsass, Sigma-Regel, getestet 2026-09-05" },
    { "techniqueID": "T1558.003", "score": 2, "comment": "4769 RC4, Regel aktiv, Test offen" },
    { "techniqueID": "T1021.001", "score": 1, "comment": "4624 Typ 10 vorhanden, keine Regel" }
  ],
  "gradient": { "colors": ["#ff6666", "#ffe766", "#8ec843"], "minValue": 0, "maxValue": 3 }
}

Eine Detection Strategy durchgespielt: T1003.001

Wie aus den neuen Objekten von Version 18 eine Regel wird, zeigt sich am besten an einer Technik, die in fast jedem Vorfall vorkommt: dem Auslesen von Zugangsdaten aus dem Speicher des LSASS-Prozesses. Die Detection Strategy zur Technik beschreibt das zu beobachtende Verhalten: Ein Prozess, der nicht zum Betriebssystem oder zu bekannter Sicherheitssoftware gehört, öffnet ein Handle auf lsass.exe mit Zugriffsrechten, die das Lesen des Speichers erlauben, oder es entsteht ein Speicherabbild des Prozesses als Datei. Die zugehörige Analytic für Windows nennt die Datenkomponenten, Prozesszugriff und Dateierstellung, und die konkreten Quellen: Sysmon Event 10 mit dem Feld GrantedAccess, Sysmon Event 11 für Dateien mit lsass im Namen, dazu die Hinweise, welche Zugriffsmasken typisch für Auslesewerkzeuge sind und dass legitime Prozesse wie Antivirus-Dienste, das EDR selbst und Systemkomponenten als Ausnahmen gepflegt werden müssen.

Daraus wird in vier Schritten eine Erkennung. Erstens Sichtbarkeit prüfen: Läuft Sysmon mit einer Konfiguration, die Event 10 für lsass.exe liefert? Wenn nicht, ist das die Maßnahme, nicht die Regel. Zweitens die Regel schreiben, am besten als Sigma-Regel: Logquelle Prozesszugriff unter Windows, Zielprozess endet auf lsass.exe, GrantedAccess enthält eine der aus der Analytic bekannten Masken, Filter für die Pfade der eigenen Sicherheitssoftware. Die Community-Sammlung hat dafür fertige Regeln, die nur um die eigenen Ausnahmen ergänzt werden. Drittens testen: Atomic Red Team hat für T1003.001 mehrere Tests, vom Speicherabbild per Bordmittel bis zum bekannten Werkzeug, und im Homelab zeigt sich in Minuten, ob die Regel bei jedem davon anschlägt oder nur beim bekanntesten. Viertens im Navigator eintragen: Score 3, Kommentar mit Datum und Testumfang. Dieselben vier Schritte funktionieren für jede Technik, die eine Detection Strategy hat, und das sind seit Version 18 die meisten, die für Windows-Umgebungen relevant sind.

Grenzen und Missverständnisse

• ATT&CK ist keine Checkliste. Eine komplett grüne Matrix gibt es nicht und sie wäre auch nicht das Ziel. Viele Techniken sind für deine Umgebung irrelevant, andere lassen sich mit vertretbarem Aufwand nicht zuverlässig erkennen.
• Techniken sind nicht gleich gewichtet. Zehn erkannte Discovery-Techniken wiegen weniger als eine erkannte Credential-Access-Technik. Prozentangaben zur Abdeckung sagen deshalb wenig.
• Abdeckung ist nicht Erkennungsqualität. Eine Regel, die existiert, aber vor Fehlalarmen nie ernst genommen wird, deckt nichts ab.
• Vorsicht bei Herstellerangaben. „Wir decken 95 Prozent von ATT&CK ab“ bedeutet meist, dass für 95 Prozent der Techniken irgendeine Regel im Produkt liegt, nicht, dass sie in deiner Umgebung greift.
• Der Schwerpunkt liegt nach dem Einbruch. ATT&CK beschreibt vor allem, was Angreifer im Netz tun. Wer nur auf Initial Access schaut, sieht einen kleinen Teil der Matrix.

Fazit

MITRE ATT&CK gibt dem Blue Team etwas, das es sonst nicht hat: eine Karte des Gegners, die aus echten Vorfällen gezeichnet wurde und die alle Beteiligten lesen können. Sie ersetzt keine Erkennung, aber sie zeigt, welche Erkennung fehlt, und seit Version 18 auch, wie sie zu bauen wäre. Wer seine Abdeckungskarte ehrlich pflegt, hat statt eines diffusen Bauchgefühls eine Liste von Techniken, an der sich jede Investition in Logquellen, Regeln und Übungen messen lässt.