Stories from the cloud: security risks we see in testing 

Introduction 

Cloud adoption is still growing fast, with more businesses relying on the cloud to deploy and manage critical workloads. Whether through complex management of multi-cloud and hybrid infrastructures or by offloading security responsibilities to cloud service providers (CSPs), organisations are expanding their cloud presence at a rapid pace. But with this growth comes new security challenges that are often overlooked. 

While cloud technologies offer flexibility and scalability, they also introduce new attack surfaces. Traditional security models struggle to keep up with dynamic cloud workloads, shifting responsibilities between CSPs and customers, and the challenges of securing distributed environments.  

In this blog post, we’ll break down the most common and impactful security risks we’ve found during cloud penetration tests. Understanding these vulnerabilities is key to strengthening cloud defences and staying ahead of evolving threats. 

Insecure IAM: the root of cloud security failures 

Identity and Access Management (IAM) is arguably the most critical security control in the cloud—if compromised, it can undo benefits provided by all other defences. On several cloud penetration tests, we’ve leveraged compromised credentials to manipulate network security rules, effectively bypassing restrictions for critical services like databases and secrets management solutions. Since modifying a security rule is essentially just a single API call away, these tests demonstrate how a weak IAM configuration can quickly escalate into a full-blown security incident. 

The challenge? IAM is inherently complex, requiring management of a wide range of user types, roles, and permissions across dynamic cloud environments. Many organisations struggle with striking the right balance between security and usability, often leading to misconfigurations, excessive privileges, and weak authentication controls. These gaps create prime opportunities for attackers to gain access, increase privileges, and compromise critical cloud resources. 

Exploiting IAM issues in Azure

Whilst on an Azure assessment we were able to leverage managed identities to extract privileged cloud credentials. While none of the deployed resources were publicly accessible, we were able to use the extracted credentials with the control-plane to modify firewall rules for an Azure Key Vault. By adding our own IP address to the allowlist, we were then able to dump all secrets from the vault, including credentials for their Azure B2C (Business-to-Consumer Identity), further expanding our attack surface. 

Common issues 

• Unrestricted Resource Deployment – Allowing users to deploy resources via the cloud portal, CLI or SDKs without enforcing peer review can lead to a lack of organisational control over deployments. This increases the risk of misconfigurations and shadow IT, whilst enabling threat actors to directly create and access resources. 
• Overly Privileged Roles – Users or services often accumulate excessive permissions, whether through direct assignments, policy inheritance, or a mix of role- and resource-based access. This increases the risk of privilege escalation or misuse in case of compromise. 
• Insecure Role Assignments – Granting users permissions directly instead of enforcing role-based access control (RBAC) through groups or policies makes access harder to track and manage and can lead to shadow admin roles. 
• Cross-Environment Access – Poorly controlled cross environment policies, permissions and trusts i.e. cross-subscription (Azure), cross-account (AWS), or cross-project (GCP) access can allow attackers to move laterally and escalate privileges beyond their intended scope. 
• Weak Authentication Controls – Insecure password policies, weak conditional access policies and lack of Multi-Factor Authentication (MFA) increase the risk of attackers gaining access to accounts, particularly for high-privilege roles. 

Quick wins  

• Limit Direct Access to Cloud Environments – Use DevOps pipelines and peer reviews to enforce security controls instead of allowing unrestricted access. 
• Apply Least Privilege Role Assignments – Grant only the permissions necessary for each role and enforce separation of duties with dedicated admin accounts. Where possible start with empty policies and add permissions gradually to meet requirements. 
• Use Short-Term, Token-Based Authentication – Rely on built-in identities, service accounts, and short-lived credentials instead of static, long-term access keys. 
• Enforce Strong Authentication and Multi-Factor Authentication (MFA) – Require MFA for all privileged accounts and use conditional access policies to mitigate risk. 
• Enable IAM Logging and Monitoring – Use cloud-native logging tools to track IAM changes and detect anomalies. 
• Implement Just-in-Time (JIT) Access – Use built-in or third-party tools to reduce attack exposure by granting temporary access only when needed, require MFA or an approval process for enabling privileged roles. 
• Rotate Credentials Regularly – Automate credential rotation to ensure no API keys, access tokens, or passwords are left static for long periods of time. 

