Security researchers have shown how Amazon's own cloud services can be stitched together into a stealthy command-and-control channel, with its Bedrock AI service translating an attacker's plain-English orders into live actions inside a compromised account. The proof of concept, called NotC2, was published on 6 November by Varonis Threat Labs.

NotC2 is not a vulnerability in Bedrock, and it is not evidence of a real-world attack campaign. It is a demonstration of what an attacker can do after already stealing AWS credentials, using only the victim's own trusted services, so that the command traffic looks like ordinary cloud activity.

Four AWS services, one loop

The framework combines four native AWS services. Amazon SQS, the message queue, acts as the command input channel, receiving orders from the attacker's external server. Because the design is asynchronous, there is no persistent connection for defenders to spot, and native Lambda integration triggers execution automatically whenever a message arrives.

AWS Lambda is the execution engine. An event source mapping invokes a function for each new SQS message, and the function carries out AWS operations using its Lambda execution role, limited to that role's permissions in the compromised account. Each invocation lasts no more than 15 minutes and leaves no persistent process behind, though its activity may still appear in cloud logs.

Amazon SNS is the results channel: the function publishes command output to a topic, and SNS sends it to the attacker's external endpoint once the HTTPS subscription has been confirmed. Amazon Bedrock is the AI command interpreter, translating the attacker's natural-language commands into AWS API calls. Varonis demonstrated the loop enumerating EC2 instances, DynamoDB tables, databases and Lambda functions.

The danger is the permissions, not the model

Varonis stresses that the whole operation stands or falls on the permissions of the compromised credentials. Deployment needs infrastructure-creation and PassRole permissions, so the attacker already owns a lot before NotC2 can run. The runtime role needs permissions including sqs:ReceiveMessage, sns:CreateTopic, sns:Subscribe, sns:Publish and bedrock:InvokeModel.

That is also why the research matters for defenders. The traffic never leaves AWS infrastructure for an unfamiliar domain, so a security team watching for beacons to odd addresses would see nothing unusual. As Varonis puts it, a Lambda execution role that accumulates all of this is functionally a backdoor with an AI assistant.

What defenders should watch for

Varonis lists three detection opportunities. The first is an SNS subscription created by a Lambda execution role that points to an external endpoint. The second is a sudden increase in Bedrock calls under a Lambda execution role, especially one that had not used Bedrock before. The third is the full sequence itself, from an SQS message to a Lambda run, Bedrock activity and an SNS publish to an external subscriber within a short period.

The firm recommends least-privilege IAM roles and monitoring of CloudTrail, Lambda logs, SNS delivery records and Bedrock invocation logs. Its conclusion is that blocking any one step of the chain breaks it. The post reports no use of the technique by attackers and quotes no response from AWS.

The finding lands alongside a cluster of November research into AI agents and cloud security, including a separate disclosure in which a single prompt to a public Bedrock AgentCore agent could extract cloud credentials. Together they point to the same lesson: as AI services gain the power to act inside cloud accounts, the identity and permissions wrapped around them matter as much as the model itself.