Varonis Threat Labs published NotC2, a proof-of-concept that runs post-compromise command and control inside a victim’s AWS account and uses Amazon Bedrock to turn short English prompts into cloud API calls. The Varonis write-up states plainly that this is service abuse, not a flaw in Bedrock, and that it only works after an attacker already holds AWS credentials. If you run coding agents on machines that touch cloud keys, the lesson is about what those credentials enable once they leave your repo—not about blocking a new CVE.
| Question | Short answer |
|---|---|
| Am I affected? | Only if long-lived AWS keys or overprivileged roles exist in accounts an attacker can reach after initial access |
| Is there a fix? | No product patch. Tighten IAM, restrict SNS subscriptions to approved destinations, and alert on new Bedrock use from Lambda roles |
| Does data leave my machine? | NotC2 exfiltrates through SNS to an attacker HTTPS endpoint inside the victim account; local agents are indirect risk via leaked keys |
| Is Bedrock broken? | No. The model stays within the stolen role’s permissions and lowers operator skill, per Varonis |
What Varonis published
Varonis named the framework NotC2—“notification” plus C2—because Amazon SNS carries results back to the operator. The research is a deliberate joke in the title: it looks like legitimate AWS plumbing while acting as command and control. Varonis positions it as the next step after single-service abuses such as XRayC2 (commands hidden in X-Ray trace annotations) and Rhino Security Labs’ demonstration of Cobalt Strike beacons that poll S3 objects for tasks.
The lab’s goal was to ask whether the entire loop—command delivery, execution, AI interpretation and result return—could run on native AWS services, including the expertise that a human operator normally supplies. Varonis demonstrated listing EC2 instances, DynamoDB tables, databases and Lambda functions with natural-language requests, and notes that destructive actions such as deleting S3 buckets or instances are possible when the execution role allows them.
explainx.ai has broader coverage of agentic cloud intrusions, including financial-sector cases where stolen keys move fast. Beam’s post here stays on Varonis’s mechanism and defensive signals.
Attack chain step by step
Varonis’s architecture uses four AWS services in a fixed loop:
- Amazon SQS receives commands from the attacker’s external server. There is no persistent C2 socket; an event source mapping triggers Lambda when a message arrives.
- AWS Lambda runs the handler for up to 15 minutes per message, using its execution role’s permissions. No long-lived implant process remains, but CloudWatch and CloudTrail can still record the activity.
- Amazon Bedrock interprets commands prefixed with natural-language prompts (for example,
ai: list all running EC2 instances with their IPs). A single generic tool,execute_aws_operation, accepts service, operation and parameters; the model can chain calls and adapt when APIs return errors. - Amazon SNS publishes results to a topic and delivers them to the attacker’s confirmed HTTPS subscription. The Lambda function never connects directly to attacker infrastructure.
Image: Varonis Threat Labs
Varonis contrasts the syntax burden: where an operator might run a long aws ec2 describe-instances command with filters and JMESPath queries, NotC2 accepts conversational reconnaissance such as “show me what I have access to.” The model cannot grant new permissions; it makes existing access easier to exercise.
Deployment versus runtime permissions
Varonis splits requirements into two phases. Deployment needs sqs:CreateQueue, lambda:CreateFunction, lambda:CreateEventSourceMapping and iam:PassRole when reusing a Lambda role—or additional IAM rights to create or modify that role. Runtime needs queue read/delete, SNS topic management, sns:Subscribe to the external endpoint, sns:Publish, bedrock:InvokeModel, plus whatever service APIs the attacker targets.
The post notes that attackers often hunt overprivileged Lambda roles with open-source enumeration frameworks such as Pacu. A role that can create queues, functions, Bedrock calls and external SNS subscriptions is, in Varonis’s words, “functionally, a backdoor with an AI assistant.”
Why network defenses miss it
Most traffic stays on encrypted HTTPS to trusted AWS endpoints signed with valid credentials. Results leave through SNS, so the Lambda function does not beacon to an unknown IP. Varonis argues that the usual indicators—suspicious domains, custom protocols, jittered beaconing—largely disappear.
The signal moves into the victim’s own logs: CloudTrail management events (on by default), optional data events, Lambda logs, SNS delivery logs and Bedrock invocation logs. Varonis stresses that seeing a queue or a model call is not the same as seeing message content: CloudTrail redacts SQS and SNS bodies, and prompt-level Bedrock detail requires model invocation logging.
Detection opportunities Varonis lists
Varonis gives three practical hunts:
- Anomalous SNS subscriptions: a Lambda execution role creating an HTTPS subscription to an external endpoint the organization does not normally use.
- Unusual Bedrock activity: a sudden rise in Converse or InvokeModel calls from a Lambda role that had not previously used Bedrock, especially alongside new access patterns to unrelated services.
- Correlated sequences: with the right logs enabled, chaining SQS receive, Lambda invoke, Bedrock calls, downstream API calls and SNS publish to an external subscriber within a short window—none of which is malicious alone.
Defensive countermeasures in the post mirror the dependencies: strict IAM least privilege, limiting who can pass powerful roles to Lambda, pairing Lambda egress controls with SNS subscription policy (because SNS, not Lambda, delivers results externally), and enabling the logging that exposes content when investigations require it.
What this means if you run AI coding agents
NotC2 does not run on your laptop. It runs in a compromised AWS account. The overlap with coding agents is credential surface, not Bedrock inside Claude Code.
Google and Mandiant’s LLMjacking reporting already describes stolen cloud and model keys resold through proxy gateways, with six-figure daily charges. Varonis’s PoC shows a different end state for the same class of secret: conversational cloud takeover without a human operator who knows every CLI flag.
The Wiz cloud attack anatomy post walks a similar story from the defender’s side: once an identity can call model and infrastructure APIs, automation accelerates discovery. NotC2 is narrower—it is a published PoC, not a named intrusion tool—but it encodes the same assumption that cloud API access is the bottleneck, not shell access on a laptop.
Prior techniques NotC2 extends
Varonis does not claim every piece is novel. XRayC2 hid tasking inside X-Ray trace annotations while hosts polled an API the application already used. Rhino’s S3 beaconing stored commands and results as objects in a bucket the beacon could reach with stolen keys, but Rhino noted polling delay and the need for keys on the implant side. Single-service designs still left the operator translating intent into precise CLI or SDK calls.
NotC2’s contribution is composition: queue-triggered serverless execution, model-mediated API selection, and SNS fan-out for results, all inside the victim tenant. That composition is what changes detection: blue teams must reason about service graphs, not just outbound IPs. For red-team readers who install audit skills locally, the lesson is different—your sandboxed agent is not deploying NotC2—but the cloud accounts those agents touch still need the IAM boundaries this research stresses.
Logging gaps Varonis calls out explicitly
Varonis’s table in the primary post distinguishes what default telemetry shows versus what investigators need for content. Management events in CloudTrail explain who created the queue, function, topic and subscription. Data events are higher volume and must be turned on deliberately if you want object-level reads and writes that some recon steps might trigger.
For the messaging layer, CloudTrail records API calls around SQS and SNS but redacts message bodies, so “someone sent a command” may be visible while the command text is not. For Bedrock, model invocation logging is separate from the standard CloudTrail event stream; without it, you may see that InvokeModel ran but not the prompt that drove a destructive chain.
Operational teams often enable management trails everywhere and defer data events and Bedrock logging to “later.” NotC2 is a concise argument for moving “later” forward on accounts where agents, CI systems or humans store powerful static keys.
Concrete checks for developers and platform teams:
- Inventory where agents can read AWS keys:
.envfiles,~/.aws/credentials, CI variables, and Northflank-style control-plane leaks that publish keys into logs agents scrape. - Prefer short-lived credentials on runners and local dev: role assumption with session tokens beats static keys in a repo an agent can
cat. - Scope Bedrock and SNS: roles used by application Lambdas should not accumulate
bedrock:InvokeModelorsns:Subscribeto arbitrary URLs unless that is an explicit product requirement. - Alert on probing patterns LLMjacking campaigns use (
max_tokens=1validation), and on new Bedrock enablement in accounts that did not previously call models, as Varonis recommends.
If your team experiments with agentic pentest tooling, treat NotC2 as adjacent research to in-the-wild ARTEX-style frameworks: automation compresses timelines, but the entry condition is still stolen identity material.
A short checklist after you read the Varonis post
Work through these in order if you maintain AWS accounts tied to engineering laptops or agent runners:
- List principals that can create Lambda event source mappings and pass roles with
bedrock:InvokeModel. Remove Bedrock from roles that only serve web traffic unless product requirements demand it. - Review SNS subscription policies for HTTPS endpoints outside your domain allowlist; Varonis treats unexpected subscriptions as high signal.
- Turn on Bedrock model invocation logging to an encrypted bucket with object lock or equivalent retention if your IR team needs prompt evidence.
- Replace static keys in repos and agent-readable dotfiles with OIDC or short-lived role assumption on CI and local dev.
- Run a Pacu module pass (or equivalent read-only assessment) on staging accounts to see whether an overprivileged Lambda role already exists for reuse—Varonis assumes attackers search for exactly that shortcut.
None of these steps live inside a coding agent installer. They are account hygiene that reduces what any stolen key—including one an agent echoed into a log—can assemble.
What Beam can and cannot do here
Beam watches local coding agents (Claude Code, Codex and similar) for risky commands, scans skills and MCP configs before you run them, and redacts known secret shapes before events are stored on-device. It can flag when an agent reads ~/.aws/credentials, dumps environment variables, or curls a metadata service—patterns that often precede cloud key theft.
Beam does not monitor CloudTrail, Lambda or Bedrock inside your AWS organization. It is not a cloud SIEM and cannot block SNS subscriptions in AWS. For cloud-side hunts, use the logging and IAM controls Varonis describes; use Beam on the workstation where agents touch the secrets that make NotC2 possible.
Related reading
- ARTEX and Friends: What Google and Mandiant Saw Agentic Attack Frameworks Do
- LLMjacking at Scale: Google and Mandiant on Stolen LLM Access
- Northflank Security Incident: Control-Plane Secrets and AI Key Abuse
- Wiz on the anatomy of AI-driven cloud attacks
- Varonis NotC2 primary research post
- Rhino Security Labs Pacu AWS exploitation framework
Frequently asked questions
Is NotC2 a vulnerability in Amazon Bedrock?
No. Varonis describes it as service abuse after the attacker already holds AWS credentials. Bedrock translates natural-language commands into API calls within the permissions of the compromised role.
Has NotC2 been seen in real attacks?
Varonis published it as its own proof of concept. The write-up does not claim in-the-wild use of NotC2 itself, but it cites related cloud C2 research and ongoing LLMjacking cases.
What AWS permissions does deployment need?
The deploying identity needs sqs:CreateQueue, lambda:CreateFunction, lambda:CreateEventSourceMapping and iam:PassRole for an execution role, plus IAM rights if it must create the role. Runtime needs SQS, SNS, bedrock:InvokeModel and permissions on target services.
What should defenders monitor?
Varonis highlights external SNS subscriptions created by Lambda roles, sudden Bedrock Converse or InvokeModel use from roles that never called models before, and correlated sequences of SQS, Lambda, Bedrock and SNS publish events.
Does this patch like a CVE?
There is no vendor patch. Controls are IAM least privilege, restricting external SNS subscriptions, enabling the CloudTrail data events and Bedrock model invocation logging needed to see content, and reviewing Pacu-style enumeration paths.
Why does this matter on a laptop running Claude Code or Codex?
Coding agents read repo and shell secrets, including long-lived cloud keys. Those same keys are what LLMjacking and frameworks like ARTEX chase once they reach a host or CI runner.
Technical details reflect Varonis’s November 2026 publication. AWS service names and permission strings are quoted from that post; your account’s effective policies may differ.