Security researchers have unveiled a proof-of-concept named NotC2, a command-and-control (C2) framework that operates entirely within Amazon Web Services (AWS), using Amazon Bedrock to convert simple English instructions into cloud API calls. This technique doesn’t exploit a vulnerability in Bedrock itself—it assumes an attacker already possesses valid AWS credentials.
How NotC2 Runs Inside AWS
Traditional C2 tools rely on custom servers or obscure protocols, which defense systems often detect and block. To evade detection, attackers have shifted toward abusing trusted platforms such as messaging services and cloud storage. NotC2 extends that pattern by embedding its entire C2 loop inside AWS, using native services to carry out each stage autonomously.
The framework chains together several AWS services, each handling a distinct role: Amazon SQS for incoming commands, AWS Lambda to process them, SNS to send the results back out, and Amazon Bedrock as the AI engine that translates plain English input into API calls. Rather than having human operators write elaborate CLI commands, attackers can submit declarative prompts—like “list all running EC2 instances with their IPs”—and Bedrock builds and executes the necessary call.
Permissions, Detection, and Defensive Strategies
Everything depends on what the stolen AWS identity is allowed to do. Deploying NotC2 requires permissions such as creating SQS queues, deciding Lambda functions with event source mappings, and passing IAM roles. At runtime, the Lambda execution role must be able to read queue messages, publish to SNS topics, invoke Bedrock models, and access target services like EC2, S3 or DynamoDB.
Because the traffic flows through trusted AWS channels and only from the victim’s environment, network monitoring tools won’t see unusual domains, strange IPs or foreign protocols. Indicators lie instead within internal AWS logs: CloudTrail, Lambda execution logs, SNS delivery logs, and particularly sawtooth-sequences of SQS message, Lambda run, Bedrock invocation, then SNS publish to an external endpoint.
To defend against NotC2, organizations should follow least-privilege practices: limit the ability to create sensitive AWS resources like queues, functions, and external SNS subscriptions; restrict which roles can invoke Bedrock or pass powerful Lambda roles; and lock down Lambdas’ access to the network. Controlling or approving external SNS topics will also help cut off unauthorised exfiltration.
NotC2 reveals a serious limitation of perimeter-based security in modern, serverless, cloud-native environments. Without a visible C2 server or unusual external domains, detection must pivot from external traffic to misused internal services and bizarre permission combinations. The chain fails if any required link is blocked—making IAM controls and cloud resource governance more critical than ever.
It’s one thing to hide malicious payloads in cloud storage or domains—NotC2 shows the next evolution: an AI-powered, fully managed loop running inside AWS itself. For defenders this means viewing machine-identity abuse, cloud service abuse, and excessive privileges as just as dangerous as network-level threats. Watch the logs, enforce strong roles, and treat AI decoders like Bedrock as potential attack vectors—not just productivity tools.
