LLM Penetration-Testing aus technischer Perspektive

Key Takeaways

• LLMs unterscheiden technisch nicht zwischen System-Instruktionen (Sicherheitsregeln) und Benutzer-Inputs. Alles wird als ein zusammenhängender Textblock verarbeitet, was Manipulationen (Prompt Injections) Tür und Tor öffnet.

• Angreifer können schadhafte Anweisungen in Dokumenten (PDFs, Wikis) verstecken. Sobald ein System diese via Retrieval-Augmented Generation (RAG) einliest, übernimmt das LLM diese "fremden" Befehle als Teil seines Arbeitsauftrags.

• Ein LLM hat kein eingebautes Verständnis für Zugriffsberechtigungen. Die Prüfung, welcher Nutzer welche Dokumente sehen darf, muss zwingend vor der Übergabe an das Modell im Backend erfolgen.

• Wenn LLMs APIs oder Datenbanken ansteuern, agieren sie als unsichere Vermittler. Ohne strikte externe Validierung können manipulierte Prompts unautorisierte Aktionen (z. B. Datenlöschung oder Exfiltration) im Backend auslösen.

• Da LLMs statistisch und nicht deterministisch arbeiten, sind Sicherheitsmechanismen auf Textbasis niemals 100% verlässlich. Ein robuster Schutz erfordert eine Absicherung der gesamten Software-Architektur, nicht nur des Prompts.

Angriffsmöglichkeiten, Systemverhalten und reale Schwachstellen in produktiven KI-Integrationen

Der produktive Einsatz von Large Language Models (LLMs) in Unternehmen

nimmt deutlich zu. Dabei reicht das Spektrum von öffentlich erreichbaren

Chatbots auf Unternehmenswebsites bis hin zu internen Assistenzsystemen,

die auf Wissensdatenbanken, Dokumentenablagen oder proprietäre

Datenquellen zugreifen. Technisch betrachtet entstehen dadurch hybride

Systeme, die klassische Softwarearchitekturen mit probabilistischen

Sprachmodellen kombinieren.

Die Sicherheitsanalyse solcher Systeme unterscheidet sich grundlegend

von traditionellen Penetrationstests. Der wesentliche Unterschied liegt

im Charakter des Modells selbst: Ein LLM ist eine Blackbox. Der Weg vom

Input zum Output ist nicht deterministisch nachvollziehbar. Das Modell

berechnet Token-Wahrscheinlichkeiten auf Basis seines Trainings und des

aktuellen Kontexts. Welche Teile eines Prompts stärker gewichtet werden,

wie interne Sicherheitsinstruktionen priorisiert werden oder wie

konkurrierende Anweisungen aufgelöst werden, ist nicht transparent

einsehbar -- insbesondere bei proprietären Cloud-Modellen.

Diese Intransparenz hat direkte sicherheitstechnische Konsequenzen.

Während klassische Software auf klar definierte Kontrollflüsse,

Bedingungen und reproduzierbare Logik setzt, reagiert ein LLM

kontextsensitiv und statistisch. Zwei nahezu identische Eingaben können

unterschiedliche Ausgaben erzeugen. Sicherheitsmechanismen, die rein auf

textuelle Instruktionen im Prompt basieren, stellen daher keine robuste

technische Isolation dar.

Vom Prompt zur Antwort: Technische Realität

In produktiven Umgebungen wird ein Benutzerinput selten isoliert an das

Modell übergeben. Typischerweise entsteht ein zusammengesetzter Prompt,

der aus Systemanweisungen, Entwicklerlogik, Benutzeranfrage und

gegebenenfalls aus extern abgerufenen Kontextinformationen besteht. Für

das Modell ist dies letztlich ein zusammenhängender Textblock. Es

existiert keine echte, technisch erzwungene Trennung zwischen

„Sicherheitsrichtlinie" und „Benutzereingabe".

Das Modell verarbeitet alles sequenziell als Text. Genau hier liegt der

Kern vieler Angriffe.

Prompt Injection als strukturelles Problem

Prompt Injection ist kein klassischer Injection-Angriff im Sinne von SQL

