MITRE ATT&CK v20 kennt jetzt Prompt Injection: welche Logs Ihres LLM-Stacks T1698, T1699 und T1700 zeigen

/01Was MITRE am 13. Oktober in Version 20 veröffentlicht hat

ATT&CK v20 ist seit dem 13. Oktober 2026 die aktuelle Version der Wissensbasis von MITRE. Zum ersten Mal stehen darin eigene Techniken für Angriffe auf und über Sprachmodelle: T1698 Indirect Prompt Injection, T1699 Direct Prompt Injection und T1700 AI-Enabled Exfiltration. Für T1700 gibt es mit DET0927 auch gleich eine Erkennungsstrategie. Für die beiden Prompt-Injection-Techniken gibt es keine.

Die Release-Seite fasst den Schwerpunkt der Version als erweiterte Abdeckung „recent adversary activity and tradecraft“ zusammen, ausdrücklich auch mit KI-bezogenen und KI-gestützten Techniken. Dazu kommen T1608.007 (AI Result Poisoning, mit der Erkennungsstrategie DET0922), T1685.007 (Impair Autonomous Defenses) und die Kampagne C0064 „AI-Assisted Breach of Mexico's Government Infrastructure“. Die Enterprise-Matrix umfasst jetzt 15 Taktiken, 227 Techniken, 479 Untertechniken, 703 Erkennungsstrategien und 1.770 Analytics.

Warum das für einen Mittelständler mit eigenem Sprachmodell wichtig ist: ATT&CK ist die Sprache, in der SOC-Dienstleister, SIEM-Hersteller und Prüfer Abdeckung beschreiben. Bisher landeten Vorfälle mit KI-Agenten dort unter Sammelbegriffen oder gar nicht. Ab v20 kann ein Haus fragen: Welche unserer Log-Quellen zeigt T1698? Wer hat eine Regel für T1700? Das ist eine prüfbare Frage. „Sind wir gegen Prompt Injection geschützt?“ ist das nicht.

Dieser Artikel behandelt das Erkennen, nicht das Abwehren. Schutzmaßnahmen in einer RAG-Pipeline, Vertrauensbereiche im Prompt und Egress-Filter sind eigene Themen. Hier geht es um die Frage, die danach kommt: Wenn eine Injektion durch alle Schichten gerutscht ist – woran sehen Sie es, in welchem Log, mit welcher Regel?

/02T1698, T1699, T1700: drei Techniken, eine Kette

Die drei Techniken sind nicht nebeneinander gedacht, sondern hintereinander. T1698 und T1699 sitzen in der Taktik Execution (TA0002), T1700 in Exfiltration (TA0010). Die Beschreibung von T1700 sagt es direkt: Angreifer nutzen direkte oder indirekte Prompt Injection, um „enterprise AI agents to exfiltrate data“ zu bewegen – mit Werkzeugen, die der Agent ohnehin freigegeben hat.

T1698 Indirect Prompt Injection beschreibt Anweisungen, die in Inhalten versteckt sind, die ein KI-System wahrscheinlich verarbeitet: Webseiten, Dokumente, E-Mails, Tickets, Code. Im eigenen Betrieb ist das jeder Text, der über Retrieval, einen Mailabruf oder ein Werkzeugergebnis in den Kontext kommt. Die Technikseite nennt als Folge ausdrücklich die „unauthorized execution of any capabilities available to the LLM“ – also alles, was der Agent per Werkzeugaufruf kann.

T1699 Direct Prompt Injection ist die Eingabe in die Oberfläche selbst: Anweisungen, die Schutzregeln umgehen, Kontext manipulieren oder vorherige Anweisungen überschreiben. Der klassische Jailbreak fällt hierunter. MITRE führt zwei Prozedurbeispiele, beide aus öffentlich dokumentierten Kampagnen (C0064 und C0062), in denen sich der Angreifer gegenüber dem Modell als Mitarbeiter einer Sicherheitsfirma ausgab oder Dateioperationen in den Prompt schrieb.

