SBN

Detecting Attacks on Amazon Web Services (AWS)

Amazon Web Services (AWS) is well known for its shared responsibility model: AWS is responsible for fixing the flaws in the infrastructure and its customers are responsible for configuring and adequately protecting their own data using access management or other security controls. If an organization does not follow the least privilege principle in AWS or makes a simple misconfiguration, it could lead to a compromise very quickly. AWS offers a variety of resources such as Amazon Elastic Compute Cloud (EC2), Lambda, Amazon Simple Storage Service (S3), API Gateway, and many more. In this blog, we will look at one of the entry points to detect an attack in AWS at the earlier stages.

AWS Identity and Access Management (IAM) is a web service that helps an organization access AWS resources securely. A principal or an identity must be authenticated and authorized to access a resource in AWS, such as an EC2 instance or S3 bucket. You can access AWS in different ways to manage the users and services.

Figure 1: Interactive console using username, password, and account ID

Figure 2: Access keys: A combination of access key Id and secret access key. Programmatic calls to AWS using AWS Command Line Interface (CLI)

We are going to look at the scenario of lost access keys. Access keys are generally long-term credentials. A relatively well known security problem that happens is when AWS access keys leak via a public code repository. For example, think of a developer who hardcoded the access keys in source code and then pushes the access keys to a GitHub repository. AWS automatically scans for the access keys and then informs the users about the access key leak, but consider how quickly attackers are able to detect the key leak. Misconfigurations also remain a primary cause for data breaches. Access keys credentials stored in users’ computers are in the form of clear text. Targeted phishing can also lead to access keys compromise.

Figure 3: Access keys stored in users’ computers in the form of clear text

Assuming the attacker got a hold of an access key with limited privileges, how could we detect the attacker who had authenticated to the AWS account?

Let us consider the attacker attained limited privileges from the compromised access keys. The attacker got a hold of the access keys, but does not know what kinds of privileges he attained in that compromised AWS account. He will enumerate further to find out who he is.

Once the attacker gets a hold of an AWS account, he will start enumerating the access he got in the environment by listing the users, the groups, policies, and roles that the compromised user is a part of, and also by enumerating the other services such as S3, EC2, Lambda, and many more. The below screenshot shows how it looks when an attacker logs in with limited privilege through the AWS management console to enumerate users.

Figure 4: A screenshot of the AWS management console denying an unauthorized user access to list users

Figure 5: A screenshot of an IAM dashboard unauthorized access to the IAM resources

What does the error look like in an AWS-CLI as the attacker gets programmatic access? Take a look at the figure below.

Figure 6: Attacker trying to enumerate the list of users using AWS CLI

AWS has many services and close to ten thousand API calls. Poking through all the services manually one by one and identifying what permissions are available for the compromised account will take a lot of time. Attackers will probably miss some services to enumerate. Therefore, using an automated tool is the best way for an attacker to enumerate. There are many tools available to do this, such as Pacu, Scout Suite, PMapper, and more, which will automate the enumeration for the attacker once he gets a hold of access keys. The below screenshot shows the different stages the attacker could enumerate using Pacu.

Figure 7: Attacker listing the different type of module available in Pacu to attack an AWS infrastructure

Assuming the attacker got hold of access keys of a victim account, the attacker then runs one of the modules from PACU. The attacker needs to know what services he has access to in the victim’s AWS account. The attacker could use the BruteForce module from PACU to enumerate the list of services and functions automatically. The figure below shows the compromised access keys do not have authorization to different services.

Figure 8: Running BruteForce operations shows the compromised access keys authorized and unauthorized API calls

The attacker could specifically target the IAM services to enumerate the available users, groups, roles, and policy permissions. The attacker is using the iam_enum_permissions module from Pacu for the enumeration on the below screenshot. The compromised access ID does not have the required permissions to enumerate the IAM.

Figure 9: Running Pacu to enumerate the available user related permissions

LogRhythm’s Logic to Detect this AWS Attack

The attacker will enumerate the AWS services using the compromised access keys. When the attacker tries to access a service, every single request from the attacker is an API call, whether authorized or unauthorized. The API calls will record in AWS CloudTrial logs. Collecting CloudTrial logs is thus very important to detect an attack at earlier stages. LogRhythm will collect these logs using the API access provided by AWS to help detect these attacks as soon as possible. The attacker running the automated tool will generate an enormous amount of unique API calls to different services. LogRhythm’s logic behind detecting this attack is to look for multiple API requests within a short time. The attacker who compromised the access key might have permission to do authorized or unauthorized API calls. For more detailed steps on how to collect logs from AWS CloudTrail using LogRhythm, refer to our documentation here.

When an attacker tries to enumerate the available AWS services, LogRhythm will detect the attack by analyzing the CloudTrail logs. LogRhythm’s 100-point risk-based priority scale provides a relative measure of events risk to help organizations prioritize analysis and response efforts.

Figure 10: AI Engine alarm indicating a BruteForce attack with high-risk score

The AI Engine rule looks for unique API calls within a short amount of time for authorized and unauthorized API calls. The attacker may have limited privileges, and the number of API calls could have been more than a hundred within a couple of seconds.

Figure 11: AI Engine rule block with Unique API calls within a short timeframe for success and failure

A drill down of the alarm referring to figure 10 will show the unique API calls related to the alarm triggered.

Figure 12: Screenshot of Alarm Drill Down referring to figure 10

The below screen shot lists the user agent, username, and source IP address related to the triggered alarm in figure 10.

Figure 13: A screenshot of the user agent, username, source IP address related to the triggered alarm

The attacker could use an automated tool or manually poke around the services. The second scenario below will look for authorization failure for unique API calls from the same user. This alarm will be triggered when an attacker goes outside his boundary to access different services without the required permission.

Figure 14: Alarm indicating API authorization failure

The AI Engine rule below looks for Unique API calls within a short time for unauthorized API calls.

Figure 15: A screenshot of the LogRhythm AI Engine rule to detect unauthorized API calls

Drill down of the alarm shows the authorization failures for unique API calls such as listing users, roles, groups, policies, and MFA tokens. It is suspicious when someone tries to list the account with multi-factor authentication assignment status and then that authorization fails.

Figure 16: Unique API calls related to the alarm triggered, reference figure 14

Drill down of the alarm will reveal the user agent, username, and source IP address related to the triggered alarm. See below:

Figure 17: The user agent, username, source IP address related to the triggered alarm

LogRhythm can analyze CloudTrail logs and hunt compromised AWS credentials by looking for unauthorized and malicious activity in an organization’s AWS account. CloudTrail logs gives you visibility on the API calls made through the management console, CLI tools, and AWS software development kit (SDK).

Provisioning IAM user access keys to a third party will give long-term access to your AWS account. As a security best practice, organizations could create temporary security credentials by using IAM roles. AWS root user access key gives full access to all the available resources. Don’t create an access key for the root account. Regularly rotate your AWS access keys. Enable multi-factor authentication to the root account and IAM users. Create IAM policies granting the least privileges. Organizations can also generate a credential report that lists all users, unused credentials in your account, and add the status of various credentials periodically.

Protect Your AWS Environment

With LogRhythm, it’s easy to achieve cloud security in your AWS environment. Download this data sheet to learn more about how LogRhythm can help you gain holistic visibility and safeguard your AWS infrastructure.

The post Detecting Attacks on Amazon Web Services (AWS) appeared first on LogRhythm.

*** This is a Security Bloggers Network syndicated blog from LogRhythm authored by YiJia Koo. Read the original post at: https://logrhythm.com/detecting-attacks-on-amazon-web-services-aws/