Die neue Masche, mit der Hacker Finanz-KI-Assistenten austricksen
von
Zuletzt aktualisiert:
7 Lesezeit: 7 Minuten
Wichtigste Erkenntnisse
- Hacker setzen in alltäglichen Dokumenten aktiv Payloads zur indirekten Eingabe von Befehlen ein, um finanzielle KI-Assistenten zu kapern.
- Im Gegensatz zu herkömmlichen Betrugsmethoden, die Menschen täuschen, zielt dieser Angriff auf automatisierte KI ab, die Befehle sofort und ohne Misstrauen ausführt.
- KI-Agenten, die Geldtransfers durchführen, Arbeitsabläufe einleiten oder auf regulierte Kundendaten zugreifen können, sind für Angreifer die wertvollsten Ziele.
- Systemmeldungen allein reichen nicht aus, um die Sicherheit eines Agenten zu gewährleisten, weshalb strenge Prinzipien der geringsten Berechtigungen und obligatorische menschliche Genehmigungen unerlässlich sind.
- Da E-Mails das wichtigste Übertragungsmedium für diese Nutzdaten sind, ist eine strenge Durchsetzung von DMARC erforderlich, um Nachrichten zu authentifizieren, bevor sie von einer KI verarbeitet werden.
Sicherheitsforscher, die Inhalte in der Praxis untersuchten, haben kürzlich etwas Beunruhigendes entdeckt. Sie fanden versteckte Anweisungen, die nicht für Menschen, sondern für KI-Agenten bestimmt waren, die den Text lesen. Eine davon war eine voll funktionsfähige Schadcode-Nutzlast, die speziell darauf ausgelegt war, einen zahlungsfähigen KI-Assistenten dazu zu bringen, eine festgelegte Transaktion in Höhe von 5.000 US-Dollar auszuführen. Dabei handelte es sich nicht um eine kontrollierte Labordemonstration, sondern um eine echte Schadcode-Nutzlast, die in der Praxis gefunden wurde.
In den letzten zehn Jahren haben Finanzinstitute enorme Ressourcen dafür aufgewendet, ihre Mitarbeiter darin zu schulen, nicht auf überzeugend wirkende E-Mails zu reagieren. Nun haben viele dieser Institute KI-Assistenten mit genau diesen Posteingängen verknüpft. Diese Assistenten lesen alles, hinterfragen nichts und agieren oft mit den Berechtigungen der Mitarbeiter, die sie nutzen.
Diese Technik wird als „Indirect Prompt Injection“ bezeichnet. Sie stellt eine grundlegende Veränderung in der Funktionsweise von Finanzbetrug dar. Im Folgenden wird detailliert erläutert, wie der Angriff abläuft, wo die Banken tatsächlich angreifbar sind, was Forscher im Jahr 2026 konkret nachgewiesen haben und welche architektonischen Kontrollmaßnahmen erforderlich sind, um ihn zu verhindern.
Was ist eine Prompt-Injektion?
Eine Prompt-Injection liegt vor, wenn ein Angreifer ein KI-System dazu manipuliert, unbeabsichtigte Befehle auszuführen. Eine direkte Injection tritt auf, wenn ein Nutzer böswillige Anweisungen direkt in das Chatfenster eingibt. Eine indirekte Prompt-Injection ist wesentlich gefährlicher. Sie tritt auf, wenn Anweisungen in externen Inhalten versteckt sind, die der Assistent automatisch liest, wie beispielsweise eine eingehende E-Mail, eine angehängte Rechnung oder eine Webseite.
Der Hauptgrund dafür ist ganz einfach: Aktuelle KI-Systeme unterscheiden nicht zuverlässig zwischen Anweisungen und Daten. Jedes Dokument, das ein Assistent aufnimmt, wird als potenzielle Eingabe behandelt, was bedeutet, dass jede externe Datei zum Einfallstor für einen Angriff werden kann.
Warum KI-Assistenten im Finanzbereich ein besonders attraktives Ziel sind
Mayur Sewani, leitender Sicherheitsforscher bei Forcepoint, bringt das Problem auf den Punkt: Die Auswirkungen steigen mit dem Umfang der Berechtigungen. Ein KI-Assistent, der lediglich Besprechungsnotizen zusammenfasst, stellt ein geringes Risiko dar. Ein Assistent, der E-Mails versenden, einen Workflow auslösen oder Geld überweisen kann, ist hingegen ein kritisches Ziel mit weitreichenden Auswirkungen.
Bei den Assistenten, die derzeit im gesamten Finanzsektor eingesetzt werden, handelt es sich zunehmend um die zweite Art. Sie rufen Kundendaten ab, werten Compliance-Dokumente aus, leiten interne Arbeitsabläufe ein und greifen in einigen Anwendungsfällen direkt auf Zahlungssysteme zu.
Im Einzelhandel kann eine eingeschleuste Anweisung lediglich dazu führen, dass ein Dokument nach außen gelangt. Bei einer Bank kann dieselbe eingeschleuste Anweisung hingegen Geldtransfers veranlassen, streng regulierte Kundendaten offenlegen oder eine Compliance-Entscheidung im Rahmen der „Know Your Customer“-Vorschriften (KYC) verfälschen.
Wo ein Finanzinstitut tatsächlich einem Risiko ausgesetzt ist
Das Bedrohungsmodell ändert sich grundlegend, wenn man einem KI-Agenten Zugriff auf Bankensysteme gewährt. Die folgende Tabelle führt die spezifischen Betriebsbereiche auf, in denen Finanzinstitute derzeit Risiken ausgesetzt sind.
| Einsatzgebiet | Angriffsvektor | Mögliche Auswirkungen auf das Geschäft |
|---|---|---|
| Zahlungsverkehr | Ein Mitarbeiter mit Genehmigungs- oder Initiierungsbefugnissen liest ein eingehendes Anweisungsdokument, das versteckten Text enthält. | Der Mitarbeiter wird dazu verleitet, unter Ausnutzung der Berechtigungen des menschlichen Bedieners Geldbeträge auf das Konto eines Angreifers zu überweisen. |
| Kunden-Onboarding & KYC | Einem Assistenten, der mit der Zusammenfassung eingereichter Dokumente beauftragt ist, wird versteckter Text zugeführt, der ihn anweist, einen kritischen Risikobefund zu unterdrücken oder zu verändern. | Ein risikoreicher Kunde umgeht die Compliance-Prüfungen. Payloads, die zur Unterdrückung von Inhalten entwickelt wurden, sind bereits in freier Wildbahn dokumentiert. |
| Kundenservice | Eine eingefügte Anweisung geht über ein vom Kunden eingereichtes Support-Ticket oder eine Chat-Nachricht ein. | Die bösartige Eingabeaufforderung führt Befehle unter Nutzung der erweiterten Service-Desk-Rechte aus, die dem KI-Assistenten gewährt wurden. |
| Interne Wissenssuche | Mitarbeiter, die Zugriff auf Transaktionsunterlagen, Kreditakten oder Vorstandsunterlagen haben, öffnen einen schädlichen Link oder ein schädliches Dokument. | Die KI sammelt vertrauliche Daten, auf die sie Zugriff hat, und leitet diese an einen vom Angreifer kontrollierten Server weiter. |
| Korrespondenz mit Lieferanten | In eingehenden E-Mails von kompromittierten Dritten sind versteckte Nutzdaten eingebettet. | Angreifer nutzen den vertrauenswürdigsten eingehenden Kanal aus, um Anweisungen direkt an Agenten zu übermitteln, die für die Bearbeitung von Lieferantenrechnungen programmiert sind. |
Was Forscher im Jahr 2026 tatsächlich nachgewiesen haben
Diese Bedrohung ist nicht mehr nur theoretischer Natur. Sicherheitsforscher haben ausführlich dokumentiert, dass diese Schwachstellen im Jahr 2026 in realen Unternehmensumgebungen ausgenutzt wurden.
Die zehn von Forcepoint identifizierten Payloads, die bereits in freier Wildbahn im Umlauf sind (April 2026)
Am 23. April 2026 veröffentlichten Forscher von Forcepoint Erkenntnisse zu zehn indirekten „Prompt-Injection“-Payloads, die in freier Wildbahn entdeckt wurden. Diese Payloads umfassten die Unterdrückung von Inhalten, das Manipulieren der Zuordnung, die Ausführung von Unix-Befehlen gegen Entwicklertools sowie den Diebstahl von API-Schlüsseln. Von größter Bedeutung für Banken war dabei, dass die Untersuchung eine Payload für Zahlungsbetrug beschrieb, die auf KI-Agenten mit integrierten Zahlungsfunktionen abzielte. Die Payload enthielt eingebettete Anweisungen zum Auslösen einer festgelegten PayPal-Transaktion in Höhe von 5.000 US-Dollar. Sewani bezeichnete dies als eine als Waffe eingesetzte Payload, die zur sofortigen Ausführung bestimmt war, und nicht als harmlose Forschungssonde.
Der „Reprompt“-Angriff auf Microsoft Copilot (Januar 2026)
Am 15. Januar 2026 beschrieb Varonis den „Reprompt“-Angriff im Detail. Dabei handelte es sich um eine Datenabfluss-Kette, die mit einem einzigen Klick ausgelöst wurde und auf Microsoft Copilot abzielte. Der Angriff nutzte einen URL-Parameter, um Befehle einzuschleusen. Der Assistent wurde angewiesen, Aktionen zu wiederholen, um Sicherheitsvorkehrungen zu umgehen, wodurch ein kontinuierlicher Austausch mit einem vom Angreifer kontrollierten Server in Gang gesetzt wurde, um Daten abzusaugen. Der Angriff erfolgte über einen per E-Mail versendeten, seriös wirkenden Copilot-Link, der lediglich einen Klick des Opfers erforderte. Microsoft schloss die Sicherheitslücke zügig, und die Unternehmensversion von Microsoft 365 Copilot war Berichten zufolge nicht betroffen. Der Mechanismus bewies jedoch, dass ein Agent bereitwillig jeden internen Kontext preisgibt, auf den er Zugriff hat, wenn er dazu verleitet wird.
Das übergeordnete Muster
Dies ist kein Problem eines einzelnen Anbieters. Es wurde bereits erfolgreich gezeigt, dass Injektionsangriffe über Kommentare im Quellcode gegen agentenbasierte Codierungswerkzeuge möglich sind, und die Umgehung von Schutzmechanismen ist bei mehreren bedeutenden Modellen gut dokumentiert.
Das ist „Business Email Compromise“ mit einem anderen Ziel
Das Muster eines indirekten „Prompt-Injection“-Angriffs entspricht funktional dem von „Business Email Compromise“ (BEC). Eine betrügerische Anweisung trifft ein, die vollkommen legitim wirkt, und jemand handelt entsprechend. Der entscheidende Unterschied besteht darin, dass dieser „Jemand“ nun eine Software ist. Die KI zögert nicht, hat kein Bauchgefühl, dass etwas nicht stimmt, und keinen Instinkt, zum Telefon zu greifen und eine seltsame Anfrage beim Finanzvorstand zu überprüfen.
Glücklicherweise lassen sich die Kontrollmechanismen, die Unternehmen bereits für BEC-Überweisungen einsetzen, direkt auf dieses neue Problem übertragen. Eine Out-of-Band-Verifizierung, die Genehmigung von Zahlungen oder Änderungen der Zahlungsempfänger durch mehrere Personen sowie strenge Obergrenzen für einzelne automatisierte Vorgänge sind nach wie vor Ihre besten Schutzmaßnahmen. Ein KI-Agent muss innerhalb dieser bestehenden Kontrollmechanismen agieren und darf diese niemals umgehen.
Steuerung: Verkleinerung des Explosionsradius eines KI-Agenten
Sicherheitsarchitekten und Risikomanagement-Teams müssen strukturelle Kontrollmechanismen rund um KI-Agenten einrichten. Man kann sich nicht allein auf Systemhinweise verlassen, um eine Finanzplattform zu sichern.
| Regelprinzip | Praktische Umsetzung | Sicherheitsziel |
|---|---|---|
| Prinzip der geringsten Berechtigungen | Die Befugnisse für Zahlungen, den Versand und die Genehmigung sind streng zu beschränken. | Stellen Sie sicher, dass die meisten Assistenten nur Lesezugriff haben, um den Schaden zu begrenzen, den sie im Falle einer Kompromittierung anrichten können. |
| Human-in-the-Loop | Für Maßnahmen mit weitreichenden Folgen muss eine Genehmigung durch einen Menschen erforderlich sein. | Die Sicherheitsgrenze sollte bei der Aktion selbst liegen. Bei einer finanziellen Zahlung muss immer ein Mensch auf „Genehmigen“ klicken. |
| Zero Trust für Inhalte | Behandeln Sie alle eingelesenen Dokumente (PDFs, E-Mails, Dokumente) als nicht vertrauenswürdige Benutzereingaben. | Verhindern Sie, dass der Agent aus externen Dateien extrahierten Rohtext ohne Validierung ausführt. |
| API- und Tool-Protokollierung | Führen Sie strenge Prüfprotokolle darüber, was der Agent genau gelesen und ausgeführt hat. | Sorgen Sie für eine schnelle forensische Transparenz während der Untersuchung im Rahmen der Reaktion auf einen Vorfall. |
| Strenge Filterung beim Verlassen des Netzwerks | Blockieren Sie ausgehende Verbindungen zu unbekannten oder nicht vertrauenswürdigen IP-Adressen. | Verhindern Sie Angriffe wie die „Reprompt“-Kette, die darauf beruhen, dass ein vom Angreifer kontrollierter Server erreicht wird, um Daten zu exfiltrieren. |
| Einheitliche Arbeitsabläufe | Integrieren Sie KI-Agenten in Ihre bestehenden Rahmenwerke zur Zahlungskontrolle. | Verhindern Sie die Entstehung paralleler, ungeprüfter Genehmigungsverfahren, die bestehende Sicherheitsprüfungen umgehen. |
Seien Sie realistisch, was die Erkennung angeht. Das Filtern eingehender Dokumente nach bekannten Auslösephrasen für Prompt-Injektionen ist nur ein kleiner Stolperstein. Angreifer werden ihre Payloads einfach umformulieren.
Da kommst du nicht mit Ausreden raus
Solange sich ein KI-Agent durch Text beeinflussen lässt, sind strukturelle Kontrollmaßnahmen die einzigen dauerhaften Lösungen. Man muss physisch einschränken, was der Agent tun darf, auf welche Systeme er zugreifen kann und welche Aktionen zwingend einen Menschen erfordern. Bessere Systemaufforderungen und Schutzmaßnahmen der Anbieter erhöhen zwar zweifellos die Kosten eines Angriffs, beseitigen diese Schwachstellenklasse jedoch nicht. Für ein reguliertes Finanzinstitut ist dieser Unterschied entscheidend: Er bedeutet den Unterschied zwischen einer Kontrollmaßnahme, deren Wirksamkeit Sie einem Wirtschaftsprüfer nachweisen können, und einer, bei der Sie nur vermuten können, dass sie funktioniert.
Was die Aufsichtsbehörden signalisieren
Die Aufsichtsbehörden beobachten diesen Wandel sehr genau. In den Leitlinien der FINRA zu den Schlüsselthemen der künstlichen Intelligenz für 2026 sowie in den Berichten zur Aufsicht wurde insbesondere die agentische KI als eigenständige Kategorie von Aufsichtsrisiken herausgestellt. Da diese Systeme nicht nur Texte generieren, sondern eigenständig handeln, müssen Unternehmen lückenlose Prüfpfade führen und vor der Ausführung manuelle Kontrollpunkte einrichten. Die FINRA hob zudem die Risiken der „Shadow-KI“ hervor und betonte die Notwendigkeit, KI-Plattformen von Drittanbietern als risikoreiche Anbieter zu behandeln (wie in einem Folgeartikel von Smarsh ausführlich beschrieben).
Die OCC hat zudem angedeutet, dass umfassende Leitlinien zur Steuerung von KI-Modellen für Banken in Kürze erscheinen werden. Darüber hinaus hat die FS-ISAC eine Reihe von Whitepapers zu KI-Risiken für den Finanzsektor veröffentlicht, die sich unter anderem mit der Taxonomie adversarischer KI und der Bewertung von Anbietern befassen. Es sei darauf hingewiesen, dass diese Papiere im Februar 2024 veröffentlicht wurden und somit aus der Zeit vor der „Agentic Wave“ stammen, aber dennoch als grundlegende Orientierungshilfe für die Branche nützlich sind.
Führungskräfte und Sicherheitsarchitekten fordern im Grunde genau dasselbe: eine nachweisbare menschliche Kontrolle über folgenreiche KI-Aktionen. Diese regulatorische Übereinstimmung ist das stärkste interne Argument, das ein Sicherheitsverantwortlicher vorbringen kann, um Finanzmittel für den Aufbau dieser Kontrollmechanismen zu sichern.
Wo E-Mail-Authentifizierung zum Einsatz kommt
Es ist wichtig, klar darzulegen, was die E-Mail-Authentifizierung nicht leisten kann. DMARC mit der Einstellung „p=reject“ verhindert keine Prompt-Injektion; es überprüft den Inhalt der Nachrichten nicht und schränkt auch nicht die Handlungsmöglichkeiten eines KI-Agenten ein.
Die Injektions-Payloads, die bei einem KI-Assistenten einer Bank am ehesten Erfolg haben, sind jedoch diejenigen, die so aussehen, als stammten sie vom Finanzvorstand, einer Korrespondenzbank oder einem vertrauenswürdigen Zahlungsabwickler. E-Mails sind der Hauptweg, über den nicht vertrauenswürdige Inhalte diese KI-Systeme erreichen. Die aufgedeckte „Reprompt“-Kette wurde über einen per E-Mail versendeten Link übermittelt. Wenn ein KI-Agent E-Mails ohne jegliche menschliche Aufsicht verarbeitet, wird die Authentizität des Absenders zum absolut letzten Vertrauenssignal in der Pipeline.
Die Finanzdienstleistungsbranche weist eine der höchsten DMARC-Einführungsraten aller Branchen auf, leider jedoch auch eine der schwächsten Durchsetzungsraten. Wenn Sie KI in Ihren Posteingang integrieren, ist die Durchsetzung einer strengen E-Mail-Authentifizierung nicht mehr optional. Weitere Informationen zur Absicherung dieses Angriffsvektors finden Sie in unserer Studie zu Phishing in der Finanzdienstleistungsbranche und zu DMARC bei Finanzinstituten.
Schlussfolgerung
In den letzten zehn Jahren war das schwächste Glied in der Sicherheit von Finanz-E-Mails der Mitarbeiter, der auf einen schädlichen Link geklickt hat. Mittlerweile haben die Institutionen genau diesen Posteingang einer Software übergeben, die alles liest, nichts hinterfragt und über echte Systemberechtigungen verfügt. Die ersten Schadcodes, die speziell dafür entwickelt wurden, diese automatisierten Agenten auszunutzen, sind bereits im Umlauf.
Die Lösung erfordert einen mehrschichtigen Ansatz. Sie müssen die physischen Handlungsmöglichkeiten von KI-Agenten einschränken, Menschen bei weitreichenden Entscheidungen einbeziehen, diese Agenten in Ihre bestehenden Zahlungskontrollen einbinden und alle Daten, die sie erreichen, einer strengen Authentifizierung unterziehen.
Überprüfen Sie die Sicherheitslage Ihrer Domain mit unserem DMARC-Record-Checker oder besuchen Sie unsere Lösungsseite für Finanzdienstleistungen, um mehr über die Absicherung Ihrer eingehenden Kanäle zu erfahren.
Häufig gestellte Fragen
Was versteht man unter „Prompt Injection“ in einfachen Worten?
Dabei handelt es sich um einen Cyberangriff, bei dem ein Hacker geheime Anweisungen in einem Dokument oder einer E-Mail versteckt. Wenn ein KI-Assistent diese Datei liest, führt er unwissentlich die versteckten Befehle aus.
Kann ein KI-Assistent durch eine Eingabeaufforderung Geld überweisen?
Ja. Wenn einem KI-Agenten Zugriff auf Zahlungssysteme gewährt wurde und es keine Kontrollmechanismen gibt, bei denen ein Mensch in den Entscheidungsprozess eingebunden ist, kann eine versteckte Anweisung ihn dazu zwingen, nicht autorisierte Überweisungen auszulösen.
Wurde die Prompt-Injection bereits bei tatsächlichen Angriffen eingesetzt?
Ja. Im April 2026 dokumentierten Forscher zehn verschiedene indirekte „Prompt Injection“-Nutzlasten in freier Wildbahn, darunter eine, die speziell dafür entwickelt wurde, eine PayPal-Transaktion in Höhe von 5.000 US-Dollar auszuführen.
Inwiefern unterscheidet sich „Prompt Injection“ von „Business Email Compromise“?
Das Angriffsmuster ist ähnlich, doch das Opfer ist ein anderes. Anstatt einen menschlichen Mitarbeiter dazu zu verleiten, Geld zu überweisen, täuscht der Angreifer einen automatisierten KI-Software-Agenten, der die Anweisung sofort ausführt.
Welche Kontrollmaßnahmen sollte eine Bank für einen KI-Agenten einführen?
Banken müssen den Grundsatz der geringstmöglichen Berechtigungen durchsetzen, für alle folgenreichen Aktionen eine manuelle Genehmigung verlangen, strenge Filter für den ausgehenden Netzwerkverkehr implementieren und jeden API-Aufruf des Agenten protokollieren.
Verhindern DMARC oder die E-Mail-Authentifizierung das Einfügen von Prompts?
Nein, DMARC kann den Inhalt einer E-Mail nicht auf versteckte Aufforderungen überprüfen. Es verhindert jedoch von vornherein, dass gefälschte E-Mails die KI erreichen, und beseitigt damit einen wichtigen Übertragungsweg für den Angriff.
Content-Spezialist bei PowerDMARC
Milena ist eine erfahrene Autorin und Inhaltserstellerin mit mehr als 7 Jahren Erfahrung in der Erstellung ansprechender Inhalte über IT, Cybersicherheit, virtuelle Veranstaltungen und mehr. Sie hat eine nachgewiesene Erfolgsbilanz bei der Erstellung hochwertiger Arbeiten für internationale Magazine und ist Absolventin renommierter Institutionen wie der New York University Abu Dhabi, UWC China und dem College of Europe.
Neueste Beiträge von Milena Baghdasaryan (alle anzeigen)
- Die neue Masche, mit der Hacker Finanz-KI-Assistenten austricksen – 7. September 2026
- Bewährte Verfahren für die DNS-Sicherheit: Eine umfassende Checkliste zur Absicherung – 7. September 2026
- Dynamischer SPF vs. automatischer SPF vs. gehosteter SPF: Welche Variante korrigiert Ihren SPF-Eintrag tatsächlich? – 25. August 2026
