NotC2 Framework Leverages AI and AWS Services for Stealthy Command and Control
Researchers have developed NotC2, a proof-of-concept C2 framework that uses AI and native AWS services to hide malicious commands within legitimate cloud operations, making detection significantly harder.
Varonis Threat Labs has unveiled NotC2, a novel proof-of-concept command-and-control (C2) framework that operates entirely within native Amazon Web Services (AWS) infrastructure. This innovative framework leverages Amazon Bedrock, an AI service, to translate natural language commands into executable AWS API calls, effectively masking malicious activity within legitimate cloud operations. Crucially, NotC2 represents a service abuse scenario rather than a vulnerability within Bedrock itself, and its deployment requires attackers to already possess compromised AWS credentials.
Traditional C2 frameworks often rely on custom servers and protocols that are readily identifiable and blockable by security tools. In response, threat actors have increasingly adopted legitimate platforms like messaging apps, cloud storage, and collaboration tools to host C2 infrastructure. This shift makes it difficult for organizations to block such domains without disrupting essential business functions. Cloud storage services, in particular, have become a common vector for exfiltrating data and relaying commands, with traffic often traversing standard ports like 443, rendering reputation-based blocking ineffective.
NotC2 builds upon previous research that explored hiding C2 traffic within AWS services. Earlier methods, such as XRayC2, hid commands in AWS X-Ray trace annotations, while others utilized services like Amazon S3 for command and data channels. However, these approaches often had limitations, including the need for specific API keys and potential delays due to constant polling. Varonis sought to create a more integrated solution where the entire C2 loop, including the human operator's role, could be executed within AWS.
The NotC2 framework orchestrates its operations across four core AWS services. Amazon Simple Queue Service (SQS) acts as the command input, allowing attackers to drop messages into a queue without establishing a direct, detectable connection. AWS Lambda serves as the execution engine, with functions triggered by new messages and operating within the permissions of an existing Lambda execution role. Amazon Simple Notification Service (SNS) is used to relay results back to the attacker's external HTTPS endpoint, ensuring the Lambda function never contacts the attacker directly. The intelligence behind translating user commands into AWS API calls is provided by Amazon Bedrock.
What sets NotC2 apart is its AI-powered command interpretation. Instead of requiring attackers to know precise AWS CLI syntax, they can issue commands in natural language, prefixed with "ai:". For instance, a prompt like "list all running EC2 instances with their IPs" is translated by Bedrock into the appropriate AWS API call. The framework also incorporates adaptive capabilities; if an API call fails, the error is fed back to the model, which can then attempt to correct the request or suggest alternative actions. This transforms reconnaissance into a conversational process, significantly lowering the barrier to entry for exploiting cloud environments.
The successful deployment and operation of NotC2 are contingent upon the permissions associated with the compromised AWS credentials. An attacker would need rights to create SQS queues, Lambda functions, event source mappings, and potentially IAM roles. At runtime, the Lambda execution role requires permissions to manage SQS messages, publish to SNS topics, subscribe the external endpoint, invoke Bedrock models, and access the target AWS services. Tools like Pacu can assist attackers in identifying these necessary permission paths.
Detecting NotC2 requires a shift in focus from traditional network-based indicators to analyzing cloud logs. Key indicators include an SNS subscription created by a Lambda role pointing to an external HTTP/S address, a sudden increase in Bedrock invocation calls from an unfamiliar role, or a tight sequence of SQS message processing, Lambda execution, Bedrock calls, and SNS publishing to an external subscriber. Implementing the principle of least privilege, restricting the creation of queues and functions, and carefully managing Lambda execution roles and SNS subscriptions are crucial defensive measures. While blocking Lambda internet access can help, it's insufficient alone due to SNS's role in external delivery. Ultimately, securing serverless environments necessitates a focus on workload identities, inter-service communication, and anomalous behavior patterns rather than solely relying on perimeter defenses.