Many developers today are using Claude Code, with a growing portion running it through Amazon Bedrock. For enterprise teams, Bedrock offers major advantages: keeping data inside a VPC, leveraging AWS credits, and integrating with existing IAM controls, monitoring, and security policies. Bedrock adoption also grows significantly among larger organizations and enterprise environments – but this setup can also introduce security risks or unintended configuration mistakes in real-world usage. 

If you’re running Claude Code with AWS Bedrock, there’s something you need to know: the AWS credentials you configure for Bedrock don’t stay confined to Bedrock. They might be shared with every shell command, every MCP server, and every subprocess that Claude Code spawns. And depending on how those credentials are scoped, that could mean full access to your entire AWS account. 

The Problem in a Nutshell 

When you set up Claude Code for Bedrock, you store your AWS credentials in ~/.claude/settings.json: 

{ 
   "env": { 
     "AWS_ACCESS_KEY_ID": "...", 
     "AWS_SECRET_ACCESS_KEY": "...", 
     "AWS_DEFAULT_REGION": "us-east-1", 
     "CLAUDE_CODE_USE_BEDROCK": "1" 
   } 
} 

These environment variables get loaded into the Claude Code process. So far, so normal. The issue is that Unix processes inherit environment variables from their parent. Every time Claude Code runs a shell command, spawns an MCP server, or launches any subprocess, those child processes get your AWS credentials too. 

That means any AWS CLI command executed through Claude Code authenticates as your IAM principal. Not just for Bedrock, but for everything that principal has permissions to do. 

How This Goes Wrong in Practice 

The security boundary here is entirely on the IAM policy side, Claude Code itself applies no restriction. If your IAM user only has `AmazonBedrockLimitedAccess`, the blast radius is minimal. But in practice, credentials often have broader permissions than intended. None of the scenarios below require an attacker or a sophisticated exploit, they’re everyday mistakes that happen when AWS credentials are broader than they need to be. 

1. Reusing your everyday IAM user

You already have an IAM user you use for daily development, like deploying lambdas, reading S3, or managing EC2 instances. Instead of creating a dedicated user for Claude Code, you drop those same credentials into settings.json because it’s faster. Now Claude Code has access to everything you do: production databases, customer data in S3, IAM itself. You meant to give it Bedrock access, but you actually gave it your entire AWS footprint. 

2. Operating on the wrong environment

You’re working on a staging project, but the credentials in settings.json belong to your production account. You ask Claude Code to “delete the old test data from S3” or “terminate the idle instances.” Claude Code generates the right AWS CLI commands for the task, but runs them against production. There’s no visual indicator in Claude Code telling you which AWS account or environment is active. The approval prompt shows aws s3 rm, and you click accept because the command looks correct for what you asked. 

3. Permissions drifting over time

You start with a tightly scoped IAM user for Bedrock only. Months later, someone on your team attaches AmazonS3ReadOnlyAccess for a one-off migration script and forgets to remove it. Then PowerUserAccess gets added during an incident for quick debugging. The Claude Code credentials silently gain more power over time, and nobody audits what it can actually do because “it’s just the Bedrock user.” 

4. Shared credentials across a team

A team lead sets up an IAM user for Claude Code and shares the credentials in a wiki or Slack channel for the team to use. Now multiple developers are running Claude Code with the same identity. There’s no way to distinguish who did what in CloudTrail logs. If one developer’s session is compromised through prompt injection, the blast radius covers everyone using those credentials, and attribution is impossible. 

The Attack Scenarios 

This isn’t just a theoretical concern. There are several realistic ways this can go wrong: 

Accidental over-provisioning is the most likely scenario. A developer uses Claude Code normally, unaware that a “clean up old files” prompt could generate AWS CLI commands touching production S3 buckets or EC2 instances. 

Prompt injection is more targeted. An attacker plants malicious instructions in a repository file: a README, a config file, a code comment. When Claude Code reads the file, the injected instruction can influence it to generate AWS CLI commands that exfiltrate data or create backdoor access keys. The user sees an approval prompt but might not catch the malicious intent among legitimate-looking operations. 

