Researchers Uncover NotC2 AI-Powered C2 Framework That Hides Malicious Commands Inside AWS Services

Varonis Threat Labs has built NotC2, a proof-of-concept command-and-control (C2) framework. It runs entirely on native AWS services and uses Amazon Bedrock to turn plain English into cloud commands.

It is service abuse, not a flaw in Bedrock, and it only works after an attacker already holds AWS credentials .

NotC2 AI-powered C2 framework

Classic C2 depends on custom servers and protocols that security tools can spot and block. Attackers have long moved away from that model by using trusted platforms such as Telegram, Discord, Slack, Pastebin, GitHub Gists and Google Sheets. Few companies can block these domains without hurting daily work.

Cloud storage follows the same idea. Amazon S3, Google Drive, OneDrive and Azure Blob Storage can all carry commands and stolen data. Cybersecurity News recently reported that attackers are hiding C2 traffic across AWS, Google Cloud, Cloudflare, Microsoft and GitHub.

Much of that traffic travels over port 443, so reputation-based blocking loses its value .

NotC2 did not appear from nothing. Researcher Dhiraj Mishra built XRayC2, which hides commands in AWS X-Ray trace annotations while infected hosts poll the same monitoring API the application already uses. We covered how hackers weaponize AWS X-Ray as a covert command channel in an earlier report .

Rhino Security Labs also showed Cobalt Strike beacons that use S3 objects as the channel. The beacon polls a bucket for task objects and writes results back as response objects. Rhino noted two weak spots in that design. The beacon needs API keys, and constant polling adds delay .

Each of these methods used one AWS service. Varonis asked what would happen if the whole C2 loop ran inside AWS, including the skill normally supplied by a human operator.

According to technical research published by Varonis Threat Labs, the name stands for “notification,” after the service that sends results back, plus “C2.” The loop uses four AWS services, and each one has a clear job.

Amazon SQS is the command input. The attacker’s external server drops messages into a queue, and there is no constant connection to spot. AWS Lambda is the engine.

An event source mapping runs the function for each new message, using the function’s execution role. Each run lasts at most 15 minutes and leaves no lasting process, though it can still appear in cloud logs.

Amazon SNS carries results out. The function publishes output to a topic, and SNS delivers it to the attacker’s HTTPS endpoint once the subscription is confirmed. The Lambda function never contacts the attacker directly.

Amazon Bedrock is the AI interpreter. It reads a request such as “list all running EC2 instances with their IPs” and builds the matching AWS API call .

Normally an operator must know the exact CLI syntax, such as a long aws ec2 describe-instances command with filters and queries. With NotC2, the attacker types a short prompt starting with “ai:” and the model does the rest.

A single generic tool, called execute_aws_operation, accepts a service, an operation and its parameters.

The model can also adapt. If an API call returns an error, the loop feeds it back, and the model can fix the request or suggest a next step. Reconnaissance turns into a chat, with questions like “show me what I have access to.”

The model cannot grant new permissions, but it makes existing access much easier to use. Varonis demonstrated listing EC2 instances, DynamoDB tables, databases and Lambda functions. With enough permissions, an attacker could also delete S3 buckets or EC2 instances.

The whole chain depends on the permissions of the stolen credentials. To deploy, an identity needs sqs:CreateQueue, lambda:CreateFunction, lambda:CreateEventSourceMapping and iam:PassRole for an existing Lambda role. If no suitable role exists, the attacker also needs IAM role and policy rights.

At runtime, the Lambda role needs rights to read and delete queue messages, manage and publish to the SNS topic, subscribe the external endpoint, and call bedrock:InvokeModel. It also needs rights to the target services themselves. Attackers often hunt for these paths with open-source tools such as Pacu, an AWS testing framework from Rhino Security Labs .

Real attackers are already moving this way. A recent LLMjacking case showed stolen cloud keys being used to run up huge model bills . Another report showed attackers targeting AI gateways linked to Amazon Bedrock .

The network signals mostly disappear. There are no odd domains, unknown IPs or custom protocols. The clues sit in the victim’s own cloud logs, including CloudTrail, Lambda logs, SNS delivery logs and Bedrock invocation logs.

CloudTrail records management events by default, but data events need extra setup. CloudTrail also hides SQS and SNS message content, and prompt-level Bedrock detail needs model invocation logging.

Defenders should watch for three signs:

• An SNS subscription created by a Lambda role that points to an outside HTTP or HTTPS address.
• A sudden rise in Converse or InvokeModel calls from a role that never used Bedrock.
• 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. Limit who can create queues and functions, set up event source mappings, pass powerful roles to Lambda, call Bedrock and create external SNS subscriptions. Blocking Lambda internet access helps, but it will not stop NotC2 alone, because SNS handles the outside delivery.

Teams should also restrict SNS subscriptions to approved destinations.

NotC2 shows that perimeter-focused security breaks down in serverless setups. With no C2 server to block, defenders must focus on workload identities, service links and unusual behavior. Block any one required step, and the chain fails.

The post Researchers Uncover NotC2 AI-Powered C2 Framework That Hides Malicious Commands Inside AWS Services appeared first on Cyber Security News.