Malicious Commands Inside AWS

Overview

Researchers at Varonis Threat Labs have developed NotC2, a proof-of-concept command-and-control (C2) framework that demonstrates how attackers could abuse legitimate AWS services to hide malicious activity. The framework uses Amazon SQS, Lambda, SNS and Amazon Bedrock to create a C2 channel without requiring a traditional attacker-controlled server or custom network protocol. Importantly, this is not a vulnerability in Amazon Bedrock; the technique relies on abusing legitimate AWS functionality after an attacker has already obtained AWS credentials with sufficient permissions.

How NotC2 Works

NotC2 uses SQS as the command channel, triggering an AWS Lambda function whenever a new message arrives. Lambda uses its execution role to process the request, while Amazon Bedrock interprets plain-English instructions and converts them into AWS API operations. The results are then published through SNS, which delivers them to an external HTTPS endpoint. This creates a complete C2 workflow inside trusted AWS infrastructure, meaning there may be no obvious malicious IP address, custom protocol or suspicious external connection from the compromised workload.

Why It Matters

The important shift is that attackers no longer need to communicate directly with their infrastructure. Instead, they can potentially use the victim’s own cloud services as the communication mechanism. A compromised identity could issue commands such as discovering EC2 instances, DynamoDB tables or Lambda functions, while Bedrock translates the request into the required API calls. The AI component does not bypass IAM permissions, but it makes existing permissions significantly easier for an attacker to use and adapt when API requests return errors.

Security Considerations

Traditional network security controls are less effective against this type of architecture because much of the activity occurs through legitimate AWS services over normal HTTPS connections. Defenders should therefore monitor CloudTrail, Lambda activity, SNS subscriptions, SQS activity and Bedrock invocation logs for unusual behaviour. Particular attention should be given to Lambda functions creating external SNS subscriptions, IAM roles suddenly invoking Bedrock, unexpected queue-to-Lambda-to-Bedrock-to-SNS activity and cloud identities performing operations outside their normal behaviour.

Security Best Practices

The strongest defence is least privilege across AWS identities and services. Restrict which identities can create Lambda functions and SQS queues, configure event-source mappings, pass IAM roles to Lambda, invoke Bedrock and create external SNS subscriptions. Where possible, restrict SNS subscriptions to approved destinations and closely monitor service-to-service permissions. Logging must also be configured correctly because CloudTrail does not automatically provide every type of data-level visibility, making additional logging important when investigating cloud-based C2 activity.

Expert in the Cloud Insight

NotC2 demonstrates an important change in cloud security: the attack surface is no longer limited to servers and network connections — it includes the relationships between cloud services and identities. A security architecture that focuses only on blocking malicious IP addresses or domains can miss an attack operating almost entirely inside the organisation’s own AWS environment. As AI services become integrated into cloud infrastructure, organisations should treat IAM permissions, service-to-service relationships and behavioural monitoring as critical security controls. The best defence is to ensure that even if an attacker obtains one cloud credential, it cannot be chained into a powerful sequence of trusted services.

Expert in the Cloud – The Future Is Now.

Be the first to comment

Leave a Reply

Your email address will not be published.


*


This site uses Akismet to reduce spam. Learn how your comment data is processed.