‍

Das Amazon Bedrock AgentCore Starter-Toolkit enthält eine zu freizügige IAM-Rolle, die von Angreifern ausgenutzt werden könnte, um mehrere kritische AgentCore-Komponenten zu kompromittieren. Dieser Artikel demonstriert die praktische Ausnutzung der Angriffskette, die diese Schwachstelle nutzt, und liefert Details zu Angriffstelemetrie, Angriffserkennung und Gegenmaßnahmen.

Einleitung

Kürzlich hat Palo Alto Networks Unit 42 eine Schwachstelle zur Privilegienerweiterung in Amazon Bedrock AgentCore offengelegt, die agentenübergreifende Angriffe ermöglicht, einschließlich des unbefugten Zugriffs auf Agenten-Container-Images und -Speicher. Die agentenübergreifenden Angriffe nutzen zudem schwache Vertrauensgrenzen aus, die eigentlich nur autorisierte Vorgänge sicherstellen sollten. Dieser Artikel untersucht, wie wir diese Schwachstellen als Angriffsszenario in Mitigant Cloud Attack Emulation (CAE) operationalisiert haben, um Unternehmen die Möglichkeit zu geben, die Auswirkungen der Gefährdung sicher zu validieren und die Wirksamkeit ihrer Abwehrmaßnahmen zu bewerten.

Das Szenario emuliert eine vollständige agentenübergreifende Kette zur Privilegienerweiterung, die vier Angriffspfade umfasst, welche durch die überprivilegierte IAM-Ausführungsrolle offengelegt werden. Während die ursprüngliche Offenlegung durch Unit 42 Pfade für Image- und Speichermissbrauch aufzeigte, validiert das Mitigant-Angriffsszenario alle vier Angriffspfade, operationalisiert sie als wiederholbare Angriffskette, analysiert die resultierende Telemetrie sowie Erkennungsmöglichkeiten und bietet entsprechende Gegenmaßnahmen.

Da die Einführung von KI-Diensten immer schneller voranschreitet, wird das Verständnis und die Validierung dieser Fehler in den Vertrauensgrenzen und damit verbundener Schwachstellen immer wichtiger für die Absicherung agentenbasierter Workloads, insbesondere solcher, die auf Amazon Web Services ausgeführt werden.

‍

‍

AgentCore: Eine kurze architektonische Einführung

Amazon Bedrock AgentCore ist eine agentenbasierte Plattform zum Erstellen, Bereitstellen und Betreiben von KI-Agenten, unabhängig von den zugrunde liegenden Frameworks und Large Language Models (LLMs). Wenn ein Unternehmen einen Agenten über das Starter-Toolkit bereitstellt, stellt AgentCore eine Reihe von Komponenten bereit, darunter:

• Runtime: die serverlose Ausführungsumgebung, in der Agenten gehostet werden, wobei jede Sitzung in einer isolierten MicroVM läuft.
• Speicher: der verwaltete Speicher für kurz- und langfristige Agentenzustände, einschließlich Gesprächsverlauf, Benutzerpräferenzen und semantischer Fakten.
• Code-Interpreter: eine isolierte Umgebung (Sandbox), in der ein Agent dynamisch Code schreibt und unter seiner eigenen IAM-Rolle ausführt.
• Identität: der Dienst zur Verwaltung von Anmeldeinformationen für die eingehende und ausgehende Authentifizierung.
• Elastic Container Registry (ECR): der Ort, an den AgentCore Runtime-Images übertragen und von dem sie abgerufen werden.
• IAM-Ausführungsrolle: die Identität, die ein Agent annimmt, um auf die anderen Komponenten zuzugreifen.

‍

‍

‍

Wenn Einfachheit zum Problem wird: Zu freizügige IAM-Rollen

Das AgentCore-Starter-Toolkit generiert automatisch eine IAM-Rolle (Abbildung 3) mit Platzhalter-Berechtigungen, was gegen das Prinzip der geringsten Rechte verstößt und vier Angriffsvektoren auf die AgentCore-Infrastruktur eröffnet. Die IAM-Rolle ist der zentrale Vertrauensanker: Jede Aktion, die ein Agent gegenüber Speicher, Code-Interpreter, Runtime und ECR ausführt, wird durch sie autorisiert. Ihre Eigenschaften bestimmen daher das Ausmaß des Schadens bei einer Kompromittierung. 

Die Rolle mit Platzhaltern gewährt kontoweite Berechtigungen über vier AgentCore-Oberflächen hinweg. Das Gefährliche daran ist der Ressourcenbereich: Jede Anweisung zielt auf einen Platzhalter (*) ab, anstatt auf die eigenen Ressourcen des Agenten.