oder Command Injection, sondern eine Manipulation der textuellen

Entscheidungsgrundlage des Modells. Da Sicherheitsregeln häufig

ebenfalls als Text formuliert sind („Beantworte keine vertraulichen

Fragen", „Gib keine internen Informationen preis"), kann ein Angreifer

versuchen, diese Anweisungen durch neue Instruktionen zu relativieren

oder zu überschreiben.

Das Modell besitzt keine inhärente Fähigkeit, zwischen legitimer Policy

und schadhafter Anweisung eindeutig zu unterscheiden. Es bewertet

Token-Wahrscheinlichkeiten. Wenn eine manipulierte Benutzeranweisung

semantisch stark formuliert ist oder geschickt kontextualisiert wird,

kann sie die ursprünglich gesetzten Sicherheitsinstruktionen überlagern.

Da der interne Entscheidungsprozess nicht transparent ist, erfolgt die

Sicherheitsprüfung hier zwangsläufig adversarial: Man testet

systematisch, wie sich konkurrierende Instruktionen auswirken und ob

Schutzmechanismen tatsächlich robust sind oder nur scheinbar existieren.

Interne LLMs und das Risiko durch Dokumentenanalyse

Besonders relevant werden diese Fragestellungen bei internen

LLM-Systemen, die mit Retrieval-Augmented Generation (RAG) arbeiten. In

solchen Architekturen werden Unternehmensdokumente -- etwa PDFs,

Office-Dateien, Wiki-Inhalte oder CRM-Daten -- automatisch analysiert,

in Text umgewandelt, vektorisiert und in einer Datenbank indexiert.

Wird später eine Benutzeranfrage gestellt, sucht das System semantisch

passende Dokumente und fügt deren Inhalte dem Prompt als Kontext hinzu.

Das Modell generiert darauf basierend seine Antwort.

Technisch bedeutet das: Der Inhalt von PDF-Dateien wird vollständig

extrahiert und dem Modell als Text zur Verfügung gestellt. Dabei gehen

visuelle Trennungen, Formatierungen oder semantische Struktur oft

verloren. Auch versteckte Textbereiche oder Metadaten können indexiert

werden, sofern sie nicht explizit gefiltert werden.

Hier entsteht ein besonders kritisches Angriffsszenario. Wenn ein

Angreifer in der Lage ist, manipulierte Inhalte in ein indexiertes

Dokument einzubringen -- etwa in ein internes Wiki, ein freigegebenes

PDF oder eine gemeinsam genutzte Dokumentenablage -- kann er schadhafte

Instruktionen platzieren, die später vom LLM verarbeitet werden.

Da das Modell nicht zwischen „Benutzerprompt" und „Dokumentkontext"

unterscheidet, kann eine im PDF platzierte Anweisung Teil der

Entscheidungsgrundlage werden. Die eigentliche Angriffsoberfläche ist

damit nicht mehr das Chat-Interface, sondern die Dokumentenbasis des

Unternehmens.

Ein praxisnahes Szenario ergibt sich im Recruiting-Prozess: Bewerbungen

werden häufig über öffentlich erreichbare Webformulare eingereicht.

Lebenslauf (CV) und Cover Letter werden als PDF hochgeladen,

automatisiert gespeichert und intern abgelegt. Greift die HR-Abteilung

später über ein internes LLM-System auf diese Dokumente zu -- etwa zur

Zusammenfassung von Profilen oder zum Vergleich von Kandidaten -- werden

die Inhalte dieser PDFs vom System ausgelesen und verarbeitet.

Platziert ein Angreifer nun gezielt schadhafte Instruktionen im

Lebenslauf oder im Anschreiben, können diese über den Dokumenten-Index

in das interne LLM gelangen. Der Angriffspfad verläuft damit von einer

öffentlich erreichbaren Upload-Funktion über das Dokumentenmanagement

bis in ein internes KI-System. Technisch handelt es sich um eine

indirekte Injection, die nicht über das Interface des LLM erfolgt,

sondern über einen vorgelagerten Geschäftsprozess.

Viele Organisationen berücksichtigen dieses Risiko nicht, da sie davon

ausgehen, dass Dokumente lediglich als Informationsquelle dienen.

Tatsächlich werden sie jedoch integraler Bestandteil des Prompts und

damit potenzieller Angriffsvektor.

Zugriffskontrolle und Datenexfiltration

Ein weiteres strukturelles Problem interner LLM-Systeme liegt in der

Zugriffskontrolle. Das Modell selbst kennt keine Berechtigungen. Es

verarbeitet lediglich den Kontext, der ihm vom Backend übergeben wird.

Wenn das Retrieval-System Dokumente abruft, ohne eine saubere

Dokument-Level-Access-Control durchzusetzen, kann es passieren, dass dem

Modell Inhalte übergeben werden, die der anfragende Benutzer eigentlich

nicht sehen dürfte. Das Modell wird diese Inhalte dann unter Umständen

in seiner Antwort verwenden oder zumindest indirekt darauf

referenzieren.

Angriffe erfolgen hier häufig iterativ. Durch geschicktes Nachfragen,

Umformulierungen oder Kontextverschiebungen lassen sich Informationen

schrittweise rekonstruieren. Selbst wenn keine vollständigen Dokumente

ausgegeben werden, können Fragmente oder Zusammenfassungen sensible

Inhalte preisgeben.

Das Kernproblem ist architektonisch: Sicherheitslogik darf nicht dem

Modell überlassen werden, sondern muss vor der Kontextgenerierung

technisch erzwungen werden.

Tool-Integration und aktive Systemeingriffe

Mit der Einführung von Function Calling oder Tool-Integrationen

verschiebt sich das Risikoprofil weiter. Das Modell generiert nicht mehr

nur Text, sondern strukturierte Aufrufe an Backend-Funktionen. Diese

können Datenbankoperationen ausführen, Tickets erstellen oder externe

APIs ansprechen.

Wenn solche Funktionsaufrufe nicht strikt validiert und serverseitig

autorisiert werden, kann ein Angreifer über manipulierte Prompts

indirekt Aktionen auslösen. Besonders kritisch wird es, wenn

Backend-Service-Accounts über weitreichende Rechte verfügen und das

Modell als Vermittler agiert.

In diesem Kontext wird deutlich: Ein LLM ist kein sicherheitsbewusster

Akteur. Es folgt statistischen Mustern. Jede sicherheitsrelevante

Entscheidung muss außerhalb des Modells technisch abgesichert sein.

Kontext- und Session-Isolation

Ein weiterer technischer Aspekt betrifft die Verwaltung von

Konversationskontexten. Viele Systeme speichern Chat-Historien oder

nutzen Caching-Mechanismen, um Antworten effizienter zu generieren.

Wenn Kontextdaten nicht sauber isoliert werden, kann es zu Vermischungen

zwischen Nutzern oder Sitzungen kommen. In Multi-Tenant-Umgebungen

stellt dies ein erhebliches Risiko dar. Da das Modell selbst keine

Mandantentrennung kennt, muss diese strikt im Backend durchgesetzt

werden.

Grundlegende technische Erkenntnis

LLM-Systeme sind keine klassischen Softwarekomponenten mit klarer

Entscheidungslogik, sondern probabilistische Textverarbeitungssysteme.

Sie besitzen kein intrinsisches Sicherheitsverständnis und keine

verlässliche Trennung zwischen Instruktion und Daten.

Sobald interne Dokumente automatisiert analysiert, indexiert und in

Prompts integriert werden, erweitert sich die Angriffsfläche erheblich.

Manipulierte PDF-Inhalte, indirekte Prompt Injection über

Wissensdatenbanken und unzureichende Zugriffskontrollen gehören zu den

realistischsten Risiken in produktiven Unternehmensumgebungen.

Die Sicherheitsbewertung solcher Systeme erfordert daher ein

architektonisches Verständnis der gesamten Verarbeitungskette -- vom

Dokumenten-Parsing über Retrieval-Mechanismen bis hin zur

Tool-Ausführung.

Der kritische Punkt liegt nicht allein im Modell, sondern in der Art und

Weise, wie es mit Daten, Kontext und Systemfunktionen verbunden wird.