Verify Attack ist in MITRE ATLAS die Technik, mit der ein Angreifer prüft, ob sein vorbereiteter Angriff gegen das Zielmodell wirklich wirkt – bevor er ihn im großen Stil oder in der physischen Welt einsetzt. Offizielle Definition: Der Angreifer verifiziert die Wirksamkeit über eine Inferenz-API oder eine Offline-Kopie des Modells. Das gibt ihm Sicherheit, dass der Ansatz funktioniert, und erlaubt den eigentlichen Schlag zu einem selbst gewählten Zeitpunkt. Reifegrad in ATLAS: demonstrated. Taktik: AI Attack Adaptation (AML.TA0001, früher AI Attack Staging). Es gibt keine Untertechniken.
Was geprüft wird – und was nicht
Verify Attack ist nicht der Diebstahl und nicht der Impact. Es ist die Qualitätskontrolle in der Werkstatt. Typische Prüffragen:
- Löst dieser Input die gewünschte Fehlklassifikation aus?
- Kommt der Jailbreak noch durch die aktuellen Guardrails?
- Liefert die API noch Chain-of-Thought in trainierbarer Tiefe – oder hat der Anbieter still abgerüstet?
- Generalisiert ein am Proxy gebautes Beispiel auf das Produktivmodell?
ATLAS betont drei Eigenschaften, die die Technik gefährlich und schwer sichtbar machen:
- Einmal prüfen, vielfach nutzen. Ein verifizierter Angriff kann gegen viele Edge-Geräte mit derselben Modellkopie laufen.
- Digital zuerst, physisch später. Verifikation an der API, Einsatz danach über Physical Environment Access (AML.T0041) – etwa ein Aufkleber gegen eine Kamera, ein akustisches Muster gegen einen Sensor.
- Wenig Spuren. Wenige Queries oder eine Offline-Kopie reichen. Hohe Last ist also nicht zwingend.
Wie die Technik an andere ATLAS-Bausteine andockt
Verify Attack ist der Rückkopplungsknoten:
- Nach Craft Adversarial Data (AML.T0043): White- oder Black-Box-Beispiel bauen, dann am Live-Modell testen, bevor es in einer Umgebung auffällt.
- Nach Create Proxy / Train Proxy via Replication (AML.T0005): Am Stellvertreter optimieren, am echten Endpunkt nur noch stichprobenartig bestätigen. Sitzt der Proxy nah genug am Ziel, reicht ein schmaler Verify-Schritt.
- Mit AI Model Inference API Access (AML.T0040): Die API ist zugleich Labor und Ziel. Ergebnisse fließen zurück ins Training des Proxys oder des Studenten.
- Mit Full AI Model Access (AML.T0044): Verifikation komplett offline, für den Verteidiger unsichtbar.
- Vor Evade AI Model / Impact: Erst wenn Verify grün ist, kommt die Wirkphase.
CISA nutzt genau diesen Knoten in AA26-251A: Destillationskampagnen betreiben automatisierte QA-Pipelines, die erkennen, ob der Lehrer absichtlich schlechtere Antworten gibt – und wechseln das Zielmodell, oft innerhalb eines Tages. Das ist Verify Attack im Industriemaßstab, nicht der klassische einzelne Adversarial-Example-Check.
Drei Verfahrensfamilien
1. Stichprobe an der API.
Wenige, gezielte Prompts oder Bilder mit bekanntem Soll-Output. Weicht die Antwort vom Labor ab, ist entweder das Modell gewechselt, eine Policy aktiv oder eine stille Degradation (CISA-Empfehlung) im Gang. Für Distillation heißt das: Reasoning-Tiefe, Stilkonsistenz und Aufgabenerfolg messen.
2. Offline gegen die Kopie.
Gewichte, Checkpoint oder ausreichend repliziertes Student-Modell. Hier ist Verify unsichtbar. ATLAS warnt ausdrücklich: Das Verhalten ist schwer zu erkennen.
3. Transfer-Schleife.
Angriff am Proxy härten ? Mini-Verify am Ziel ? Verlust ins Proxy-Training zurück. Das ist Closed-Loop-Adaptation. Ohne diesen Schritt bleibt Black-Box-Transfer ein Hoffen auf Generalisierung.
Warum Erkennung so leicht scheitert
Einzelne Verify-Queries sehen aus wie normale Nutzung: ein Nutzer testet, ob das Modell noch rechnen, coden oder klassifizieren kann. Ambiguous Technique im Sinne von ATT&CK-Methodik – Absicht steht nicht im einzelnen Request. Sichtbar wird sie erst in der Kette: Craft ? wiederholtes Verify ? plötzlicher Modellwechsel ? Collection/Exfiltration.
Deshalb greifen Mitigations nicht an der einen Query, sondern am Muster:
- Telemetrie von Inputs und Outputs (AML.M0024) über Zeit und Kontenpools;
- Erkennung atypischer, sich wiederholender Evaluationsprompts (AML.M0015);
- Query-Limits, die enge Testschleifen verteuern (AML.M0004);
- variable, nicht binäre Antwortveränderung, damit Verify kein klares „Abwehr an/aus“-Signal bekommt;
- keine Logits nach außen (AML.M0002), keine frei verfügbaren Produktionsartefakte (AML.M0001) – sonst wandert Verify vollständig offline.
Praktische Lesart
Wer nur nach Malware oder IOC sucht, sieht AML.T0042 nicht. Wer API-Logs nach Evaluation durchsucht – feste Benchmark-Prompts, A/B derselben Aufgabe, Qualitätsmetriken in kurzen Abständen, Schwenk auf ein Schwestermodell nach einem Update – sieht die Technik.
Für Destillations-Abwehr ist Verify Attack der Gegenspieler der stillen Degradation: Der Verteidiger will den Nutzen der Outputs senken, ohne dass es messbar wird. Der Angreifer will genau diese Messung. Wer immer gleich drosselt, verliert das Duell. Wer nie misst, merkt den Probelauf erst am Impact.
