Using Amazon GuardDuty: IAM 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 IAM Finding types.
Technical difficulty:
| Novice | Beginner | Competent | Proficient | Expert
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 about 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:
- IAM finding types
- S3 finding types
- EC2 finding types
- Kubernetes finding types
- Malware Protection finding types
In this article, we will mainly discuss IAM finding types.
What is IAM?
AWS Identity and Access Management (IAM) is a web service that allows you to control access to AWS resources in a secure manner. IAM is used to manage who is authenticated (signed in) and authorized (has access to resources).
IAM provides the following features: Granular permissions, shared access to your AWS account, Secure access to AWS resources for Amazon EC2 applications, Multi-factor authentication (MFA), identity federation, identity information for assurance, PCI DSS compliance Integrates with numerous AWS services, is consistent, and is free to use.
GuardDuty IAM finding types
The IAM finding types are specific to IAM entities and access keys and always have a Resource Type of AccessKey. The severity and details of the findings differ based on the finding type.
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: Amazon GuardDuty IAM Findings
Objective
Enable and use AWS GuardDuty service to detect potential security threats and misconfigurations using GuardDuty IAM Findings.
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: Configure the AWS CLI using credentials that we got for the lab.
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 6: Interact with AWS account using various commands. Change the AWS account password policy to a weak policy.
Command:
aws iam update-account-password-policy --no-require-symbols --no-require-numbers --no-require-uppercase-characters --no-require-lowercase-characters
Create an access key for this account.
Command:
aws iam create-access-key --user-name student
Update the username of this account to the name “Bob”.
Command:
aws iam update-user --user-name student --new-user-name Bob
Revert back the name “Bob” to “student”.
Command:
aws iam update-user --user-name Bob --new-user-name student
Try to list the access keys of this account.
Command:
aws iam list-access-keys --user-name student
Step 7: Get back to the AWS console and search for “EC2” and navigate to the EC2 dashboard.
Step 8: Create a new instance with an instance profile. Launch a new instance by clicking “Launch instance”.
Step 9: Enter “lab-instance” as name and “Amazon Linux” as AMI.
The Amazon Linux AMI is a supported and maintained Linux image provided by Amazon Web Services for use on Amazon Elastic Compute Cloud (Amazon EC2).
Step 10: Select “Proceed without a key pair” and select “Create security group”. By default these settings will allow port 22 so that we can connect with the instance.
Step 11: Click on “Advanced details”.
Step 12: Enable the Metadata for the instance. Choose “V1 and V2 (token optional)” as the Metadata version.
Instance Metadata Service (IMDS) provides data about your instance that you can use to configure or manage the running instance. Instance metadata is divided into categories, for example, host name, events, and security groups. The temporary access credentials can be retrieved using the metadata.
Click on “Launch instance”.
Step 13: Wait until the instance state changes to “Running”. After that click on the instance id.
Step 14: Click on “Modify IAM role”.
Step 15: Click on “Create new IAM role”.
An IAM role is a specific permissioned IAM identity that you can create in your account. It is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, rather than being associated with a single person, a role is intended to be assumable by anyone who requires it.
Step 16: Click on “Create role”.
Step 17: Select Trusted entity type as “AWS service” and use case as “EC2”.
Step 18: Search for “s3full” and select “AmazonS3FullAccess” policy and click “Next”.
A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when an IAM principal (user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied.
AmazonS3FullAccess policy grants permissions that allow full access to Amazon S3.
Step 19: Set role name as “instance_role” and click on “Create role”.
Step 20: Navigate back to the previous tab and attach a role with the EC2 instance. Click on the refresh button to load the new role.
Now, click on “Update IAM role”.
Step 21: From the EC2 instance listing page , Select EC2 instance and click on “Connect”.
Amazon EC2 Instance Connect is a simple and secure way to connect to your instances using Secure Shell (SSH). With EC2 Instance Connect, you can control SSH access to your instances using AWS Identity and Access Management (IAM) policies as well as audit connection requests with AWS CloudTrail events.
Use EC2 instance connect and click on “Connect”.
Step 22: Retrieve temporary credentials using metadata services version 1.
Command:
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/instance_role
Step 23: Set the required environment variable to allow AWS CLI to use the temporary access credentials. AWS CLI prioritizes the environment variable over the stored credentials.
Command:
export AWS_ACCESS_KEY_ID = <AWS Access Key ID Value>
export AWS_SECRET_ACCESS_KEY = <AWS Secret Access Key Value>
export AWS_SESSION_TOKEN = <AWS Session Token Value>
Step 24: Check the caller identity.
Command:
aws sts get-caller-identity
Step 25: Create an S3 bucket. Append account id with the name to make it unique.
Command:
aws s3api create-bucket \
--bucket lab-bucket-029911053369 \
--region us-east-1
Step 26: Fetch your public ip address.
Command: echo $(curl -s https://api.ipify.org)
Step 27: Write this IP address to a plain text file and save it as “ip_list.txt” .
Command: echo “137.97.83.9” > ip_list.txt
Step 28: Upload the file “ip_list.txt” to the created bucket.
Command: aws s3 cp ip_list.txt s3://lab-bucket-029911053369/
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-029911053369.s3.amazonaws.com/ip_list.txt
Step 29: Navigate back to GuardDuty dashboard and click on lists.
Step 30: 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.
Enter the “List name” as “ip_list”. Paste object URL in the “Location” field and choose “Plaintext” as format.
Step 31: Make the created threat IP active.
Step 32: Interact with the resources so that it could make a finding. List S3 bucket.
Command:
aws s3api list-objects --bucket lab-bucket-029911053369 --query 'Contents[].{Key: Key, Size: Size}'
Step 33: Download “ip_list.txt” file.
Command:
aws s3api get-object --bucket lab-bucket-029911053369 --key ip_list.txt iplist.txt
Navigate back to the GuardDuty dashboard and refresh the page.You will find findings similar to this.
Note: Listing all the findings might take some time.
Step 34: Click on “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. A threat list consists of known malicious IP addresses. This can indicate unauthorized access to AWS resources within your environment.
Step 35: Click on “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 36: Click on “UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS” of resource “S3 Bucket”.
This finding informs you that a host outside of AWS has attempted to run AWS API operations using temporary AWS credentials that were created on an EC2 instance in your AWS environment. The listed EC2 instance might be compromised, and the temporary credentials from this instance might have been exfiltrated to a remote host outside of AWS. AWS does not recommend redistributing temporary credentials outside of the entity that created them (for example, AWS applications, EC2, or Lambda). However, authorized users can export credentials from their EC2 instances to make legitimate API calls. To rule out a potential attack and verify the legitimacy of the activity, validate if the use of instance credentials from the remote IP in the finding is expected.
Step 37: Click on “PenTest:IAMUser/KaliLinux” of resource “instance_role”.
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. Here the affected resource is an instance role and the access credentials are set on the Kali Linux machine and invoked an API to create a new bucket.
Step 38: Click on “UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS” of resource “instance_role”.
This finding informs you that a host outside of AWS has attempted to run AWS API operations using temporary AWS credentials that were created on an EC2 instance in your AWS environment. The instance role credentials are set outside of the AWS environment and invoked an API to create a new bucket.
Step 39: Click on “PenTest:IAMUser/KaliLinux” of resource “student”.
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. Here the affected resource is an instance role and the access credentials are set on the Kali Linux machine and invoked an API to Update the user data.
Thus, GuardDuty generates a finding whenever it detects unexpected and potentially malicious activity in IAM operations.
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 IAM Findings.
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!