Hari 
Command-and-control frameworks traditionally depend on attacker-owned servers, custom protocols, and network indicators that defenders can identify and block.
Varonis Threat Labs’ NotC2 proof of concept demonstrates a different model: a C2 loop assembled entirely from native AWS services, with Amazon Bedrock translating natural-language instructions into AWS API actions.
The result blends post-compromise activity into ordinary cloud operations and shifts the defensive burden from network blocking to identity, permissions, and service-relationship monitoring.
NotC2: How Attackers Build AI-Powered C2 Channels
Attackers have long abused legitimate communication platforms to move commands and stolen data. Telegram and Discord bots can deliver instructions, Slack webhooks can disguise exfiltrated data as notifications, and Pastebin, GitHub Gists, and Google Sheets can function as dead drops.
Cloud storage services such as Amazon S3, Google Drive, OneDrive, and Azure Blob Storage extend the same concept because organizations often cannot block services central to daily work.
AWS itself has been used in earlier C2 experiments. XRayC2 embeds commands in X-Ray trace annotations, while Rhino Security Labs demonstrated a Cobalt Strike beacon that used S3 objects as its communication channel, polling for task objects and returning results through response objects.
In both cases, traffic travels over encrypted HTTPS to trusted AWS endpoints and uses valid AWS credentials, making it resemble ordinary cloud traffic rather than a connection to an unknown C2 server.
NotC2 goes further by placing the entire loop inside the victim’s AWS account: command delivery, execution, AI interpretation, and result return. Its name combines “notification” and “C2,” a deliberate joke because the framework is very much a C2 system even though it does not look like one on the network.
NotC2 uses four AWS services in sequence. Amazon SQS serves as the command input channel: the attacker’s external server sends commands to a queue, and Lambda’s native event-source integration invokes the function automatically when a message arrives. Because SQS is asynchronous and decoupled, there is no persistent connection for defenders to spot.
AWS Lambda is the execution engine. Each invocation processes a queued command and performs AWS operations under the function’s execution role, limited to the permissions attached to that role. Lambda functions have a maximum runtime of 15 minutes and leave no persistent process, although their activity can still appear in cloud logs.
Amazon SNS returns results to the attacker. The Lambda function publishes command output to an SNS topic, which delivers it to an attacker-controlled external endpoint after the HTTPS subscription is confirmed. This removes the need for the attacker to poll directly, while SNS retries failed deliveries according to its configured delivery policy.
Amazon Bedrock acts as the AI command interpreter. A generic tool specification called execute_aws_operation accepts a service, operation, and parameters, giving the model a consistent interface for supported AWS services.
The model receives a natural-language prompt, determines the relevant AWS service and operation, invokes the tool with the correct parameters, receives the result, and formats a human-readable response.
Traditional C2 requires an operator who understands the target environment and can construct precise command syntax. NotC2 reduces that requirement. Instead of issuing a detailed AWS CLI command to enumerate running EC2 instances and their private IP addresses, an attacker can type, “ai: list all running EC2 instances with their IPs.”
The model can also chain operations. When the orchestration loop returns API results or errors, Bedrock can revise the request or propose a follow-up action. This makes reconnaissance conversational: an operator can ask what resources it can access, list database resources, or identify Lambda functions, and let the model propose the necessary API calls.
Importantly, Bedrock does not grant permissions the attacker does not already possess. It lowers the expertise needed to use compromised cloud access, but the Lambda execution role remains the boundary of what the framework can do. A role with broad permissions across SQS, SNS, Bedrock, and target resources effectively becomes an AI-assisted backdoor.
NotC2’s feasibility depends on the permissions of the compromised credentials. During deployment, an attacker needs to create and configure the infrastructure.
In the simplest path, where a suitable Lambda execution role already exists, the deploying identity needs sqs:CreateQueue, lambda:CreateFunction, lambda:CreateEventSourceMapping, and iam:PassRole for that role. If the attacker must create or modify the role, additional IAM role and policy-management permissions are required.
At runtime, the Lambda execution role needs permissions to receive and delete SQS messages, inspect queue attributes, create or validate SNS topics, subscribe to external endpoints, publish results, and invoke Bedrock models. It also needs permissions for whatever target resources the attacker intends to access, such as s3:ListAllMyBuckets for enumerating S3 buckets.
Attackers often seek existing roles rather than creating new ones. Enumeration tools such as Pacu are designed to discover these paths, although enumeration itself generally requires List permissions. Pacu is an open-source AWS exploitation framework that includes modules for privilege escalation, IAM backdooring, Lambda attacks, enumeration, and data exfiltration.
Because NotC2 runs over encrypted HTTPS to trusted AWS endpoints and uses valid credentials, conventional network indicators largely disappear.
There are no suspicious domains, unknown IP addresses, custom protocols, or direct Lambda-to-attacker connections. SNS performs the external delivery, so the Lambda function never connects directly to the attacker’s server.
The signal instead moves into the victim’s cloud logs. CloudTrail management events reveal how the queue, function, topic, and model invocation infrastructure were created and configured, and these events are recorded by default. Data events that expose the actual message flow are higher-volume and require explicit configuration.
CloudTrail redacts SQS and SNS message content, while prompt-level Bedrock visibility comes from model invocation logging rather than standard CloudTrail events.
Mitigation
Several detection signals emerge despite the use of legitimate services. An SNS subscription created by a Lambda execution role and pointing to an external HTTP or HTTPS endpoint deserves investigation, especially when the destination is unfamiliar. Legitimate Lambda workflows rarely create new external subscriptions at runtime.
Unusual Bedrock activity is another warning sign. A sudden increase in Converse or InvokeModel calls under a Lambda execution role may be suspicious, particularly if the function or role has not previously used Bedrock. The signal becomes stronger when the same role begins accessing unrelated AWS services.
The strongest detection comes from correlation. With the relevant logs enabled, defenders can connect an SQS message from an unexpected source, a Lambda execution, Bedrock activity, downstream AWS API calls, and an SNS publish to an external subscriber within a short period. Individually, none of these events proves malicious intent; together, they reveal the C2 loop.
Strict IAM least privilege is the highest-leverage control. Organizations should prevent identities and Lambda execution roles from accumulating permissions they do not need, especially permissions to create queues and functions, configure event source mappings, pass powerful roles to Lambda, invoke Bedrock, and create external SNS subscriptions.
If a compromised identity cannot assemble the infrastructure, or if the execution role cannot reach unrelated resources, the NotC2 chain fails.
Restricting external communication also matters. Limiting unrestricted internet access from Lambda functions reduces opportunities for payload delivery and direct exfiltration, but it does not stop NotC2 alone because SNS performs the external delivery.
Organizations should pair Lambda network restrictions with SNS controls that limit who can create or modify external subscriptions, allow only approved destinations, and restrict functions to publishing through intended topics.
NotC2 shows where perimeter-focused security breaks down in serverless environments. When command delivery, execution, AI interpretation, and result handling all run through native services inside the victim’s AWS account, there is no conventional C2 server to block.
Amazon Bedrock lowers the skill required to operate the framework, turning natural-language commands into AWS API operations and accelerating cloud reconnaissance. The model operates within the identity’s assigned permissions, helping attackers understand and exploit whatever access those permissions allow.
The framework only works when an attacker can create or reuse the required infrastructure, attach a powerful execution role, invoke Bedrock, reach target resources, and establish a results channel. Blocking any one of those steps breaks the chain.
Defenders must therefore focus on workload identities, service relationships, and deviations from expected behavior rather than relying on network-level blocking alone.
Site: Thecyberdef.com
Follow TheCyberDef on Google News, LinkedIn & X for the latest cybersecurity updates. Stay informed.
About the Author
Kiran 
