Using Amazon GuardDuty: S3 Findings

In our lab walkthrough series, we go through selected lab exercises on our INE Platform. Subscribe or sign up for a 7-day, risk-free trial with INE and access this lab and a robust library covering the latest in Cyber Security, Networking, Cloud, and Data Science!

Purpose: An attacker can exploit misconfigurations and perform malicious tasks, so it is important to have a system/service that can detect all potential security threats which an attacker can take advantage of. In this article we will look at how we can use AWS GuardDuty to detect potential security threats using S3 Finding types.

Technical difficulty:

What is AWS GuardDuty Service?

Amazon GuardDuty is a threat detection service that continuously monitors your AWS Service accounts, workloads, and data stored in Amazon S3 for malicious activity and provides detailed security findings for visibility and remediation.

To identify and prioritize potential threats, the service uses machine learning, anomaly detection, and integrated threat intelligence. Threat intelligence combined with machine learning and behavior models helps in the detection of activity such as cryptocurrency mining, credential compromise, unauthorized and unusual data access, communication with known command-and-control servers, or API calls from known malicious IPs.

Let’s understand Amazon GuardDuty findings

A GuardDuty finding denotes a potential security issue discovered in your network. When GuardDuty detects unexpected and potentially malicious activity in your AWS environment, it generates a finding. You can view and manage your GuardDuty findings via the Findings page in the GuardDuty console, as well as through AWS CLI or API operations.

GuardDuty finding types:

S3 finding types
EC2 finding types
IAM finding types
Kubernetes finding types
Malware Protection finding types

In this article, we will mainly discuss S3 finding types.

GuardDuty S3 finding types

The S3 finding types are specific to Amazon S3 resources, with a Resource Type of S3 Bucket if the data source is CloudTrail data events for S3, or AccessKey if the data source is CloudTrail management events. The severity and specifics of the findings will vary depending on the type of finding and the permission associated with the bucket.

Now that we have covered all the key terms for the lab, let's carry out the experiment.

Lab Scenario

We have set up the below scenario in our INE labs for our students to practice. The screenshots have been taken from our online lab environment.

Lab Link: GuardDuty

Objective

Enable and use AWS GuardDuty service to detect potential security threats and misconfigurations with using GuardDuty.

Solution

Step 1: Click the lab link button to get access credentials. Login to the AWS account with these credentials.

Step 2: Enable GuardDuty from the console. Search for GuardDuty in the search bar and navigate to the GuardDuty dashboard.

Step 3: AWS provides a 30 days free trial for the GuardDuty service. Click on Get Started to use this free trial.

Step 4: To enable the GuardDuty service, click on the Enable GuardDuty button.

At first, there will not be any findings.

Step 5: Navigate to Usage. This will display the Estimated total daily cost by the data source.

Step 6: Configure AWS CLI with given credentials and interact with S3 buckets.

Configure AWS CLI using the following command.

Copy the AWS Access Key Id and AWS Secret Access Key form the lab login credentials page and use the below command to configure the AWS CLI.

Command: aws configure

Step 7: Let’s try to list the S3 buckets using S3 API.

Command: aws s3api list-buckets --query "Buckets[].Name"

Step 8: Now, let’s fetch the account id and note down the output somewhere.

Command: aws sts get-caller-identity

Step 9: Create an S3 bucket. You need to specify the name and region in which you want to create this bucket.

Note: The bucket name must be unique globally.

Command:

aws s3api create-bucket \

--bucket lab-bucket-343559064700 \

--region us-east-1

Step 10: Allow the public access to the bucket by removing “public block access”.

Command:

aws s3api delete-public-access-block \

--bucket lab-bucket-343559064700

Step 11: Grant public access to an S3 bucket to all AWS users by changing ACL.

Command:

aws s3api put-bucket-acl --bucket lab-bucket-343559064700 \

--grant-full-control uri=http://acs.amazonaws.com/groups/global/AuthenticatedUsers

Step 12: Fetch your public IP address and note it down somewhere.

