Acht Angriffsvektoren in AWS Bedrock entdeckt — AI-Infrastruktur ist die neue Frontlinie

Forscher von XM Cyber haben acht validierte Angriffspfade innerhalb von AWS Bedrock identifiziert, über die Angreifer AI-Agenten übernehmen, Prompts manipulieren, Wissensdatenbanken stehlen und Sicherheitsmechanismen schwächen können — ohne das Modell selbst anzutasten.

🔍 Warum das wichtig ist

AWS Bedrock ist Amazons führende Plattform für die Entwicklung AI-gestützter Anwendungen. Sie verbindet Basismodelle direkt mit Unternehmensdaten — Salesforce-Instanzen, SharePoint-Bibliotheken, Lambda-Funktionen und S3-Buckets. Diese Konnektivität macht sie leistungsfähig — und gleichzeitig zu einem Angriffsziel.

Wenn ein AI-Agent Ihr CRM abfragen, serverlose Funktionen auslösen oder Daten aus einer Wissensdatenbank abrufen kann, wird er zu einem Knotenpunkt Ihrer Infrastruktur — mit Berechtigungen, Erreichbarkeit und Pfaden zu kritischen Ressourcen. Das Bedrohungsforschungsteam von XM Cyber hat nun nachgewiesen, dass eine einzige übermäßig privilegierte Identität ausreicht, um den gesamten AI-Stack zu kompromittieren.

⚡ Die acht Angriffsvektoren

1. Angriffe auf Modellaufrufprotokolle

Bedrock protokolliert jede Modellinteraktion zu Compliance-Zwecken. Angreifer können mit bedrock:PutModelInvocationLoggingConfiguration Protokolle an von ihnen kontrollierte S3-Buckets umleiten und dadurch unbemerkt jeden Prompt erfassen. Eine zweite Variante nutzt s3:DeleteObject, um Beweise für Jailbreaking-Aktivitäten zu beseitigen.

2. Angriffe auf Datenquellen von Wissensdatenbanken

Mit RAG verbundene Datenquellen (S3, Salesforce, SharePoint, Confluence) sind direkt erreichbar. Ein Angreifer mit Zugriff auf s3:GetObject kann das Modell vollständig umgehen und rohe Unternehmensdaten abrufen. Schlimmer noch: Gestohlene Zugangsdaten können laterale Bewegungen in das Active Directory ermöglichen.

3. Angriffe auf Datenspeicher von Wissensdatenbanken

Vektordatenbanken wie Pinecone und Redis Enterprise Cloud speichern indiziertes Wissen. Offengelegte Zugangsdaten in StorageConfiguration verschaffen Angreifern vollständigen administrativen Zugriff auf Vektorindizes und sämtliche strukturierten Daten in Aurora oder Redshift.

4. Direkte Angriffe auf Agenten

Mit bedrock:UpdateAgent-Berechtigungen können Angreifer den Basis-Prompt eines Agenten umschreiben, um interne Anweisungen und Werkzeugschemas offenzulegen. In Kombination mit bedrock:CreateAgentActionGroup binden sie bösartige Ausführungskomponenten an legitime Agenten an und ermöglichen so unautorisierte Datenbankänderungen, getarnt als normale AI-Workflows.

5. Indirekte Angriffe auf Agenten

Anstatt die Agentenkonfiguration anzugreifen, nehmen Angreifer unterstützende Lambda-Funktionen ins Visier. Mit lambda:UpdateFunctionCode oder lambda:PublishLayer schleusen sie Schadcode in die Werkzeugaufrufe ein, auf die Agenten angewiesen sind — und können so unbemerkt Daten exfiltrieren oder Antworten manipulieren.

6. Flow-Injection-Angriffe

Bedrock Flows definieren mehrstufige AI-Workflows. Angreifer mit bedrock:UpdateFlow können zusätzliche S3- oder Lambda-Knoten einschleusen und sensible Eingaben an Angreifer-Endpunkte weiterleiten, ohne die Anwendungslogik zu beeinträchtigen. Sie können außerdem Bedingungsknoten verändern, um Autorisierungsprüfungen zu umgehen.