T1700 AI-Enabled Exfiltration ist der Schritt, der Schaden macht: Der Agent trägt Daten hinaus. MITRE verweist darauf, dass dann zusätzlich bekannte Techniken greifen können, etwa T1567 (Exfiltration Over Web Service) oder T1567.001 (Exfiltration to Code Repository). Für einen SOC ist das der vertraute Teil – neu ist nur, wer die Daten bewegt.

Ein Detail, das auffällt: Als Plattformen nennen alle drei Techniken „SaaS, Windows“. Linux steht nicht dabei, obwohl die meisten eigenen Inferenzserver auf Linux laufen. Die Erkennungsstrategie DET0927 hat trotzdem eine Linux-Variante. Wer seine Abdeckung nach Plattform-Filter im ATT&CK Navigator prüft, sieht die Techniken für einen On-Premise-Stack also womöglich gar nicht – das ist ein Filterproblem, kein Entwarnungssignal.

/03DET0927: wie MITRE KI-Exfiltration erkennen will

DET0927 „Detect AI-Enabled Exfiltration“ ist am 24. September 2026 angelegt worden und besteht aus drei Analytics. Alle drei folgen demselben Muster: Ein KI-Prozess oder Agent greift auf Daten außerhalb seines Auftrags zu, und innerhalb eines Zeitfensters folgt eine Übertragung an ein Ziel außerhalb der erlaubten Datenflüsse. Kein Analytic versucht, den bösen Prompt zu finden. Alle suchen die Abfolge.

• AN2079 (Windows): Ein KI-zugeordneter Prozess liest Daten außerhalb seines erlaubten Bereichs; derselbe Prozessbaum startet danach eine übertragungsfähige Ausführung und baut eine Verbindung zu einem nicht erlaubten Ziel auf. Log-Quellen: Security-Ereignisse 4663, 4670, 4656 (Dateizugriff), PowerShell 4103 bis 4106, Sysmon-Ereignis 1 (Prozessstart).
• AN2078 (SaaS): Ein Agent greift auf geschützte Daten zu, ruft mit diesen oder abgeleiteten Daten ein Werkzeug oder eine API auf, und der Zieldienst verzeichnet eine erfolgreiche Übertragung außerhalb der erlaubten Datenflüsse. Log-Quellen: das Audit-Log der SaaS-Anwendung und – als einziges namentlich genanntes KI-Produkt – die Agent-Traces von AWS Bedrock (Werkzeugaufruf und Wissensbasis-Abfrage).
• AN2080 (Linux): dieselbe Abfolge wie AN2079, gemessen über auditd: open/read für den Dateizugriff, EXECVE für den Prozessstart, connect für die Netzverbindung.

Der wichtigste Teil von DET0927 sind die sogenannten Mutable Elements – Werte, die jedes Haus selbst festlegen muss, bevor eine Regel überhaupt laufen kann. MITRE nennt unter anderem AuthorizedAIDataScope (welche Datenpfade oder Datenklassen der KI-Dienst lesen darf), ExpectedAIProcessTree (welche Eltern-Kind-Prozesse bei sauberem Betrieb auftreten), AuthorizedAIEndpoints (welche Ziele erlaubt sind), AuthorizedAIDataFlows (Quelle → Werkzeug → Ziel) und ein Zeitfenster zwischen Zugriff und Übertragung, das aus sauberen Abläufen abgeleitet wird.

Ehrlich: Das ist die eigentliche Arbeit. Eine Regel, die „Zugriff außerhalb des erlaubten Bereichs“ sucht, ist wertlos, solange niemand aufgeschrieben hat, was der erlaubte Bereich ist. Die meisten Mittelständler, die einen Agenten an Laufwerke, Ticketsystem und Mail gehängt haben, können diese Werte heute nicht ausfüllen. DET0927 ist deshalb weniger eine fertige Regel als eine Checkliste für das Betriebskonzept.

/04Zuordnung: welche Log-Quelle welche Technik zeigt

MITRE beschreibt Windows, Linux und SaaS – aber keinen eigenen LLM-Stack mit vLLM oder Ollama, einem Gateway davor und Werkzeugen über MCP. Die folgende Zuordnung überträgt die drei Techniken auf die Log-Quellen eines solchen Stacks. Sie ist unsere Arbeitshilfe, keine MITRE-Veröffentlichung.

