NotC2 turns AWS services into a proof-of-concept C2 chain

Varonis Threat Labs built NotC2 as a proof-of-concept command-and-control framework that runs entirely on native AWS services. It uses Amazon Bedrock to turn plain English into cloud commands, and it depends on an attacker already having AWS credentials.

Service abuse inside AWS

NotC2 is described as service abuse rather than a flaw in Bedrock. The framework only works after stolen or otherwise obtained AWS credentials are already in hand, so it is tied to existing access rather than new access creation. Varonis said the loop stays inside AWS and gives each service a specific role in moving commands and results through the system.

The framework’s name comes from “notification” and “C2,” according to the technical research published by Varonis Threat Labs. The design uses four AWS services, and the workflow assigns each one a different task. Amazon SQS carries commands in, AWS Lambda runs the function, Amazon SNS sends results out, and Amazon Bedrock interprets natural-language requests.

How the loop is assembled

The command path starts with Amazon SQS. An external server controlled by the attacker drops messages into a queue, which avoids the constant connection that security tools might otherwise notice. An event source mapping triggers the Lambda function for each new message, and the function runs under its execution role.

Each Lambda execution lasts at most 15 minutes and leaves no lasting process, although it can still appear in cloud logs. Amazon SNS handles the outbound leg. The function publishes output to a topic, and SNS delivers that output to the attacker’s HTTPS endpoint after the subscription is confirmed. The Lambda function never connects directly to the attacker.

Amazon Bedrock acts as the language layer. A prompt such as “list all running EC2 instances with their IPs” is turned into the matching AWS API call. Normally, an operator would need exact CLI syntax, such as a long aws ec2 describe-instances command with filters and queries. In NotC2, the attacker uses a short prompt that begins with “ai:” and the model handles the rest.

The model works with a single generic tool named execute_aws_operation, which takes a service, an operation and its parameters. If an API call fails, the loop sends the error back to the model, and the model can adjust the request or suggest the next step. That makes reconnaissance look like a chat, with prompts such as “show me what I have access to.”

What the model can and cannot do

Bedrock does not create permissions. It only makes the access that already exists easier to use. Varonis showed the framework listing EC2 instances, DynamoDB tables, databases and Lambda functions. With enough permissions, an attacker could also delete S3 buckets or EC2 instances.

The permissions picture shapes both deployment and runtime. To set up the framework, the identity needs sqs:CreateQueue, lambda:CreateFunction, lambda:CreateEventSourceMapping and iam:PassRole for an existing Lambda role. If there is no suitable role, the attacker also needs IAM role and policy rights. At runtime, the Lambda role needs permission to read and delete queue messages, manage and publish to the SNS topic, subscribe the external endpoint and call bedrock:InvokeModel, along with access to the target services themselves.

Attacker tradecraft and log traces

The article places NotC2 in a broader pattern where attackers already use cloud and AI services for their own ends. It cites a recent LLMjacking case in which stolen cloud keys were used to run up large model bills. It also points to another report showing attackers targeting AI gateways linked to Amazon Bedrock. Open-source tooling such as Pacu, an AWS testing framework from Rhino Security Labs, can help attackers look for the needed permissions paths.

The network picture is sparse. There are no odd domains, unknown IPs or custom protocols in the usual sense. Instead, the evidence sits in the victim’s own cloud logs, including CloudTrail, Lambda logs, SNS delivery logs and Bedrock invocation logs. CloudTrail records management events by default, while data events require extra setup. It also hides SQS and SNS message content, and prompt-level Bedrock detail requires model invocation logging.

Defensive signals and limits

Defenders are told to watch for an SNS subscription created by a Lambda role that points to an outside HTTP or HTTPS address. Another signal is a sudden increase in Converse or InvokeModel calls from a role that never used Bedrock before. A third sign is a tight sequence of an SQS message, a Lambda run, Bedrock calls and an SNS publish to an outside subscriber.

Least privilege is the strongest control, and the guidance names the permissions that should be limited: queue and function creation, event source mappings, passing powerful roles to Lambda, Bedrock access and external SNS subscriptions. Blocking Lambda internet access can help, but it will not stop NotC2 on its own because SNS handles the outside delivery. Teams are also told to restrict SNS subscriptions to approved destinations.

NotC2 is framed as a sign that perimeter-focused security breaks down in serverless environments. There is no C2 server to block, so defenders have to focus on workload identities, service links and unusual behavior. The chain fails if any required step is blocked.