7. Schwächung von Schutzmechanismen

Schutzmechanismen filtern toxische Inhalte, blockieren Prompt Injection und schwärzen personenbezogene Daten. Ein Angreifer mit bedrock:UpdateGuardrail kann Schwellenwerte systematisch senken und Modelle dadurch anfällig für Manipulationen machen. Mit bedrock:DeleteGuardrail verschwinden die Schutzmaßnahmen vollständig.

8. Manipulation verwalteter Prompts

Bedrock Prompt Management zentralisiert Vorlagen anwendungsübergreifend. Angreifer mit bedrock:UpdatePrompt können Vorlagen im laufenden Betrieb verändern und Anweisungen wie „Sicherheitsregeln ignorieren“ oder „Backlinks des Angreifers einfügen“ einschleusen. Die Änderungen lösen keine erneute Bereitstellung aus, wodurch sie äußerst schwer zu erkennen sind.

🎯 Zentrale Erkenntnis: Das Modell ist nicht das Ziel

Alle acht Vektoren folgen einem gemeinsamen Muster: Angreifer nehmen die Berechtigungen, Konfigurationen und Integrationen rund um das Modell ins Visier — nicht das Modell selbst. Traditionelle AI-Sicherheit konzentriert sich auf Prompt Injection und Jailbreaking und übersieht dabei die eigentliche Angriffsfläche: IAM-Richtlinien, Datenquellenkonfigurationen und die Infrastruktur, die AI mit Unternehmenssystemen verbindet.

🛡️ Sofortmaßnahmen für Sicherheitsteams

1. Bedrock-IAM-Richtlinien prüfen — Wenden Sie das Prinzip der geringsten Rechte auf alle mit AI-Workloads verbundenen bedrock:*, lambda:*- und s3:*-Berechtigungen an
2. Änderungen an Protokollkonfigurationen überwachen — Lösen Sie bei jedem Aufruf von PutModelInvocationLoggingConfiguration eine Warnung aus
3. Zugangsdaten verschlüsseln und rotieren — Alle Zugangsdaten für Datenquellen und Datenspeicher sollten AWS Secrets Manager mit automatischer Rotation verwenden
4. Agentenkonfigurationen absichern — Beschränken Sie UpdateAgent und CreateAgentActionGroup ausschließlich auf CI/CD-Pipelines
5. Prompts versionieren — Behandeln Sie verwaltete Prompts wie Code: Änderungen müssen geprüft, genehmigt und revisionssicher protokolliert werden
6. Ihre AI-Angriffsfläche abbilden — Nutzen Sie Exposure Management, um alle Pfade von AI-Workloads zu kritischen Ressourcen zu identifizieren
7. Widerstandsfähigkeit der Schutzmechanismen testen — Überprüfen Sie regelmäßig, dass Schutzmechanismen nicht durch Konfigurationsänderungen geschwächt werden können

📊 Auswirkungen von NIS2 und DORA

Für Unternehmen in der EU haben diese Erkenntnisse direkte regulatorische Auswirkungen. NIS2 verlangt Risikomanagement in der Lieferkette und die Meldung erheblicher Sicherheitsvorfälle. Die Kompromittierung von AI-Infrastruktur — insbesondere über Cloud-Dienste von Drittanbietern — fällt eindeutig in diesen Anwendungsbereich. Das Rahmenwerk von DORA für das IKT-Risikomanagement verlangt von Finanzunternehmen, alle digitalen betrieblichen Abhängigkeiten einschließlich AI-gestützter Automatisierung zu erfassen und zu testen.

Unternehmen, die AWS Bedrock produktiv einsetzen, sollten diese Angriffsvektoren in ihren Risikobewertungen dokumentieren und die Kontrollen im Rahmen ihres NIS2-Compliance-Programms validieren.