• ecr:BatchGetImage auf repository/*: Abrufen eines beliebigen Container-Images im Konto.
• bedrock-agentcore:* on memory/*: Lesen oder Schreiben des Memory-Stores eines beliebigen Agents.
• bedrock-agentcore:InvokeCodeInterpreter on *: Aufrufen eines beliebigen Code-Interpreters.
• bedrock-agentcore:InvokeAgentRuntime on runtime/*: Aufrufen einer beliebigen Agent-Runtime.

Zusammengenommen bilden diese Berechtigungen ein vollständiges Primitiv für eine agentübergreifende Kompromittierung: Jeder Agent kann das Image eines anderen Agents abrufen, dessen Speicher lesen oder manipulieren, Code unter der Interpreter-Rolle eines anderen Agents ausführen und die Runtime eines anderen Agents direkt aufrufen. Bitte beachten Sie, dass AWS das Starter Toolkit nicht mehr unterstützt.; der empfohlene Weg ist nun das AgentCore CLI. Dies behebt nicht rückwirkend Bereitstellungen, die bereits mit dem Toolkit erstellt wurden. Jeder damit bereitgestellte Agent kann daher weiterhin die überprivilegierte Ausführungsrolle besitzen, bis diese manuell angepasst wird.

‍

‍

Anatomie der Angriffskette: Vier Angriffswege, ein Vertrauensanker

Die Schwachstelle zur agentübergreifenden Privilegienerweiterung wurde als Mitigant-Angriffsszenario implementiert, das einfach und sicher reproduzierbar orchestriert werden kann. Das Szenario stellt zwei AgentCore-Agents im selben Konto bereit: einen bösartigen Agent (Agent A) und einen Opfer-Agent (Agent B). Die Wildcard-Ausführungsrolle aus dem Starter Toolkit wird Agent A zugewiesen, der daraufhin Agent B angreift und die vier in Abbildung 4 dargestellten Angriffswege ausführt.

‍

‍

Angriffsweg 1: Agentübergreifende ECR-Image-Exfiltration

Unter Verwendung der ECR-Wildcard-Berechtigungen ruft Agent A das Container-Image von Agent B aus der Registry ab. Container-Images enthalten häufig sensible Daten: Quellcode, proprietäre Algorithmen, Konfigurationen, eingebettete Geheimnisse usw.; unbefugter Zugriff und die anschließende Exfiltration stellen ein erhebliches Risiko dar. Dies schafft zudem die Voraussetzungen für die erfolgreiche Ausführung von Weg 2: die Extraktion der Memory-ID von Agent B (BEDROCK_AGENTCORE_MEMORY_ID) aus der env-output.txt-Datei des Containers. Die Memory-ID ist die einzige Hürde für den agentübergreifenden Speicherzugriff. Sowohl das Auslesen des Repositorys (T1213, Daten aus Informations-Repositories) als auch die Wiederherstellung von Anmeldedaten (T1552.001, Anmeldedaten in Dateien) wirkt wie legitime API-Aktivität, was die Erkennung erschwert.

Angriffspfad 2: Speicherzugriff und Poisoning zwischen Agenten

Mit der Memory-ID von Agent B aus Pfad 1 nutzt Agent A die Wildcard-Speicherberechtigungen gegen den Speicher von Agent B aus. Agent A liest den Speicher mit bedrock-agentcore:ListEvents aus und erhält so den Gesprächsverlauf, Benutzerpräferenzen und gesammelte semantische Fakten (MITRE ATLAS AML.T0086, Exfiltration durch Aufruf von KI-Agenten-Tools).

In diesem Angriffsszenario legte eine einzige ListEvents -Anfrage den Gesprächsverlauf des betroffenen Agenten offen, einschließlich produktiver API-Anmeldedaten, Kennzahlen zu Mandanteneinnahmen, Interaktionen mit dem Kundensupport und Daten zur Identitätsprüfung. Die abgerufenen Datensätze zeigten, wie der speicherübergreifende Zugriff zwischen Agenten sowohl sensible Geschäftsinformationen als auch operative Geheimnisse aus ansonsten isolierten Agenten-Workloads preisgeben kann (siehe Abbildung 5).

Anschließend vergiftet Agent A den Speicher mit einem CreateEvent-Aufruf, der bösartige Inhalte einschleust. Diese verbreiten sich durch die Speicherkonsolidierungsstrategien von AgentCore in den zukünftigen Denkprozess von Agent B (ATLAS AML.T0080, KI-Agenten-Kontext-Poisoning: Speicher). Die eingeschleuste Anweisung verwandelt jede zukünftige Antwort in einen unbemerkten Exfiltrationskanal. Da AgentCore das Ereignis in einen strukturierten Speicherdatensatz umwandelt, bleibt es über Sitzungen hinweg bestehen. Poisoning ist in agentenbasierten Systemen besonders gefährlich, da es sitzungsübergreifend wirkt und das Verhalten im Laufe der Zeit unauffällig verändert, ohne die offensichtlichen Anzeichen, die eine Persistenz auf Festplatten- oder Netzwerkebene erzeugen würde.

Angriffspfad 3: Privilegieneskalation durch Code-Interpreter

Code-Interpreter in AgentCore werden unter ihren eigenen IAM-Rollen ausgeführt, die sich von denen des aufrufenden Agenten unterscheiden. Daher wird jeder Code mit den Berechtigungen des Interpreters ausgeführt, nicht mit denen von Agent A. Die Wildcard-Berechtigung InvokeCodeInterpreter für * ermöglicht es Agent A, jeden Interpreter im Konto zu erreichen, nicht nur seinen eigenen. Dies eröffnet einen indirekten Eskalationspfad: Agent A listet die verfügbaren Interpreter auf, identifiziert einen, dessen Rolle über Berechtigungen verfügt, die der eigene Agent nicht besitzt, und führt Code in diesem Kontext aus. Die Eskalation erfolgt nicht automatisch; sie hängt davon ab, eine leistungsfähigere Interpreter-Rolle zu finden, aber der Wildcard-Bereich macht diese Suche erst möglich. Dies entspricht MITRE ATT&CK T1059.009, Befehls- und Skript-Interpreter: Cloud-API und ATLAS AML.T0053, Aufruf von KI-Agenten-Tools. 

Angriffspfad 4: Laufzeit-Hijacking zwischen Agenten

Durch die Nutzung der Wildcard-Berechtigung InvokeAgentRuntime kann Agent A jede AgentCore-Agentenlaufzeit aufrufen und beliebige Prompts übermitteln. Die Folge ist, dass kompromittierte Agentenlaufzeiten die gegebenen Anweisungen unter ihrer eigenen Identität und mit ihren eigenen Tools, Speichern und Berechtigungen ausführen. Dies überschreitet die Vertrauensgrenzen, die Unternehmen zwischen Agenten unterschiedlicher Sensibilität voraussetzen: ein Finanz-Agent, der bösartige Anweisungen von einem Entwickler-Tool-Agenten erhält, oder ein Admin-Agent, der von einem Kundensupport-Agenten manipuliert wird. Die Antwort geht an Agent A zurück und kann für eine direkte Exfiltration oder als Schritt in einer längeren Multi-Agenten-Kette verwendet werden. Dies entspricht ATLAS AML.T0086, Exfiltration durch Aufruf von KI-Agenten-Tools.

‍

Empirische Validierung: Ausführung der Kill Chain

Die schwierigere Frage ist, wie die Kill Chain gegen ein echtes AWS-Konto aussieht, welche Telemetriedaten sie erzeugt und welche Beweise ein Verteidiger sichern kann. Das verwaltete Szenario zur Cross-Agent-Privilege-Escalation in Cloud Attack Emulation (CAE) führt die gesamte Kette von Anfang bis Ende als orchestrierten Angriff aus, nicht als statisches Skript. Es stellt seine eigenen Opfer- und Angreifer-Agenten bereit, weist die Wildcard-Rolle zu, führt die vier Pfade nacheinander aus und baut die Umgebung anschließend wieder ab, sodass es die bestehenden Agenten oder Bereitstellungen des Benutzers nicht berührt und keine Rückstände hinterlässt. Das ausgeführte Szenario erstellt einen Angriffsbericht mit dem vollständigen Ausführungsgraphen, den gesammelten CloudTrail-Beweisen und Sigma-Erkennungsregeln. Das gesamte Szenario ist in etwa vier Minuten abgeschlossen, wobei der Großteil auf die Bereitstellung von AgentCore entfällt und der eigentliche Angriff weniger als eine Minute dauert.

Angriffserkennung

AgentCore stellt zwei SDK-Clients bereit: eine Control Plane (BedrockAgentCoreControlClient) für die Ressourcenverwaltung und eine Data Plane (BedrockAgentCoreClient) für ListEvents, CreateEvent, StartCodeInterpreterSession und InvokeAgentRuntime. Standardmäßig schreibt nur die Control Plane Management-Ereignisse in CloudTrail; für die Data Plane müssen Data Events explizit aktiviert werden.

‍

Dies bedeutet, dass ohne die Aktivierung von Data Events kritische Angriffsereignisse in CloudTrail unsichtbar bleiben, einschließlich des Cross-Agent-Speicherauszugs (ListEvents), der Manipulation (CreateEvent), der Interpreter-Sitzung und des Runtime-Hijackings (InvokeAgentRuntime).

Die Aktivierung von Data Events macht die Data-Plane-Ereignisse sichtbar, jedoch mit zwei Einschränkungen. Erstens ist das Signal im Vergleich zum Rauschen der Control Plane spärlich: Nur ein kleiner Teil der erfassten Ereignisse stellt den eigentlichen Angriff dar; der Rest sind routinemäßige GetMemory- und ListEvents-Aufrufe. Zweitens sind die Anforderungs- und Antwortinhalte an der Quelle geschwärzt: Der CreateEvent-Body, also die tatsächlich im Speicher hinterlegte Anweisung, wird sowohl in S3 als auch in CloudWatch als HIDDEN_DUE_TO_SECURITY_REASONS aufgezeichnet. Der Trail kann zwar belegen, dass ein Cross-Agent-Schreibvorgang stattgefunden hat, aber er kann nicht zeigen, was geschrieben wurde.

‍

‍

Das praktische Fazit: Verteidiger müssen sowohl Data Events für die Ressourcentypen AgentCore Memory, Runtime und Code-Interpreter aktivieren als auch eigene Erkennungsinhalte erstellen, da die entscheidende Telemetrie standardmäßig weder erfasst noch interpretiert wird. Um Teams einen Ausgangspunkt zu geben, gibt jeder Emulationslauf potenzielle Sigma-Regeln aus, die aus der erfassten Telemetrie abgeleitet wurden. Diese decken die Aktivitäten auf der Management-Ebene ab und – sofern Data Events aktiviert sind – auch die Data-Plane-Operationen, die das eigentliche Signal enthalten.

Gegenmaßnahmen gegen Angriffe

Die wichtigste Gegenmaßnahme für diesen Angriff ist identitätsbasiert: Vermeiden Sie Platzhalter (Wildcards) in AWS-Richtlinien und stellen Sie sicher, dass für alle AgentCore-Komponenten das Prinzip der geringsten Rechte (Least Privilege) durchgesetzt wird. Hier sind zudem weitere wichtige Gegenmaßnahmen:

• Pfad 1, ECR-Image-Exfiltration: beschränken Sie ECR-Aktionen auf das eigene Repository des Agenten und halten Sie Geheimnisse sowie Identifikatoren wie BEDROCK_AGENTCORE_MEMORY_ID aus dem Image fern, indem Sie diese zur Laufzeit injizieren.
• Pfad 2, Speicherzugriff und -manipulation: begrenzen Sie, welche Prinzipale in einen Speicher schreiben dürfen, und überprüfen Sie die Herkunft von Inhalten, bevor diese zusammengeführt werden, da das Prinzip der geringsten Rechte zwar den Zugriff verhindert, aber nicht die Persistenz.
• Pfad 3, Eskalation über den Code-Interpreter: beschränken Sie InvokeCodeInterpreter auf den eigenen Interpreter des Agenten, damit ein kompromittierter Agent keine Rolle mit höheren Privilegien übernehmen kann.
• Pfad 4, Laufzeit-Hijacking: behandeln Sie den Aufruf zwischen Agenten als Autorisierungsentscheidung und segmentieren Sie Agenten nach Sensitivität, damit ein Agent mit geringem Vertrauensstatus keinen Agenten mit hohem Vertrauensstatus aufrufen kann.

‍

KI-Agenten-Sicherheit mit Mitigant

Das zentrale Problem im Szenario der agentenübergreifenden Privilegienerweiterung ist kein Fehler in der Logik oder dem Modellverhalten der Agenten. Es resultiert aus Schwachstellen im Identitäts- und Zugriffsmanagement (IAM). Wenn eine einzelne IAM-Rolle als Vertrauensanker für Speicher, Laufzeiten, Interpreter und Container-Artefakte dient, wirken sich Fehler bei der Rechtevergabe auf das gesamte Agenten-Ökosystem aus. Da Unternehmen immer größere Flotten von KI-Agenten einsetzen, wird die Validierung dieser Vertrauensgrenzen ebenso wichtig wie die Validierung der Agenten selbst.

Die Validierung der AgentCore-Exposition ist im Grunde ein Red-Teaming-Problem: Es ermöglicht die empirische Überprüfung der Wirksamkeit von Sicherheitsmaßnahmen gegen diese Schwachstellen. Das im Artikel beschriebene Szenario (Agentenübergreifende Privilegienerweiterung) ist auf der Mitigant-Plattform als verwaltetes, in sich geschlossenes Szenario verfügbar. Bei der Ausführung stellt das Szenario die gesamte Infrastruktur als isolierte Ressourcen bereit, führt die vier Pfade aus und bereinigt die Umgebung anschließend. Ein umfassender Bericht mit Korrekturmaßnahmen und entsprechenden Sigma-Regeln wird bereitgestellt.

Melden Sie sich noch heute an und sichern Sie proaktiv Ihre auf Amazon Bedrock AgentCore basierende KI-Infrastruktur - https://mitigant.io/en/sign-up

‍