Compromised MCP servers inherit the full environment as subprocesses. A malicious or supply-chain-compromised MCP server can silently make AWS API calls using your credentials. 

What You Should Do 

Scope your credentials tightly. The IAM user or role you configure for Claude Code should have the absolute minimum permissions needed, ideally only bedrock:InvokeModel* and related Bedrock actions. Audit what’s attached right now. You might be surprised. 

Consider using Bedrock API keys instead of IAM credentials. Claude Code supports AWS_BEARER_TOKEN_BEDROCK, which is inherently scoped to Bedrock operations. API keys can’t be used by the AWS CLI for non-Bedrock operations. This is the most effective mitigation available today and requires no infrastructure changes. 

Use temporary credentials. If you must use IAM credentials, prefer STS temporary credentials or SSO-based authentication over long-lived access keys. They at least limit the exposure window. 

Pay attention to shell command approval prompts. When Claude Code asks permission to run a command –  read it. Look for aws CLI commands that access services beyond what you’d expect. If you see aws s3, aws ec2, aws iam, or similar, think about whether that’s something you intended to allow. 

Audit your settings.json. Run aws sts get-caller-identity with the configured credentials and check what policies are attached to that principal. If the answer is anything broader than Bedrock access, tighten it. 

The Bigger Picture 

This is a classic example of the principle of least privilege being violated through environment inheritance, a well-understood Unix behavior that becomes a security issue when credentials meant for one purpose are implicitly available for all purposes. 

Claude Code’s shell command approval prompt provides some protection, but it’s a thin layer. Users lack context about which AWS credentials are active and what permissions they grant. Approval fatigue, the tendency to reflexively accept prompts after seeing enough of them, further erodes this safeguard. 

The ideal fix would be credential isolation: Bedrock credentials should be internal to Claude Code and never exposed to shell subprocesses through environment variables. Until that happens, and according to Anthropic, the responsibility falls on you to ensure your credentials are scoped as narrowly as possible. 

The post Using Bedrock with Claude Code? Your AWS Credentials Are Shared With Every Subprocess appeared first on Blog.

Introduction

There’s an automated attack circulating right now that breaks into unprotected Redis servers, takes over the underlying machine, and then carefully puts everything back the way it found it. It restores the database filename. It deletes the tools it used. It detaches from the connections it opened. When it’s done, the server looks healthy. Logs look normal. Nothing appears to be wrong.

Except there’s a new line in /root/.ssh/authorized_keys that wasn’t there before.

We discovered this attack recently targeting a single Redis honeypot. Attacks came from 10 distinct source IPs across six countries, and over 1,200 attack attempts were recorded in a single month. Our data-driven, AI-based honeypot enabled us to detect and analyze this activity in detail.

The Attack

Redis was never designed to face the internet directly. But people expose it: a misconfigured security group, a container with the wrong port mapping, a developer who needs it reachable for a quick test. The default configuration has no password. Port 6379, open to the world.

When our Redis honeypot instance was exposed, the first visitors arrived within minutes. They connected, ran INFO, read the version string, and disconnected. That’s it. They aren’t trying to break in. They’re taking a census- cataloging what’s out there, how old it is, whether it’s protected. Thousands of these scans happen every day across the internet, quiet and mechanical.

Then a second wave showed up. These bots tried something: config set dbfilename backup.db. It’s a test. If Redis accepts the command, it means the server will let you write files to arbitrary paths on the host machine’s disk. The bot doesn’t exploit this. It just records the address and leaves. It’s building a list for someone else.

The real attack came as a single connection that tried five different methods of compromise in rapid sequence. The whole thing took a few seconds. It opened with FLUSHDB to wipe the database and clear the slate, and then worked through the following tricks:

Cron injection: redirect Redis’s save directory to /var/spool/cron/, write a key whose value is a cron entry. Now the host downloads and runs a binary from a C2 server every minute, with a randomly generated filename to dodge signature detection.

