AWS Cloud Security Monitoring With Deception
Getting a Foothold in AWS
Adversaries target enterprises running AWS cloud applications in multiple ways to gain a foothold into their cloud environment. This article covers a few of the methods used by attackers and how to deploy deception around AWS assets to protect the infrastructure against intruders.
Enterprises have multiple access levels into their cloud environments to deploy and manage cloud infrastructure. Below are some examples in which enterprises provide various access levels and how attackers can target these to gain a foothold.
Web Tier — attackers can conduct exploitation on ports 80 and 443 against vulnerable applications to gain a foothold into the AWS infrastructure.
Engineering/DevOps — users have access to AWS access keys, PEM keys, AWS console access, etc. to develop, deploy, and manage the system. Attackers who compromise user endpoint systems can steal credentials and access the enterprise AWS infrastructure.
Authorized 3rd party — users have selective access to AWS resources like S3 buckets, databases, etc. Any breach in a 3rd party vendor infrastructure can result in a compromise of confidential information.
Stealing AWS Access Keys
AWS access keys consist of two pairs (a Key Id and a Key Secret) used programmatically to make requests to AWS through the CLI, SDK, or API. Attackers target vulnerable applications and misconfigurations or steal access keys from compromised endpoint systems, source code repositories, etc., to gain access to the AWS infrastructure.
This section documents a few of the methods attackers use to steal AWS access keys.
Stealing access keys exploiting vulnerable AWS applications
AWS allows users to query instance metadata information using IP address 169.254.169.254. Once attackers exploit vulnerable web applications or misconfigurations, they can drop web-shells and query EC2 instance meta-data to retrieve IAM access keys.
The following URL request retrieves security credentials for the IAM role “s3 access”.
Attackers can exploit permissions assigned to the AWS resource to access other AWS resources. In the above example, if the EC2 instance is assigned a policy to access S3 buckets, attackers can query and read data from the AWS S3 buckets.
Stealing access keys from engineering/DevOps systems
Engineering/DevOps systems have access to AWS keys to deploy and manage the AWS infrastructure.
The AWS CLI, by default, uses access keys from the following file locations
Scripts and applications can also read AWS access keys from environmental variables.
Attackers on compromised endpoints can find and steal AWS access keys from various locations. Once attackers retrieve the access keys, they can access AWS cloud from outside the network as well, unless they have strict firewall rules to restrict access to AWS services.
Stealing access keys from GitHub repositories
There are multiple instances of developers accidentally checking in AWS access keys to GitHub repositories. Attackers on a compromised endpoint with access to git repositories can steal these AWS access keys from the git repos.
Breach in 3rd Party Vendors Networks
Many enterprises provide access to a subset of AWS resources for 3rd party vendors, partners, consultants, etc. to access data and supply services.
Any breach in a 3rd party vendor’s infrastructure can impact a customer’s AWS infrastructure and lead to leakage of sensitive information.
Lateral Movement and Data Exfiltration in AWS
Once attackers gain access to the cloud infrastructure, they can perform various actions to escalate privileges and exfiltrate data. This section describes a few of the attack methods and possible ways to deploy deception to protect cloud infrastructure.
EC2 Instances and Privilege Escalation
The AWS EC2 (Elastic Compute Cloud) service offers virtual servers running applications in the AWS cloud and has a larger attack surface compared to other AWS services. Apart from application-level exploitation, attackers can escalate privileges in AWS by exploiting IAM roles and permissions assigned to various resources.
The following table shows a few of the exploitation methods possible in AWS.
To defend against these methods, users can deploy decoy EC2 instances running production applications in their AWS environment. They can then distribute breadcrumbs pointing to the decoy applications on production EC2 instances to lead attackers to the decoys.
Attacks Targeting S3 buckets
AWS S3 is an object storage service that customers use to store and protect data such as static websites, documents, backup files, etc.
S3 buckets continue to be one of the prime targets for attackers due to:
- Misconfigurations around S3 buckets
- Too many access methods. Multiple AWS Services and APIs can access S3 buckets
- Access to 3rd party vendors
- Over-provisioning of S3 access permissions
Assigning granular cloud access policies across various AWS users, groups, roles, services, and 3rd party vendors are complex and challenging
Attackers can exploit over-provisioned resource permissions assigned to S3 buckets and sync data to exfiltrate customer S3 buckets to their own, bypassing traditional security solutions.
Customers can deploy deception around S3 buckets to detect intruders bypassing existing preventive mechanism and exfiltrating data from them
Customers need to monitor CloudWatch logs to detect for any activity on decoy S3 buckets and implement alerting mechanism. The monitoring solution should also support whitelisting, so administrators or valid users accessing these buckets will not trigger events.
Attacks Targeting AWS Hosted Storage
AWS offers multiple hosted data storage services. Once inside the AWS environment, attackers try to escalate privileges and steal keys to gain access to cloud data storage
DynamoDB is one of the popular AWS managed database services. Users can access DynamoDB in multiple ways
- IAM Users: Accounts with permissions to access the DynamoDB database.
- Access Keys: Assigned to IAM users programmatically.
- IAM Role: Assigned to various AWS services to interact with DynamoDB
- IAM roles assigned to EC2 instances to access DynamoDB
- IAM roles assigned to Lambda functions to access DynamoDB
Intruders gaining access to any of the IAM users’ credentials, access keys, or IAM role permissions can access the AWS DynamoDB tables.
Customers can deploy decoy DynamoDB tables and monitor for intruders accessing decoy content. The solution. The monitoring solution should also support whitelisting, so administrators or valid users accessing or listing decoy tables does not not trigger false alarms.
Attacks Targeting Lambda Functions
Lambda is the AWS event-driven serverless computing function and is growing in popularity due to its ability to run code without the need to provision and manage servers as well as its ability to scale as needed
There are many possible threats to Lambda computing. Lambda functions can have multiple trigger points, and attackers having access to these triggers can invoke the Lambda functions to retrieve data directly from backend AWS services.
Below is an example of an attacker invoking backend a Lambda function, bypassing the standard workflow:
The Attivo Networks ThreatDefend platform can deploy decoy Lambda functions and can detect attackers targeting backend Lambda functions to bypass the regular workflow
Attacks Targeting Web Apps
Enterprises deploy many intranet web applications in their networks. Attackers on a compromised endpoint can steal credentials, cookies, or other stored access tokens from browser caches and target internal web applications.
For example, a solution such as the Attivo Networks ThreatDefend platform can deploy decoy web applications hosted in S3 buckets or Lambda functions with decoy dynamoDB tables.
Additionally, the Attivo Networks ThreatDefend integrates with endpoint management systems to distribute deceptive breadcrumbs (browser credentials, cookies, browser history, etc.) to production systems. Attackers performing reconnaissance and targeting enterprise web apps are now efficiently redirected away from the production environment and into the decoy infrastructure. Multi-cloud and on-premises environments can all be managed from a single management console.
Summary
Enterprises have AWS accounts ranging from a single account to a few dozen accounts with varying degrees of access controls. Cyber deception solutions such as the Attivo Networks ThreatDefend platform will significantly reducing the risk for these environments by deploying a layer of deception across a customer’s AWS cloud. Deception deploys as part of internal security monitoring to detect attackers performing reconnaissance or targeting the AWS infrastructure using stolen credentials and misconfigurations, playing a critical role in an organization’s cloud security risk reduction strategy.
