Zero-Trust Cloud Audit: Vulnerability Assessment for a Global Retailer

Background

A global retail organisation serving 150,000 active users across e-commerce and in-store channels engaged XHack to conduct a cloud-focused vulnerability assessment against their AWS environment. The client had recently migrated core workloads to the cloud and wanted an independent review of their security posture ahead of a compliance audit.

Their internal team had reviewed the environment previously and not raised any material concerns. XHack was brought in for an independent, adversarial perspective.

The engagement was structured as a grey-box cloud VAPT. The client provided read access to assist with enumeration, and XHack assessed the environment with a zero-trust methodology, treating every trust boundary as potentially already compromised and following every permission path to see what an attacker could reach from each foothold.

What Zero-Trust Means in a Cloud Context

Zero-trust is not a product. It is the approach of assuming no implicit trust exists anywhere in your environment, regardless of whether access originates from inside the network, an existing session, or a recognised service identity.

Applied to cloud infrastructure this means every IAM role, every storage policy, every service-to-service trust relationship, and every network rule is assessed as if the thing protecting it has already failed. The question is not whether the boundary is in place. It is what the blast radius looks like when that boundary breaks.

Most cloud misconfigurations are not on the perimeter. They accumulate inside the environment, left behind by engineers who were moving fast and made decisions that seemed reasonable in the moment. A zero-trust review follows those decisions to their logical end.

Environment Overview

The client ran their infrastructure primarily on AWS, using EC2 for application workloads, RDS for relational databases, S3 for storage and static assets, and Lambda for event-driven processing. Customer accounts, order history, and payment data were all processed within this environment, placing the client firmly in scope for PCI-DSS compliance requirements.

A number of SaaS integrations connected to the AWS environment through API keys and service accounts managed within the account.

Vulnerabilities Found

The assessment uncovered multiple vulnerabilities spanning storage exposure, identity and access management, secrets handling, network architecture, and logging coverage. Taken individually, each finding was serious. Together they formed a connected exposure chain that placed the full 150,000-user dataset at risk.

Publicly Accessible Storage Containing Customer Data

Several S3 buckets had public read access configured. One of these buckets was actively serving customer-facing static assets and was considered non-sensitive by the engineering team. On inspection, the same bucket also contained files produced by an automated pipeline including internal configuration data and, in one instance, a file with database connection strings from the staging environment.

The bucket had been publicly accessible for several months. It had not been picked up in any access review because it was created by a developer outside the standard provisioning workflow during a feature sprint and never transferred into the tracked asset inventory.

Overprivileged IAM Roles Across the Account

Multiple IAM roles had been granted significantly broader permissions than their function required. The most severe was a role attached to a Lambda function responsible for processing order confirmation events. That role had been given full S3 access across every bucket in the account, full RDS access, and permission to create new IAM users.

None of those permissions were required for the function to do its job. A single code injection in a Lambda dependency or a supply chain compromise of any package the function imported would have given an attacker unrestricted access to the entire account, including the customer database and payment processing infrastructure.

Hardcoded AWS Credentials in the CI/CD Pipeline

The CI/CD pipeline configuration contained hardcoded AWS access keys stored as plaintext environment variables. The keys belonged to an IAM user with read access to the production datastore.

The keys had not been rotated since the pipeline was originally set up. No automated secret scanning was in place across the repository, and no alerting existed on the IAM user's access activity. The keys had been live and unmonitored for an extended period before the assessment.

No Segmentation Between Staging and Production

The staging and production environments shared a VPC with permissive internal security group rules. Database instances in staging were reachable from the production application subnet. The staging database had been seeded from a production backup for testing purposes and the data was never anonymised before loading.

This meant the staging environment held real customer records including names, email addresses, and order history, in an environment with significantly weaker access controls than production. Any developer with staging access could query live customer data directly.

CloudTrail Logging Gaps

CloudTrail was enabled on the primary region but had been left unconfigured in several other active regions. API activity across those regions generated no log records and was entirely invisible. Log retention on the primary region was set to 30 days.

PCI-DSS v4.0 requires 12 months of audit log retention with at least 3 months immediately available. The client was failing this requirement across both the retention period and the coverage gaps at the time of assessment.

Compliance Implications

Because customer payment card data was processed within the environment, the client was in scope for PCI-DSS v4.0. The assessment identified failures against the following requirements:

Requirement 3 covering protection of stored cardholder data was violated by the public storage bucket exposure of database connection strings.

Requirement 7 requiring least-privilege access control for all system components in the cardholder data environment was violated by the overprivileged IAM roles.

Requirement 10 covering audit log generation, retention, and availability was violated by the 30-day retention configuration and the regional coverage gaps.

The presence of real, non-anonymised customer data in the staging environment also created exposure under GDPR Article 25, which requires data protection by design and by default across all environments where personal data is processed, not only production.

Remediation

XHack delivered findings in a prioritised report with specific, actionable steps for each issue. The client's team resolved all critical findings within one week of delivery.

The S3 buckets were audited, public access was removed, and bucket policies were reviewed and tightened. The overprivileged IAM roles were scoped down to minimum required permissions for each service. The hardcoded credentials were removed from the CI/CD pipeline and replaced with AWS Secrets Manager references, and the exposed keys were immediately rotated.

The staging database was rebuilt using anonymised data. Network segmentation between staging and production was enforced through updated security group rules.

CloudTrail was extended to 13 months retention and enabled across all active regions. An AWS Config rule was deployed to alert on public bucket creation or access policy changes going forward.

XHack conducted a verification review at the close of the engagement and confirmed all critical and high severity findings had been remediated.

What This Engagement Demonstrates

The client's internal team had reviewed the environment before the engagement. They had not found these issues. That is not an unusual situation and it is not a failure of competence. Internal teams built the environment. They know what was deliberate. They are less likely to notice what accumulated gradually through decisions that made sense at the time and were never revisited.

With 150,000 active users and payment data in scope, the cost of any one of these findings being exploited before discovery would have been significant. The publicly accessible bucket alone had been in that state for months. The hardcoded credentials had never been rotated. The staging database held real customer records.

None of these were detected by the internal review. All of them were found within the first two weeks of an adversarial assessment.

Cloud infrastructure is not secure by default and it does not stay secure without active, independent review. XHack's zero-trust approach finds what routine internal checks miss, and finds it before someone else does.