Lua sandbox escape: a Debian/Ubuntu packaging decision dynamically linked Redis’s Lua interpreter against the system library, breaking the sandbox. One EVAL command loads io.popen, leading to full RCE. CVE-2022-0543 is four years old, yet still working.

SSH key planting: same file-writing trick, pointed at /root/.ssh/authorized_keys. One line, and the operator has root access forever.

Replication hijacking: SLAVEOF tells Redis to sync from the attacker’s server, which serves a malicious shared object disguised as a database dump. MODULE LOAD turns it into a Redis extension exposing system.exec. This trick leads to full RCE through Redis’s own replication protocol.

Direct execution: use that module to download and run the binary through the shell.

Five methods, one connection, a few seconds- but attackers don’t need all five to work. They just need one.

Then the connection did something unexpected. It started cleaning up.

SLAVEOF NO ONE
 system.exec "rm -rf /tmp/exp.so"
 MODULE UNLOAD system
 config set dbfilename dump.rdb

It detached from the rogue replication server. It deleted the malicious shared library from the disk. It unloaded the module from Redis. It restored the original database filename. Redis is often used for ephemeral data, like sessions, queues, and rate limits, so a cleared database might not even raise an alarm. It just looks like a restart.

The attack was optimized for staying hidden after breaking in. Every forensic trace is reversed. The only artifact left behind is an SSH public key, one line in a file that most administrators never read, indistinguishable from a legitimate entry. Even if you find the malware, kill the process, and delete the cron entry, the key is still there. Root access, on demand, forever. Or until someone manually audits authorized_keys, which is rare.

The Botnets

The SSH Key Operator: A sophisticated, single-operator attack that targets unprotected Redis servers. It attempts five different RCE methods. Over a single month, our single Redis honeypot recorded over 1,200 attack attempts from 10 distinct source IPs across six countries. The majority included RCE attempts: Lua sandbox exploits and replication hijacking aimed at arbitrary command execution on the host. Different C2 servers, different binary names, but the same sequence, the same Lua payload, the same SSH public key. One operator, rotating sources and randomizing filenames. The key is the only constant.

The traffic came in distinct waves. Baseline was roughly 15 to 20 attempts per day from two or three sources. Then, without warning, a wave would hit, with a single IP connecting hundreds of times in an afternoon, once every 69 seconds- in total, over 300 attempts in a few hours. We saw three to four waves per month, each lasting two to six hours, each from a different source IP. Then silence until the next wave.

MGLNDD Botnet: A separate operation that periodically connects to exposed Redis servers, sending a single command format (MGLNDD_54.147.241.42_6379) to perform a “roll call” – checking whether the Redis server is already part of their botnet. It operates from Azure VMs using AWS IP addresses, never repeating the same source twice.

The SSH key operator and the MGLNDD botnet share the same hunting ground but ignore each other completely. Two separate operations are working in the same territory. An exposed Redis port isn’t just targeted by an attacker, it’s targeted by an ecosystem.

Takeaway

The attack is silent. The window between “I’ll fix that config later” and the machine is silently compromised isn’t days or hours-it’s seconds. Everything looks fine afterward: the server is up, the application works, the dashboards are green. The only artifact is an SSH key, patient and persistent, waiting to be used.

What You Must Do:

• Never expose Redis to the internet. Restrict access via security groups, firewalls, or VPCs.
• Set a strong Redis password. The default has none.
• Regularly audit /root/.ssh/authorized_keys for unfamiliar keys-attackers hide persistence here.
• Keep Redis patched. CVE-2022-0543 still works after 4 years.
• Monitor for suspicious commands: CONFIG SET, MODULE LOAD, FLUSHDB, SLAVEOF.
• Use file integrity monitoring on /root/.ssh/authorized_keys to detect tampering.
• Don’t trust green dashboards. Assume you’ve been breached until verified otherwise.

Imperva Data Security solutions provide comprehensive protection for your data against a wide range of threats. These offerings enable security teams to identify the location of sensitive information, monitor access patterns, and detect misuse promptly to facilitate timely response.

The post Your Redis Server Looks Fine. That’s the Problem. appeared first on Blog.