Resources
    Using Amazon GuardDuty: I ...
    16 September 22

    Using Amazon GuardDuty: IAM Findings

    Posted byINE
    facebooktwitterlinkedin
    news-featured

    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.

    agdif1.png

    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).

    agdif0.png

    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.

    agdif3.png

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

    agdif4.png

     

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

    agdif5.png

     

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

    agdif6.png

     At first, there will not be any findings.

    agdif7.png

    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

    agdif8.png

    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

    agdif9.png

    Create an access key for this account.

    Command: 

    aws iam create-access-key --user-name student

    agdif10.png

    Update the username of this account to the name “Bob”.

    Command: 

    aws iam update-user --user-name student --new-user-name Bob

    agdif11.png

    Revert back the name “Bob” to “student”.

    Command: 

    aws iam update-user --user-name Bob --new-user-name student

    agdif12.png


    Try to list the access keys of this account.

    Command: 

    aws iam list-access-keys --user-name student

    agdif13.png

    Step 7: Get back to the AWS console and search for “EC2” and navigate to the EC2 dashboard.

    agdif14.png

    Step 8: Create a new instance with an instance profile. Launch a new instance by clicking “Launch instance”.

    agdif15.png


    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).

    agdif16.png

    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.

    agdif17.png

    Step 11: Click on “Advanced details”.

    agdif18.png

    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.

    agdif19.png

    Click on “Launch instance”.

    agdif20.png


    Step 13: Wait until the instance state changes to “Running”. After that click on the instance id.

    agdif21.png


    Step 14: Click on “Modify IAM role”.

    agdif22.png

    Step 15: Click on “Create new IAM role”.

    agdif23.png

    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”.

    agdif24.png

    Step 17: Select Trusted entity type as “AWS service” and use case as “EC2”.

    agdif25.png

    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.

    agdif26.png

    AmazonS3FullAccess policy grants permissions that allow full access to Amazon S3.

    Step 19: Set role name as “instance_role” and click on “Create role”.

    agdif27.png


    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.

    agdif28.png

    Now, click on “Update IAM role”.

    agdif29.png

    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.

    agdif30.png

    Use EC2 instance connect and click on “Connect”.

    agdif31.png

    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

    agdif32.png

    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>

    agdif33.png

    Step 24: Check the caller identity.

    Command: 

    aws sts get-caller-identity

    agdif34.png

    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

    agdif35.png

    Step 26: Fetch your public ip address.

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

    agdif36.png

    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

    agdif37.png

    Step 28: Upload the file “ip_list.txt” to the created bucket.

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

    agdif38.png

    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.

    agdif39.png

    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. 

    agdif40.png

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

    agdif41.png

    Step 31: Make the created threat IP active.

    agdif42.png


    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}'

    agdif43.png

    Step 33: Download “ip_list.txt” file.

    Command: 

    aws s3api get-object --bucket lab-bucket-029911053369 --key ip_list.txt iplist.txt

    agdif44.png

    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.

    agdif45.png

    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.

    agdif46.png


    agdif47.png

    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.

    agdif48.png


    agdif49.png

    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.

    agdif50.pngagdif51.png

    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.

    agdif52.pngagdif53.png

    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.

    agdif54.png


    agdif55.png

    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.

    agdif56.pngagdif57.png


    Thus, GuardDuty generates a finding whenever it detects unexpected and potentially malicious activity in IAM operations.

    References: 

    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!

    © 2024 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo