What We Find on Cloud Penetration Tests

Cloud penetration testing examines the security of your AWS, Azure, or Google Cloud environment — not the applications running on it, but the configuration of the infrastructure itself. Cloud misconfigurations are the leading cause of cloud-related security incidents, and they share a characteristic that makes them particularly problematic: they are easy to introduce through routine operations, difficult to detect without active testing, and can exist in production environments for months before being exploited. What we find on cloud assessments consistently reflects the challenges of managing complex identity and access policies across environments that grow faster than governance processes keep up.

Publicly accessible storage

Misconfigured object storage — S3 buckets, Azure Blob containers, Google Cloud Storage buckets — set to allow public access remains one of the most commonly exploited cloud vulnerabilities and is found regularly on cloud assessments. The issue is rarely intentional. It typically arises through automation that creates buckets with defaults that were permissive at the time, misconfiguration introduced by infrastructure-as-code changes, or misunderstanding of the interaction between bucket-level and object-level access controls.

The contents of exposed buckets vary by organisation but routinely include database backups, application configuration files containing database credentials or API keys, customer data exports, internal documentation, and code repositories. Public storage is indexed by specialised search engines and scanning tools; data believed to be private is often accessible to anyone who looks for it.

Overpermissive IAM

Identity and Access Management misconfigurations are the most complex category of cloud findings and carry the highest potential impact. In practice, IAM policies in organisations that have grown their cloud usage organically tend to accumulate permissions over time — developer roles with broad access that was convenient during initial setup and never scoped down, service accounts with wildcard resource permissions, and cross-account trust relationships that create escalation paths no single administrator intended to create.

Starting from a set of credentials that appear to have limited scope — a developer role, a service account for a specific application, a read-only role — we regularly find routes to administrative permissions through sequences of IAM actions that are individually permitted. Assume-role permissions that allow transitioning to more powerful roles. Lambda functions that can be updated by a developer role and execute with a privileged execution role. IAM users that can create new IAM policies and attach them to themselves. The escalation paths are often unintended and invisible to the team responsible for managing them.

Exposed metadata service

Cloud providers expose an instance metadata service — AWS IMDS, Azure IMDS, and equivalent services in other platforms — that provides configuration data and temporary credentials to compute instances. These credentials carry the permissions of the instance's IAM role, which are often broader than the application running on the instance requires.

If an application running on a cloud instance is vulnerable to Server-Side Request Forgery (SSRF) — a class of vulnerability where the application can be made to fetch URLs specified by the attacker — that vulnerability can be used to query the metadata service from the server side and retrieve the instance's cloud credentials. This converts an application-layer vulnerability into cloud infrastructure access. The combination is found on assessments that cover both application and cloud security; neither the SSRF nor the permissive instance role is a critical finding in isolation, but together they represent a significant escalation path.

Logging and monitoring gaps

Cloud platforms generate extensive audit logs by default, but those logs must be actively collected, retained, and monitored to be useful for security purposes. A consistent finding is that critical audit logging is either not enabled, or enabled but stored in a way that makes it inaccessible for security monitoring. AWS CloudTrail not enabled across all regions. Azure Activity Log not forwarded to a SIEM. Log retention configured to the minimum period rather than one aligned to incident investigation requirements.

The consequence is not just that attacks are harder to detect in real time — it is that when an incident occurs, the evidence needed to understand what happened is absent. Incident response teams attempting to reconstruct an attacker's path through a cloud environment with no audit logging have limited options. We regularly find cloud environments where this logging either does not exist or has never been tested to confirm it captures what it is supposed to capture.

Secrets in pipelines and container images

Cloud deployments introduce new places where credentials end up outside of secrets management systems. Environment variables on EC2 instances and Lambda functions containing database passwords or third-party API keys in plaintext. Container images in private registries that have credentials embedded at build time — either through Dockerfile commands that retrieved secrets during the build, or through docker history-visible layers. CI/CD pipeline configurations that log secrets to job output, or that store them in configuration files committed to source repositories.

Infrastructure-as-code templates — Terraform, CloudFormation, Bicep — that include sensitive values as literals rather than references to secrets management services. These exposure points are specifically targeted when an attacker gains initial access to a cloud account or a code repository, and the volume of secrets findable through a combination of repository access and basic cloud enumeration is consistently higher than organisations expect.