Entweder Unternehmen führen LLM-Penetrationstests durch —oder Angreifer übernehmen den Job.
Im September 2025 wurde ein historischer Wendepunkt erreicht: Zum ersten Mal führte eine KI weitgehend autonom und teilweise erfolgreich einen Cyberangriff durch. Keine klassische Hackergruppe, keine Malware-Toolkits, sondern ein agentisches KI-System basierend auf Standardtools. Der Angriff wurde von einem chinesisch staatlich unterstützten Akteur durchgeführt und nutzte Anthropic Claude Code, um automatisiert 80–90 % der operativen Cyber-Attacke ohne menschliche Steuerung auszuführen.
Dies beinhaltete:
- „Reconnaissance“ (Zielerkundung),
- „Exploit-Entwicklung“ (Ausnutzen gefundener Schwachstellen),
- „Credential-Theft“ (Diebstahl von Zugangsdaten),
- „Lateral Movement“ (Seitwärtsbewegung im Netzwerk zur Ausweitung der Rechte),
- „Datenextraktion“ (gezieltes Auslesen vertraulicher Informationen) und
- „Exfiltration“ (unerlaubter Abfluss der Daten nach außen).
Die KI handelte orchestriert, skalierbar, 24/7 und mit einer Geschwindigkeit, die kein menschliches Team erreicht. Erstmals wurden hochrangige Unternehmen und Regierungsbehörden kompromittiert — nicht von Menschen, sondern von KI-Agenten.
Dieser Fall zeigt:
Cyberangriffe werden künftig nicht nur digitaler — sondern autonomer. Die Frage ist nicht, ob KI angegriffen wird, sondern ob Ihre KI sicher ist.
Damit werden die unangenehmen Fragen an jedes Unternehmen immer dringender:
- Wissen Sie, welche Ihrer Softwareanwendungen bereits KI enthalten?
- Gibt es eine vollständige, gepflegte Liste in Ihrem Unternehmen?
- Wer bewertet regelmäßig die Sicherheitsrisiken dieser KI-Systeme?
Die Realität im Mittelstand: Die meisten Unternehmen nutzen bereits KI — ohne geprüft zu haben, ob die Systeme sicher sind. Besonders LLM-basierte Lösungen (z. B. Chatbots, Co-Piloten, RAG-Systeme, Automations-Agenten) erzeugen eine neue Klasse von Angriffsflächen:
LLM-Systeme benötigen eigene, spezialisierte Penetrationstests — klassische Penetrationstests reichen nicht aus.
LLM-Penetrationstests unterscheidet sich grundlegend von klassischen IT-Penetrationstests:
1. Fokus auf Infrastruktur & deterministische Software (IT) vs. Fokus auf Modell, API, Kontext, probabilistische Ausgaben (LLM)
2. Schwachstellen sind überwiegend technischer Natur (IT) vs. Schwachstellen sind technisch, datenschutzrechtlich & inhaltlich (LLM)
3. Exploit-Kette ist vorhersehbar (IT) vs. Ergebnisse können variieren (Nicht-Determinismus) (LLM)
4. Ziel: System übernimmt keine falschen Befehle (IT) vs. KI führt keine schädlichen Inhalte aus oder gibt keine sensiblen Daten preis (LLM)
5. Angriffsvektoren sind begrenzt (IT) vs. Prompt Injection, Indirect Prompt Injection, RAG-Manipulation, Tool-Missbrauch, API-Abuse etc. (LLM)
Wer KI wie klassische Software behandelt, hat einen blinden Fleck bei IT- Sicherheit, der immer größer wird.
Die Bandbreite möglicher Schäden durch unsichere LLM-Systeme ist deutlich größer, als vielen Unternehmen bewusst ist. Ein einziger Vorfall kann sowohl immaterielle als auch finanzielle Folgen nach sich ziehen. Besonders kritisch sind Reputationsschäden, etwa wenn KI-Systeme versehentlich vertrauliche interne Informationen an Kunden ausgeben. Hinzu kommen rechtliche Risiken, etwa wenn eine KI diskriminierende oder gesetzeswidrige Entscheidungsvorschläge erzeugt und damit Compliance- und Haftungsfragen auslöst. Wirtschaftliche Schäden entstehen, wenn KI-Systeme über APIs oder Tool-Anbindungen proprietäre Daten, Quellcode, Konstruktionspläne oder Produktinformationen exfiltrieren. Ebenso gravierend sind operative Schäden, wenn automatisierte KI-Agenten irreversible Aktionen ausführen – von fehlerhaften Bestellungen über falsche Vertragsänderungen bis hin zu ungewollten System- oder Prozessinterventionen.
Diese Szenarien sind keine Theorie — sie treten bereits real in Unternehmen auf und kein Betroffener spricht gerne darüber.
LLM-Penetrationstests können nicht nur wirtschaftliche Schäden vermeiden, sondern haben sich zur Compliance-Pflicht entwickelt . Dabei gibt es verschiedene relevante gesetzliche Regulierungen:
- DSGVO: KI darf personenbezogene Daten nicht unkontrolliert verarbeiten oder preisgeben
- AI Act: Hoch- und mittelrisikobehaftete KI-Systeme benötigen eine dokumentierte Risikoprüfung. Dabei fallen unter mittelrisikobehaftete Systeme zum Beispiel KI-Chatbots, Voicebots und Co-Piloten im Kundenservice oder KI zur Kundensegmentierung im Marketing.
- Cyber Resilience Act (CRA): Software mit digitalem Risiko muss vor und während des Einsatzes getestet werden. Dies umfasst fast jede Unternehmensanwendung wie ERP-Systeme (z. B. SAP), CRM-Systeme (z. B. Salesforce), HR-Software, Finanz-/ Buchhaltungssoftware, Shopsysteme (Shopify, Shopware), Payment-Gateways oder Customer-Service-Bots.
- Dazu kommen branchenspezifische Regulierungen wie NIS-2 oder DORA für kritische Unternehmen oder im Finanzwesen.
Nicht immer sind diese gesetzlichen Regelungen und die mit Ihnen verbundenen Bußgeldrisiken im Mittelstand bekannt.
Wir teilen LLM-Penetrationstests in vier Phasen ein:
Phase 1 – IST-Analyse
• Welche KI-Systeme sind im Einsatz?
• Welche Daten verarbeiten sie?
• Welche Geschäftsrisiken entstehen bei Missbrauch?
Ziel der Phase: Klarheit darüber, welche LLM-Systeme existieren und welche davon aus Risikogesichtspunkten wie intensiv geprüft werden müssen.
Phase 2 – Threat Modeling & Testplanung
In dieser Phase wird systematisch analysiert, welche Angriffe auf das jeweilige LLM realistisch möglich sind. Dafür kommen etablierte Methoden wie STRIDE oder MITRE ATT&CK zum Einsatz. STRIDE und MITRE ATT&CK liefern einen strukturierten Ansatz, um aus möglichen Angriffen konkrete, priorisierte Risikoszenarien für das jeweilige KI-System abzuleiten.
Typische Bedrohungsszenarien, die identifiziert und bewertet werden:
• Prompt Injection – Manipulation des Modells über Eingaben
• Credential & Data Leakage – ungewollte Preisgabe sensibler Daten
• Halluzinationen mit Geschäftsfolgen – falsche, aber plausibel klingende Aussagen
• Bias-Propagation – diskriminierende oder fehlerhafte Muster in Ergebnissen
• Tool-Missbrauch – z. B. automatisierte Code-Ausführung über Agentenfunktionen
Ziel der Phase: Risiken, Angriffswege und Prioritäten definieren, bevor getestet wird.
Phase 3 – Testdurchführung
Auf Basis des Threat Modeling werden gezielte Tests durchgeführt. Dabei wird überprüft, ob und wie sich das LLM manipulieren, ausnutzen oder missbrauchen lässt.
Typische Testkategorien:
• API-Sicherheit – Zugriffsschutz, Authentifizierung, Rate-Limits
• Inferenz-Manipulation – Manipulation der Ausgaben durch präparierte Eingaben
• RAG-Manipulation – Angriff auf externe Datenquellen und Index
• Rollen- & Tool-Missbrauch – unautorisierte Aktionen über Agentenfähigkeit
• Jailbreak-Resistenz – Widerstand gegen Umgehung von Sicherheitsrichtlinien
Ziel der Phase: Reproduzierbarer Nachweis von Schwachstellen.
Phase 4 – SOLL-Festlegung & Umsetzung
• Priorisierte Risikoeinschätzung
• Technische & organisatorische Handlungsempfehlungen
• Umsetzung
• Zeitplan für erneute Tests (Empfehlung: alle 6 – 12 Monate)
Ziel der Phase: Schwachstellen dokumentieren, beheben und den Sicherheits-Status überprüfbar machen.
Für den LLM-Penetrationstest müssen die sicherheitskritischen Schwerpunkte klar definiert werden: Auf Modell-Ebene stehen Prompt Injection (manipulative Eingabe), ungewollte Datenoffenlegung (Information Leakage) und rechtlich riskante Halluzinationen im Mittelpunkt.
In der Ausführungsumgebung geht es vor allem um den Schutz von Modellgewichten und API-Zugängen sowie um ausreichende Ratenlimits, um Industriespionage und missbräuchliche Systemüberlastung zu verhindern.
In der Bereitstellung entsteht zusätzlich das Risiko von Cross-Tenant-Leaks – also dem versehentlichen Zugriff eines Mandanten auf Daten eines anderen Mandanten.
Beim oben dargestellten Angriff mit Claude haben sich die Angreifer als Sicherheitstester bzw. Mitarbeiter legitimer Cybersecurity-Firmen ausgegeben.
Es gibt verschiedene Tools, die man bei LLM-Penetrationstests einsetzen kann:
- Threat Modeling (Modellierung von Angriffspfaden): STRIDE, MITRE ATT&CK
- Adversarial Testing (Gezielte Manipulation von Eingaben): Garak, LLM-Guard
- Bias-Analyse (Erkennung systematischer Verzerrungen): Aequitas
- Prompt Injection Tests (Robustheit gegen Jailbreak & Manipulation): LLM-PI-Toolkit
- Datenextraktionstesting (Abwehr gegen Datenlecks): LLM-LeakCheck
- API-Testing (Authentifizierung, Autorisierung & Zugriffsschutz): OWASP ZAP
- Testautomatisierung (Skalierbare Attack-Simulation): Langfuse Security
- Lasttests (Prüfung von Ratenlimit & Robustheit): Locust
Mit dem „Leitfaden für Penetrationstests von Large-Language-Modellen (LLMs)“ hat der Expertenkreis KI-Sicherheit (Allianz für Cybersicherheit / BSI) erstmals einen konsolidierten Standard für LLM-Sicherheitsprüfungen veröffentlicht. Dieser Artikel greift die zentralen Inhalte daraus auf und übersetzt sie in konkrete Handlungsoptionen für Unternehmen. Empfohlenes Vorgehen:
Damit lässt sich genau die zentrale Lücke schließen, die autonome KI-Angriffe heute ausnutzen: fehlende Transparenz über KI-Systeme, fehlendes KI-Risikomanagement und fehlende KI-Sicherheitsprüfungen.
Wenn Unternehmen diese Schritte heute nicht einleiten, tut es morgen der Angreifer.