Exposed secrets: hiding in plain sight 

Securely managing secrets in cloud environments is a persistent challenge. While cloud service providers (CSPs) offer dedicated secrets management solutions, getting secrets into such solutions and ensuring they are ingested and used without exposure remains a difficult practice. Poor handling of credentials, API keys, and tokens can often lead to significant security breaches. 

We frequently discover secrets and sensitive information exposed in various locations, including storage services, environment variables, virtual machine user-data, Infrastructure-as-Code and misconfigured repositories. Hardcoded credentials, API keys, and improperly secured access tokens create unnecessary attack paths that adversaries can easily exploit. 

Permissions issues in AWS 

During an AWS assessment, we discovered an insecure S3 bucket containing Terraform state files that exposed credentials for an automated GitHub application. The bucket’s overly permissive access controls allowed us to retrieve the state file and extract these secrets. 

These credentials allowed us to authenticate to a private GitHub repository, where we found additional stored secrets—including credentials for a privileged Azure service principal. With access to Azure, we were able to interact with cloud resources and retrieve additional secrets from Azure Key Vault. These secrets included AWS access keys which provided administrator access to an additional AWS account.  

The series of compromises across multiple cloud platforms shows how exposed secrets can lead to widespread, cascading security failures. Even when cloud accounts are isolated by design, poor secrets management can bridge the gap between environments, turning a minor oversight into a full-scale breach. 

Common issues 

• Secrets Stored in Unprotected Locations – Credentials, API keys, and tokens are often found in cloud storage, code repositories, configuration files, and environment variables, where they can be easily accessed by attackers. 
• Long-Lived Static Credentials – Hardcoded secrets or long-term API keys increase the attack window, making it easier for attackers to exploit them. 
• Weak or Non-existent Access Controls – Improperly configured permissions on storage services, logs, and infrastructure can inadvertently expose secrets to unauthorised users. 

Quick wins  

• Use Cloud-Native Secrets Management Solutions – Leverage AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager to store and manage secrets securely. 
• Implement Dynamic Secret Generation – Use cloud-native or third-party services to generate secrets on demand and automatically revoke them after use. 
• Inject Secrets Securely at Runtime – Use service meshes, or API-based retrieval mechanisms to provide applications with secrets dynamically rather than statically storing them in code or configuration files. 
• Scan for Exposed Secrets Regularly – Implement automated secret scanning tools to detect leaked credentials in logs, repositories, and cloud storage. 
• Restrict Access to Secrets – Apply strict access controls and least privilege principles to secrets management services to minimize exposure. 
• Monitor and Rotate Secrets Frequently – Use automated rotation policies to limit the impact of compromised credentials. 

Weak network controls: unrestricted paths to exploitation 

Cloud environments rely heavily on software-defined networking, but weak network controls continue to be a major security gap. This issue isn’t just limited to virtual machines—databases, storage services, and other critical resources are also commonly exposed to the internet, either by default or through misconfiguration. While authentication is typically required, direct exposure increases the attack surface and allows attackers to exploit services immediately if credentials are compromised – commonly achieved on penetration tests. 

Although improvements have been made in securing inbound access, with organisations adopting bastion hosts and private endpoints, outbound and internal (inter-VPC/VNet/subnet) traffic remains widely unrestricted. This lack of egress filtering and internal segmentation enables lateral movement, making post-exploitation easier for attackers. 

An example

On one assessment, unrestricted internal network access allowed us to pivot from a compromised jumpbox to Active Directory (AD) domain controllers running on virtual machines in the cloud. With access to these systems, we could add accounts, escalate privileges, or deploy persistence mechanisms—leading to full domain compromise. 

Common issues 