Drei Dinge zeigt die Tabelle. Erstens: Die Inferenzserver-Logs helfen fast nicht. Wer seine Erkennung bei vLLM oder Ollama beginnt, schaut auf die falsche Schicht. Zweitens: T1698 ist nur dort sichtbar, wo die Herkunft eines Kontextstücks protokolliert wird – im RAG-Abruf und im Tool-Call-Protokoll. Drittens: Für T1700 reichen klassische Quellen (auditd, Firewall, Audit-Logs der Zielsysteme), sobald die Agent-Identität darin unterscheidbar ist.

Der letzte Punkt ist der unterschätzte. Ein Agent, der Mails mit dem Konto des Sachbearbeiters verschickt, ist in keinem Audit-Log vom Menschen zu unterscheiden. MITRE schreibt bei T1698 unter M1018 sinngemäß: Agenten bekommen eigene Identitäten mit minimalen Rechten, und abgerufene Inhalte dürfen den Berechtigungskontext nicht ändern. Das ist Abwehr – aber zugleich die Voraussetzung für jede Erkennung.

/05Protokollierung im eigenen LLM-Stack einschalten

Bevor eine Regel greift, müssen die Daten da sein. In der Praxis fehlen drei Dinge am häufigsten: das Tool-Call-Protokoll mit Agent-Identität, die Herkunft der RAG-Treffer und die Zuordnung des Agenten-Prozesses auf dem Host. Für die dritte Lücke genügt auditd, und die Regeln dafür sind in zehn Minuten gesetzt.

# /etc/audit/rules.d/50-ki-agent.rules  (Beispiel; Pfade und Benutzer anpassen)
# Agent läuft als eigener Dienstbenutzer "kiagent" (UID per: id -u kiagent)

# 1) Lesezugriffe auf schützenswerte Ablagen (AuthorizedAIDataScope liegt AUSSERHALB davon)
-a always,exit -F arch=b64 -S openat -F dir=/srv/personal -F uid=1050 -k ki_daten_ausserhalb
-a always,exit -F arch=b64 -S openat -F dir=/srv/finanzen -F uid=1050 -k ki_daten_ausserhalb

# 2) Prozessstarts des Agenten (ExpectedAIProcessTree)
-a always,exit -F arch=b64 -S execve -F uid=1050 -k ki_exec

# 3) Netzverbindungen des Agenten
-a always,exit -F arch=b64 -S connect -F uid=1050 -k ki_connect

# laden und prüfen
augenrules --load
auditctl -l | grep ki_
ausearch -k ki_exec --raw --start today | aureport -x --summary -i

Wichtig ist --raw: Mit ausearch -i im Rohr meldet aureport „no events of interest“ (getestet mit audit 4.0.2 am 22.10.2026). Die Ausgabe von aureport -x --summary nach einer Woche sauberem Betrieb ist Ihr ExpectedAIProcessTree: typischerweise der Python-Interpreter des Agenten-Frameworks und eine Handvoll Hilfsprogramme. Taucht später curl, scp, git oder eine Shell auf, die vorher nie lief, ist das genau die „transfer-capable execution“ aus AN2080.

Für das Tool-Call-Protokoll gibt es keinen Standard. Bewährt hat sich eine JSON-Zeile je Aufruf, geschrieben vom Gateway oder vom MCP-Proxy, nicht vom Agenten selbst – ein kompromittierter Agent soll sein eigenes Protokoll nicht schreiben. Pflichtfelder aus unserer Sicht: Zeitstempel, Agent-Identität, auslösender Benutzer, Sitzungs-ID, Werkzeugname, Ziel (Empfänger, URL, Repository), Größe der Nutzlast, Liste der Dokument-IDs, die im Kontext dieser Anfrage standen. Das letzte Feld verbindet T1698 mit T1700: Es zeigt, welches Dokument im Kontext war, als der Agent zu senden begann.

