NotC2 AWS Bedrock C2: Researchers Turn Stolen Cloud Credentials Into a Hidden AI Control Channel, and What to Check This Week

Security researchers at Varonis have built NotC2, a proof-of-concept tool showing that an attacker who already holds stolen AWS credentials can run a hidden control channel using only AWS's own services, with Amazon Bedrock's AI turning plain-English requests into cloud commands. It matters because the activity looks like normal AWS use, so the defenses that count are your cloud permissions and logs, not your firewall.

There is no patch to install: this is misuse of legitimate services, not a reported flaw in AWS. What you can do is make stolen credentials less useful and make this pattern visible.

What is NotC2 and how does the AWS Bedrock C2 channel work?

C2 stands for command and control: the link an intruder uses to send instructions into a breached system and get results back. Varonis describes NotC2 in a write-up titled "NotC2: How We Built an AI-Powered C2 Channel With AWS Services", by researcher Or Soria. News coverage and search listings date it November 6, 2026; the copy of the page we read showed no date.

The design spreads the job across four managed services:

Varonis writes: "Most of NotC2's command loop runs over encrypted HTTPS to trusted AWS endpoints, and every API call is signed with valid credentials." The AI adds convenience: the operator asks for what they want in plain language instead of writing AWS commands.

Is NotC2 a vulnerability? What is confirmed and what is not

Confirmed in the Varonis write-up:

• NotC2 is a research proof of concept that "assumes the attacker already holds AWS credentials."
• The AI works inside the stolen identity's permissions, "without granting permissions the attacker does not already possess."
• Varonis says it "lowers the expertise required to use compromised cloud access."
• Setting it up takes real rights, including sqs:CreateQueue, lambda:CreateFunction, lambda:CreateEventSourceMapping and iam:PassRole. Varonis notes stolen credentials might not have these at first, which may require privilege escalation.

Not stated or not known:

• The write-up reports no use of NotC2 in real attacks. Varonis does point to earlier research, such as Rhino Security Labs' demonstration of Cobalt Strike communications through S3, so the general idea is not new.
• It links to no public NotC2 code and includes no response from AWS.
• It does not name the Bedrock model used.
• We found no published test showing whether Amazon GuardDuty or other tools flag NotC2 specifically.

Why NotC2 matters for a business running on AWS

The starting point is a stolen credential, and that is the part a business controls. An access key left in a code repository, on a developer laptop or with a vendor could be the way in. If that identity has wide permissions, an intruder can use your own cloud account as their infrastructure and reach whatever those permissions allow, including the data behind your website or app.

Network controls will not carry this alone. Results leave through SNS, so the Lambda function never connects to the attacker's server directly, and Varonis says egress controls "do not stop NotC2 by themselves because SNS performs the external delivery." It calls strict permissions "the highest-leverage control." Strong sign-in matters too, and not every second factor holds up equally.

How to check your AWS account for NotC2-style abuse this week

Know the limits of your logs. AWS logs SNS Subscribe and Bedrock's InvokeModel and Converse as management events, which CloudTrail records by default. SNS Publish is a data event that you must turn on, at extra cost. Message content stays hidden in CloudTrail either way, and prompts appear only in Bedrock's invocation logs.

The strongest signal Varonis describes is the chain: an SQS message from an unexpected source, then a Lambda run, Bedrock activity, other API calls and an SNS publish to an outside subscriber, all within a short window.

If something looks wrong, follow the steps in AWS's GuardDuty guidance: identify the identity and API call, review its permissions, and ask its owner whether the activity was intended. If you cannot confirm that it was, treat the credentials as compromised.

NotC2 questions people are asking

What is NotC2?

A proof-of-concept command and control framework from Varonis, built on Amazon SQS, Lambda, SNS and Bedrock, for use after an attacker already holds AWS credentials.

Is NotC2 being used in real attacks?

The Varonis write-up reports no real-world use. That does not rule out similar techniques being tried.

Does NotC2 exploit a flaw in Amazon Bedrock?

The write-up identifies no flaw in AWS. It abuses legitimate services using valid credentials, so there is no fix to install.

Can a firewall block NotC2?

Not on its own. Most of the traffic goes to trusted AWS endpoints, and SNS makes the outside delivery.

What if we do not use Bedrock at all?

Then any Bedrock call from one of your roles deserves a look. Varonis says NotC2 only works when the attacker can invoke Bedrock, so remove that permission where it is not needed, or block it across accounts with a service control policy.

Is Bedrock model invocation logging on by default?

No. AWS says it is disabled by default, and you must set up an S3 or CloudWatch Logs destination first.

The bigger lesson

NotC2 does not make stolen credentials more powerful. It makes them easier to use and harder to spot, because every step looks like a service doing its job. That puts the weight on three plain habits: give each identity only what it needs, keep the logs that prove what happened, and know what normal looks like in your account.

See how we approach this through security hardening, or get a quote for a review of your cloud setup.

Get security alerts by email, with the free checklist, at our security alerts page.

Sources: Varonis: NotC2; AWS: Bedrock model invocation logging; AWS: Bedrock API calls in CloudTrail; AWS: SNS API calls in CloudTrail; AWS: CloudTrail event history; AWS: GuardDuty IAM finding types; AWS: Remediating compromised credentials; AWS: IAM security best practices.