Welcome! We hope that this introductory lab will be enjoyed by red and blue alike. Purple-teaming FTW! It showcases using AWS CloudTrail logs to detect malicious activity, as well as S3 enumeration.

To get started, download the CloudTrail logs in INCIDENT-3252.zip from the 🔎-case-files channel in the Pwned Labs Discord.

Scenario

We've been alerted to a potential security incident. The Huge Logistics security team have provided you with AWS keys of an account that saw unusual activity, as well as AWS CloudTrail logs around the time of the activity. We need your expertise to confirm the breach by analyzing our CloudTrail logs, identifying the compromised AWS service and any data that was exfiltrated.

Lab prerequisites

• Basic Linux command line knowledge

Learning outcomes

• Prettifying JSON files for easier analysis
• Familiarity with the AWS CLI
• Familiarity with analyzing CloudTrail logs
• Enumerating S3 buckets
• Simulating an attacker to validate the path to breach

Difficulty

Beginner

Focus

Blue

Real-world context

Analyzing AWS CloudTrail logs is a standard practice for detecting suspicious activity within an AWS account, while S3 buckets are frequently targeted by attackers due to the valuable data they can contain.

Starting point

Provided AWS keys and case file

Submit Flag

 Format: MD5 hash

Walkthrough

Confirming the Breach by Analyzing CloudTrail Logs

To get started, download the CloudTrail logs in INCIDENT-3252.zip from the 🔎-case-files channel in the Pwned Labs Discord.

With the case file downloaded, let's start the investigation.

Note: This guide uses Linux but it's possible to complete the activity using any operating system

First unzip the file with unzip. If you need to install it first, run apt install unzip .

Opening the file in a text editor such as Nano or Vim reveals that the JSON files aren't prettified, which make them harder to read. To prettify the files we can use jq - a command-line JSON processor for parsing and structuring data. Install it if needed with the command apt install jq . Then issue the command below in the current directory containing the JSON files.

Opening the file in nano the data is now much easier to read and scan.

We notice that the CloudTrail logs contain the time of creation in the file name and they are ordered by time. The earliest time is T2035 so let's start there. We suspect that the temp-user account is involved, and grep the file with temp-user as the search term.

This reveals that an IAM user named temp-user with the globally unique ARN (Amazon Resource Name) arn:aws:iam::107513503799:user/temp-user from the AWS account 107513503799 issued the CLI command aws sts get-caller-identity on 2023-08-26T20:29:37Z .

The GetCallerIdentity action in AWS is part of the Security Token Service (STS) and allows users to retrieve details about the IAM identity whose credentials are used to make the API request. It can be considered a bit like the whoami command for Windows and Linux. The command returns the globally unique ARN, and, if applicable, the assumed IAM role's ARN. While this is a commonly used command, it is also used by malicious actors to determine the principal (IAM user or role) associated with compromised credentials, as part of gaining situational awareness.

The request originated from the IP address 84.32.71.19 . A check on the IP reveals that the request originated from Turkey. This is not a country where Huge Logistics has a technical presence, and so this could be a potential indicator of compromise (IoC). Let's dig in further.

Turning our attention to the next file, a quick look reveals that the temp-user account made an unsuccessful attempt to list the contents of a bucket named emergency-data-recovery .

Investigation of the next file reveals a lot of errors. The errorMessage value reveals that temp-user issued a large number of requests to other AWS services.

Although it is very noisy, malicious actors may look enumerate the permissions granted to their IAM user or role by brute force. There are multiple tools available for brute forcing IAM permissions, such as aws-enumerator and pacu. We find that there are 450 access denied messages generated by temp-user in the next log file.

Analyzing the next log file and again searching for actions invoked by the user, we see that they were able to assume the role named AdminRole ! The AssumeRole operation in AWS is part STS. It allows an AWS identity to assume a different privilege context for a limited period, and potentially access other resources that the assuming principal wouldn't normally have access to.

Examination of the next file reveals that the attacker again invoked the aws sts get-caller-identity command to verify their new execution context.

Noting their previous interest in the emergency-data-recovery S3 bucket, we find that they re-attempted to list and retrieve the contents.

The file emergency.txt was downloaded!

Retracing Steps as an Attacker

Now thinking as an attacker, we want to  to validate the exploitation path and access the compromised data. We use our gained keys and confirm our execution context.

Having previously identified the role named AdminRole (we recommend as a follow-up to check out the lab on Unauthenticated AWS IAM Principals Enumeration), the attacker attempted to assume it. We can do this with the command below.

After setting the keys with aws configure and then issuing the command aws configure set aws_session_token "<SessionToken>" to set the token, we call the command aws sts get-caller-identity and verify our new context.

We can now list the bucket contents and retrieve the files. PWNED!
The flag is in the file emergency.txt .

Further reading

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-examples.html

https://github.com/nagwww/s3-leaks