Inhalte von System-Prompt, Nutzereingabe und Modellantwort gehören in ein getrenntes Log mit kürzerer Aufbewahrung und Zugriff nur für Berechtigte. Für die Erkennung reichen meist Metadaten; für die Aufklärung braucht man die Inhalte. Die Aufbewahrungsfrist klären Sie mit dem Datenschutzbeauftragten, nicht mit dem SOC.

/06Beispielregeln: Sigma und Wazuh für das LLM-Gateway

Die folgenden zwei Regeln sind Beispiele für die Abfolge aus DET0927, angepasst auf ein Tool-Call-Protokoll im JSON-Format. Sie sind nicht von MITRE und nicht aus einem Regel-Repository; Feldnamen und Schwellen müssen auf Ihr Protokoll angepasst werden. Die Sigma-Regel nutzt eine eigene Log-Quelle, weil Sigma für LLM-Gateways keine Standardkategorie kennt.

title: KI-Agent sendet an Ziel ausserhalb der Erlaubnisliste nach externem Dokument
id: 1eb408b5-6394-44f9-ad65-cbdeba55341c
status: experimental
description: Beispielregel nach MITRE DET0927 / AN2078. Werkzeugaufruf mit
  Sendefunktion an nicht erlaubtes Ziel, waehrend ein extern eingegangenes
  Dokument im Kontext stand (Hinweis auf T1698 -> T1700).
references:
  - https://attack.mitre.org/detectionstrategies/DET0927/
author: ki-spezial
date: 2026-10-22
tags:
  - attack.exfiltration
  - attack.t1700
  - attack.execution
  - attack.t1698
logsource:
  product: llm-gateway
  service: toolcalls
detection:
  sendewerkzeug:
    tool:
      - 'send_mail'
      - 'http_post'
      - 'upload'
      - 'git_push'
  extern_im_kontext:
    context_sources|contains:
      - 'mail-eingang'
      - 'web'
      - 'ticket-extern'
  erlaubt:
    target_domain|endswith:
      - '.firma.de'
      - 'partner-portal.example'
  condition: sendewerkzeug and extern_im_kontext and not erlaubt
falsepositives:
  - Freigegebene Antworten an neue Kunden (Erlaubnisliste pflegen)
level: high

Die gleiche Logik als Wazuh-Regel, ergänzt um eine Häufungsregel: Ein einzelner abgewiesener Sendeversuch ist ein Hinweis, fünf in zehn Minuten aus derselben Sitzung sind ein Vorfall. Wazuh dekodiert JSON-Zeilen mit dem eingebauten JSON-Decoder; eigene Regel-IDs liegen im Bereich ab 100000.

<!-- /var/ossec/etc/rules/local_rules.xml  (Beispiel) -->
<group name="ki_agent,attack,">

  <rule id="100700" level="3">
    <decoded_as>json</decoded_as>
    <field name="log_type">^toolcall$</field>
    <description>KI-Agent: Werkzeugaufruf protokolliert</description>
  </rule>

  <rule id="100701" level="10">
    <if_sid>100700</if_sid>
    <field name="tool">^send_mail$|^http_post$|^upload$|^git_push$</field>
    <field name="target_allowed">^false$</field>
    <description>KI-Agent sendet an nicht erlaubtes Ziel: $(target_domain)</description>
    <group>attack_t1700,</group>
  </rule>

  <rule id="100702" level="12">
    <if_sid>100701</if_sid>
    <field name="context_sources">mail-eingang|web|ticket-extern</field>
    <description>KI-Agent: Sendeversuch nach externem Dokument im Kontext</description>
    <group>attack_t1698,attack_t1700,</group>
  </rule>

  <rule id="100703" level="14" frequency="5" timeframe="600">
    <if_matched_sid>100701</if_matched_sid>
    <same_field>session_id</same_field>
    <description>KI-Agent: Häufung von Sendeversuchen an fremde Ziele (10 Minuten)</description>
    <group>attack_t1700,</group>
  </rule>
</group>

Beide Regeln sind getestet mit sigma-cli 3.1.0 (pySigma 1.5.1, sigma check ohne Befund, Umwandlung nach Splunk und Lucene) und Wazuh 4.14.9 am 22.10.2026, mit vier JSON-Testzeilen über wazuh-logtest und eine überwachte Logdatei. Drei Befunde aus dem Test: Erstens kennt die mitgelieferte MITRE-Datenbank von Wazuh 4.14.9 (Stand Mai 2023) T1698 und T1700 nicht; <mitre> erzeugt nur eine Warnung und ein leeres MITRE-Feld im Alarm, deshalb tragen die Regeln die IDs als Gruppe. Zweitens löste 100703 je nach Lauf beim fünften oder sechsten Versuch derselben Sitzung aus – für einen Häufungsalarm genügt das. Drittens: Sigma verlangt eine echte UUID als id, sonst bricht sigma check ab. Prüfen lässt sich die Regel ohne echten Angriff: eine JSON-Zeile in /var/ossec/bin/wazuh-logtest einfügen und nachsehen, ob Regel 100702 auslöst. Das gehört in denselben Testlauf wie das Red-Teaming des Agenten. Eine Erkennungsregel, die nie gegen eine echte Injektion aus dem Testset gelaufen ist, ist eine Vermutung.

Für T1699 lohnt sich zusätzlich eine einfache Häufungsregel am Gateway: viele Ablehnungen durch die Guardrails aus demselben Konto in kurzer Zeit. Einzelne Ablehnungen sind Alltag; eine Serie ist jemand, der probiert. Mustererkennung auf Wörter wie „ignore previous instructions“ dagegen erzeugt viel Lärm und wird mit der ersten Umformulierung wirkungslos.

/07Grenzen: was sich nicht erkennen lässt

Die ehrliche Bilanz zuerst: MITRE selbst listet für T1698 und T1699 keine Erkennungsstrategie. Das ist kein Versehen. Eine Injektion ist Text unter Text; ob „Bitte fassen Sie zusammen und senden Sie das Ergebnis an …“ eine legitime Anweisung im Dokument oder ein Angriff ist, entscheidet der Kontext, nicht das Muster. Inhaltsfilter und Klassifikatoren helfen, aber sie sind Abwehr mit Fehlerquote, keine verlässliche Erkennung.

Zweitens: Exfiltration ohne Werkzeug. Wenn die Antwort des Modells selbst die Daten enthält und ein Mensch sie weiterleitet, sieht kein Tool-Call-Protokoll etwas. Ebenso, wenn ein Chat-Client Markdown-Bilder mit externen URLs automatisch lädt – dann ist die Übertragung ein Bildabruf im Browser des Nutzers, nicht im Log des Agenten. Abhilfe ist hier Abwehr (externe Bilder nicht rendern), nicht Erkennung.

Drittens: erlaubte Ziele. DET0927 sucht Übertragungen außerhalb der erlaubten Flüsse. Ein Agent, der Daten per Injektion in ein freigegebenes Ticketsystem schreibt, das ein externer Kunde lesen kann, bleibt innerhalb der Liste. Je breiter die Erlaubnis, desto blinder die Regel.

Viertens: Aufwand gegen Nutzen. Ein Haus, dessen Sprachmodell nur Fragen zu internen Handbüchern beantwortet, ohne Werkzeuge, ohne Mailzugriff und ohne Internet, hat für T1700 schlicht keine Angriffsfläche. Dort ist eine Erkennungsstrategie für KI-Exfiltration Aufwand ohne Gegenwert. Die Techniken werden erst relevant, wenn Agenten handeln dürfen – also mit Function Calling und echten Werkzeugen.

/08Entscheidung: wer welche Erkennungsstufe braucht

Die Frage ist nicht, ob Sie ATT&CK v20 „umsetzen“, sondern welche Stufe zu Ihrem Agenten passt. Wir unterscheiden drei.

Stufe 0 – Chat ohne Werkzeuge. Ein lokales Modell beantwortet Fragen aus einer Wissensbasis, kann aber nichts senden, schreiben oder abrufen. Hier genügen die üblichen Gateway-Logs mit Benutzerbezug und eine Häufungsregel für T1699. DET0927 brauchen Sie nicht. Die meisten Mittelständler, die gerade mit einem internen Assistenten anfangen, stehen hier.