• Publicly Accessible Cloud Resources – Databases, storage, and other cloud services are sometimes exposed to the internet, increasing the risk of direct exploitation. 
• Lack of Outbound Traffic Controls – Without egress restrictions, compromised workloads can communicate freely with external servers, enabling data exfiltration and command-and-control (C2) activities. 
• Unrestricted Internal Network Traffic – Poor segmentation between subnets, VNets, or VPCs allows attackers to move laterally across cloud environments, targeting sensitive systems. 
• Overly Permissive Security Groups and Firewall Rules – Default or overly broad rules often allow unintended access to critical assets. 

Quick wins 

• Restrict Public Access to Resources – Use private endpoints, VPC peering, or service networking features to limit exposure. 
• Enforce Network Segmentation – Implement least privilege network access by defining strict inter-subnet and inter-VNet policies. 
• Apply Outbound Filtering – Control egress traffic to prevent exfiltration and block unnecessary external communications. 
• Monitor and Log Network Activity – Enable VPC flow logs, Azure NSG flow logs, or GCP VPC firewall logging to detect suspicious traffic. 
• Use Just-in-Time Access for Admin Systems – Implement JIT access for jumpboxes and administrative tools to minimize the attack window. 
• Limit Lateral Movement – Use micro-segmentation and resource-based network controls to prevent attackers from moving freely between cloud workloads. 

Vulnerable DevOps configurations: remote code execution as a service 

When implemented effectively, DevOps can modernise cloud deployments, enabling organisations to provision infrastructure and applications rapidly, with consistency and efficiency. Beyond speed and automation, a well-secured DevOps pipeline enhances security by reducing direct user access to cloud environments, enforcing peer reviews, and applying organisation-wide security policies. 

However, DevOps platforms have become high-value targets for attackers due to the potential impact of a compromised pipeline or codebase. Many organisations rely on a single, highly privileged identity to deploy resources within an environment, granting broad access to streamline deployments. This means that if an attacker compromises a pipeline, build agent, or deployment identity, they can gain extensive control, often leading to full cloud compromise. 

Weak DevOps configurations to full compromise

During one assessment, a shared identity between development and production allowed us to hijack a development pipeline and deploy directly to production Kubernetes clusters. By modifying environment variables, we redirected deployments to use the production build agents and identity gaining remote code execution (RCE) on the Kubernetes runner. This provided highly privileged access to the production cluster and broader cloud environment. 

With control over the production build agent, we also gained network access to the production data plane, allowing further interaction with sensitive workloads. This case highlights how weak DevOps configurations can quickly escalate into full production compromise, making them a prime target for attackers. 

Default configurations 

Let’s get this one out of the way first. Default configurations are still a widespread issue coming in all shapes and sizes. The ongoing prevalence of this issue highlights the importance of the shared responsibility model, as cloud providers offer infrastructure with certain controls, but expect admins and DevOps teams to harden these configurations themselves. Unfortunately, many organisations leave these default settings untouched, assuming they are secure out of the box – which can have serious implications. 

Default configurations cover a broad spectrum of security issues which could take up a blog of its own, but most commonly include: 

• Services directly connected to the internet. 
• Unrestricted or widespread internal communication, enabling lateral movement. 
• Unencrypted resources. 
• Lack of defence-in-depth, where multiple layers of security are absent, leaving resources inadequately protected. 

Deploying cloud services in a default state can be likened to a developer deploying third-party code without first reviewing the code for weaknesses or further hardening. Just as code reviews and security scans are crucial for application source code, the same attention is required for cloud infrastructure.  

Provisioning cloud resources via Infrastructure as Code (IaC), enables teams to implement a ‘shift left’ security model (DevSecOps) to ensure security hardening is integrated from the start. Peer reviewing configuration parameters and employing security scanning tools within pipelines can help identify weaknesses early in the deployment process, preventing many of these issues from making it into production. 

Conclusion 

Across our cloud tests, the same problems come up again and again. Weak identity controls, exposed secrets, and overly open networks make it far too easy for small mistakes to turn into big security gaps. 

Most of these issues aren’t advanced exploits, they are from how fast environments grow and how easy it is for secure setups to drift over time. 

Good cloud security comes down to doing the basics well, like keeping visibility over what’s deployed, limiting who can do what and baking security into build and deployment from the start. Get those things right, and most of the hard problems take care of themselves.