Varonis says NotC2 PoC hides C2 commands in AWS services

What happened

According to Cyber Security News, Varonis Threat Labs built NotC2, a proof-of-concept command-and-control (C2) framework that runs on native AWS services and uses Amazon Bedrock to turn plain English into cloud commands. Cyber Security News says this is service abuse, not a flaw in Bedrock, and that it only works after an attacker already holds AWS credentials. This advisory rests on that single outlet’s report; the Varonis publication itself was not available to us, and no AWS statement is included in the source.

Cyber Security News says the loop works like this:

• Amazon SQS is the command input.
• AWS Lambda is the engine, triggered by an event source mapping and running under the function’s execution role.
• Amazon SNS sends results to an attacker’s HTTPS endpoint once the subscription is confirmed.
• Amazon Bedrock interprets a short prompt starting with “ai:” and builds the matching AWS API call.

The article says Varonis demonstrated listing EC2 instances, DynamoDB tables, databases and Lambda functions. It also says the model cannot grant new permissions but makes existing access easier to use.

Not confirmed: the source does not report NotC2 being used in real attacks, and it names no victims or threat actors. It mentions other reported cases of stolen cloud keys and attacks on AI gateways linked to Bedrock, but these are separate from NotC2.

Am I affected?

Cyber Security News says the chain depends entirely on the permissions of stolen credentials. You are only in scope if an attacker could obtain AWS credentials with the relevant rights. The source lists these for deployment:

• sqs:CreateQueue
• lambda:CreateFunction
• lambda:CreateEventSourceMapping
• iam:PassRole for an existing Lambda role

It adds that 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, plus rights to the target services.

The source says network signals mostly disappear, with no odd domains, unknown IPs or custom protocols. The clues sit in CloudTrail, Lambda logs, SNS delivery logs and Bedrock invocation logs. It also says CloudTrail records management events by default, but data events need extra setup, and prompt-level Bedrock detail needs model invocation logging.

What to do now

1. Review which identities can create SQS queues and Lambda functions, set up event source mappings, pass powerful roles to Lambda, call Bedrock, and create external SNS subscriptions. Cyber Security News names least privilege as the strongest control.
2. Restrict SNS subscriptions to approved destinations, as the source recommends. Blocking Lambda internet access alone will not stop this design, because the source says SNS handles the outside delivery.
3. Check that the logs the source names are available: CloudTrail data events (extra setup), Lambda logs, SNS delivery logs, and Bedrock model invocation logging.
4. Watch for the three signs the source lists: 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; and a tight sequence of an SQS message, a Lambda run, Bedrock calls and an SNS publish to an outside subscriber.
5. Read the original Varonis Threat Labs research for technical detail. We did not have its URL, so details beyond the Cyber Security News summary are not confirmed.

Sources

• Cyber Security News: Researchers Uncover NotC2 AI-Powered C2 Framework That Hides Malicious Commands Inside AWS Services