Stufe 1 – Agent mit lesenden und wenigen schreibenden Werkzeugen. RAG über Laufwerke, dazu ein bis drei Werkzeuge mit Außenwirkung (Ticket anlegen, Mail-Entwurf, Kalender). Hier brauchen Sie ein eigenes Dienstkonto je Agent, ein Tool-Call-Protokoll mit Kontextquellen, die auditd-Regeln aus Abschnitt /05 und mindestens die Regel 100702. Aufwand in der Praxis: wenige Tage für das Protokoll, ein bis zwei Tage für die Regeln, danach eine Woche Beobachtung, um die Erlaubnislisten zu füllen.

Stufe 2 – Agenten mit Sendefunktion oder Zugriff auf Code und Kundendaten. Mailversand, Git-Push, Freigaben in Kundenportale, Zugriff auf Personal- oder Finanzdaten. Hier ist DET0927 vollständig umzusetzen: alle Mutable Elements dokumentiert, Erkennung auf Host, Gateway und Zielsystem, ein SOC oder ein benannter Verantwortlicher, der Meldungen innerhalb von Stunden bewertet, und ein Human-in-the-Loop für Sendevorgänge an neue Ziele. Für diese Stufe ist die Erkennung keine Kür; ohne sie merken Sie eine erfolgreiche Exfiltration erst durch den Empfänger.

Unabhängig von der Stufe: Die Einstufung ist eine Entscheidung der Geschäftsleitung mit IT und Datenschutz, nicht des Administrators allein. Sie hängt an der Frage, welche Werkzeuge der Agent bekommt – und die stellt sich bei jeder Erweiterung neu.

/09Technik-IDs im Betrieb verankern

Der praktische Nutzen von v20 liegt weniger in einzelnen Regeln als darin, dass KI-Vorfälle jetzt eine Kennung haben. Drei Stellen, an denen sich das sofort auszahlt.

1. Abdeckungsliste. Tragen Sie T1698, T1699 und T1700 in die Liste ein, die Ihr SOC oder SIEM-Dienstleister pflegt, mit der Spalte „Log-Quelle vorhanden: ja/nein“ aus der Tabelle in Abschnitt /04. Eine leere Zeile ist eine ehrliche Aussage; eine fehlende Zeile ist ein blinder Fleck.
2. Regel-Tags. Jede Regel, die Agentenverhalten betrifft, bekommt die Technik-ID als Tag. Dann zeigt das SIEM bei einer Meldung sofort, dass es um KI-Exfiltration geht und nicht um einen gewöhnlichen Upload.
3. Testfälle. Das Testset für Red-Teaming wird nach denselben IDs sortiert. Jeder Testfall für T1698 hat eine erwartete Erkennung – oder den dokumentierten Vermerk, dass es keine gibt.

Für den Betrieb der Modelle selbst, also Inferenz, Updates und Kapazität, ändert v20 nichts. Es ändert die Fragen, die ein Prüfer, ein Versicherer oder ein Kunde in Zukunft stellen wird: „Wie erkennen Sie T1700?“ ist eine Frage, die man mit einer Tabelle und zwei Regeln beantworten kann. Wer agentischer KI produktiv einsetzt, sollte diese Antwort vorbereitet haben, bevor sie verlangt wird – und sie in sein LLMOps-Handbuch schreiben, damit sie den nächsten Werkzeugwechsel übersteht.

Zum Weiterlesen im Bestand: Warum sich Prompt Injection grundsätzlich nicht wegfiltern lässt und die Daten-Ebene die eigentliche Grenze ist, steht im Grundlagenartikel zu Prompt Injection und Data-Layer-Governance. Wie ein MCP-Gateway ausgehende Verbindungen der KI-Agenten einfängt und damit die Log-Quelle „Egress“ überhaupt erst sauber macht, beschreibt der Artikel zu Egress-Kontrolle und Credential-Injection.