Command: echo $(curl -s https://api.ipify.org)

This will output the public IP address.

Step 13: Add the IP to a plain text file and name it as “ip_list.txt”.

Command: echo “103.177.252.62” > ip_list.txt

This command will create a file with name “ip_list.txt” and overwrite it with the given ip address.

Step 14: Upload the “ip_list.txt” to the created S3 bucket.

Command: aws s3 cp ip_list.txt s3://lab-bucket-343559064700/

We got an S3 URI as an output. Convert the URI to an object URL using this syntax.

Syntax: https://<bucket-name>.s3.amazonaws.com/<object or key name>

So finally the object URL will be similar to the following one.

Object URL: https://lab-bucket-343559064700.s3.amazonaws.com/ip_list.txt

Step 15: Navigate back to the GuardDuty dashboard click on “Lists” from side navigation bar.

Step 16: Click on “Add a threat IP list”.

Threat lists consist of known malicious IP addresses. These lists can be supplied by third party threat intelligence or created specifically for your organization. GuardDuty generates findings based on threat lists. You can include a maximum of 250,000 IP addresses and CIDR ranges in a single threat list. GuardDuty only generates findings based on activity that involves IP addresses and CIDR ranges in your threat lists, findings will not be generated based on domain names. At any given time, you can have up to six uploaded threat lists per AWS account per Region.

Step 17: Enter the “List name” as “ip_list”. Paste object URL in the “Location” field and choose “Plaintext” as format.

Step 18: After adding the list, activate the list by checking the checkbox.

Step 19: Go back to the console and try to interact with S3 buckets. List S3 buckets.

Command: aws s3api list-buckets --query "Buckets[].Name"

Step 20: Now, let’s list the objects inside the buckets.

Command: aws s3api list-objects --bucket lab-bucket-343559064700 --query 'Contents[].{Key: Key, Size: Size}'

Step 21: Download the object.

Command:

aws s3api get-object --bucket lab-bucket-343559064700 --key ip_list.txt out.txt

Step 21: Navigate back to the GuardDuty dashboard and check the findings.

Note: Refresh the findings page if the findings are empty. Detecting findings might get delayed.

Each GuardDuty finding has an assigned severity level and value that reflects the potential risk. GuardDuty breaks down this range into High, Medium, and Low severity levels.

Step 22: Click on finding with the name “PenTest:IAMUser/KaliLinux”.

This finding informs you that a machine running Kali Linux is making API calls using credentials that belong to the listed AWS account in your environment.

This finding will provide the details about the affected resource. Here the affected resources are IAM role and S3 bucket. It will also provide the action done by the attacker. Here the action was to change bucket ACL and it is listed as “PutBucketAcl”

Step 23: Click on finding with the name “Policy:S3/BucketPublicAccessGranted”.

This finding informs you that the listed S3 bucket has been publicly exposed to all authenticated AWS users because an IAM entity has changed a bucket policy or ACL on that S3 bucket.

Here the affected resources are IAM role and S3 bucket.

It will also provide the action done. Here the action was to change bucket ACL and it is listed as “PutBucketAcl”.

Step 24: Click on finding with the name “Policy:S3/BucketBlockPublicAccessDisabled”

This finding informs you that Block Public Access was disabled for the listed S3 bucket. When enabled, S3 Block Public Access settings are used to filter the policies or access control lists (ACLs) applied to buckets as a security measure to prevent inadvertent public exposure of data.

Typically, S3 Block Public Access is turned off on a bucket to allow public access to the bucket or to the objects within. When S3 Block Public Access is disabled for a bucket, access to the bucket is controlled by the policies or ACLs applied to it. This does not mean that the bucket is shared publicly, but you should audit the policies and ACLs applied to the bucket to confirm that appropriate permissions are applied.

Here the affected resources are IAM role and S3 bucket. The action was to disable Block Public Access .

Step 25: Click on finding with the name “Recon:IAMUser/MaliciousIPCaller.Custom”

This finding informs you that an API operation that can list or describe AWS resources in an account within your environment was invoked from an IP address that is included on a custom threat list. The threat list used will be listed in the finding's details. An attacker might use stolen credentials to perform this type of reconnaissance of your AWS resources in order to find more valuable credentials or determine the capabilities of the credentials they already have.

Step 26: Click on finding with the name “UnauthorizedAccess:IAMUser/

MaliciousIPCaller.Custom”.

This finding informs you that an API operation was invoked from an IP address that is included on a threat list that you uploaded. In , a threat list consists of known malicious IP addresses. This can indicate unauthorized access to AWS resources within your environment.

Thus GuardDuty generates a finding whenever it detects unexpected and potentially malicious activity in your AWS environment.

References:

Amazon GuardDuty (https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html)

Conclusion

Congratulations! You have successfully enabled and used AWS GuardDuty service and detected the possible security threats using Amazon GuardDuty.

Try out AWS GuardDuty hands-on in our lab! Subscribe or sign up for a 7-day, risk-free trial with INE to access this lab and a robust library covering the latest in Cyber Security, Networking, Cloud, and Data Science!