SECNORA® is a CREST Accredited cyber security focused consulting firm with expertise in Information Security and Governance, Risk, Compliance.
Cloud red teaming has evolved beyond identifying misconfigurations to validating how modern attackers exploit identities, automation and cloud-native services. For years, an open storage bucket or an exposed management port counted as the worst thing a cloud audit could find. Misconfigurations remain important but they are no longer the whole story. Basic misconfigurations still cause breaches, but the attackers who matter most in 2026 are studying the architecture of the cloud itself and working out which identity, pipeline or API can get them where they want to go.
This is the gap that cloud red teaming exists to close. It validates whether detection and response can actually hold up against a goal-oriented adversary who chains together small weaknesses into a high-impact outcome, rather than confirming that a checklist of controls exists on paper.
The two terms get used interchangeably but the scope is different.
Cloud Penetration Testing works against a defined boundary, a named set of assets, a fixed testing window and a report of individual vulnerabilities ranked by severity. It answers a narrower question, whether specific systems have exploitable flaws.
Cloud Red Teaming works against an objective instead of an asset list. The engagement mimics a real adversary trying to reach a specific outcome, such as exfiltrating a production database or gaining administrative control of a subscription and measures whether the organisation’s detection and response capability notices along the way.
Both disciplines earn their place in a mature security programme. An environment with unpatched vulnerabilities still needs a penetration test. An environment that has already passed its vulnerability scans needs something that tests what a scanner cannot see, identity trust relationships, detection coverage and the human response behind them.
Misconfiguration hasn’t disappeared as a risk, it is being compounded by identity risk rather than replaced by it. According to the Cloud Security Alliance’s Top Threats to Cloud Computing 2024 report, misconfiguration and inadequate change control remain the leading cloud security concern with identity and access management ranking close behind.
In practice, these risks rarely exist in isolation. A seemingly minor configuration error such as an over-permissive AWS IAM role, Azure Managed Identity or GCP Service Account, combined with a broad trust relationship or workload identity federation, can provide the initial foothold for an attacker. From there, attackers typically target identities, temporary credentials, tokens and privileges, including cloud-issued credentials such as AWS Security Token Service (STS) tokens, to move laterally, escalate privileges and access high-value cloud resources.
That progression, a misconfigured entry point followed by identity abuse, is exactly what separates a cloud red team engagement from a routine vulnerability scan. Automated scanners are effective at identifying exposed resources and configuration issues but they cannot demonstrate how those weaknesses can be chained together into a realistic attack path. Cloud red teams validate that progression, showing not just where the weakness exists, but how an attacker could exploit it to achieve meaningful business impact.
A useful cloud red team engagement doesn’t improvise its way through an environment. It follows a chain of tactics that mirrors how documented cloud intrusions actually unfold, mapped against MITRE’s ATT&CK framework which catalogues cloud-specific techniques across AWS, Azure, Google Cloud and connected SaaS platforms.
Testing each stage in isolation misses the point. The value of cloud red teaming comes from proving whether the whole chain, start to finish, gets detected anywhere along the way, not just at the point of initial access.
When an adversary lands inside a cloud environment, the network is rarely the next target. The identity layer is.
A compromised low-privilege account is only a foothold. A competent cloud red team spends most of its effort hunting for overly permissive roles and trust relationships that let that foothold expand. An internal function or workload might have permission to assume a role in a different account and if that role carries a broad trust policy, an attacker can hop across accounts and, in some cases, edit its own permissions along the way, all without ever touching a flagged user account.
The pattern isn’t unique to the cloud. Our breakdown of Active Directory Certificate Services abuse paths shows the same dynamic on-premises, where a single misconfigured certificate template hands out domain-level privilege escalation the same way an over-permissive IAM role does in a cloud tenant.
Service accounts, workload identities and automation tokens now outnumber human users in most cloud estates and they’re rarely reviewed with the same discipline as a human login. A cloud red team engagement should treat these non-human identities as first-class targets. A forgotten service principal with standing access is often a quieter route to privilege than a targeted phishing campaign against an employee.
Few cloud environments run in isolation. Most rely on a web of SaaS integrations, third-party APIs, and OAuth token exchanges that were set up for convenience and rarely revisited afterward. A red team assessment worth its cost tests these hybrid identity paths directly, looking for token abuse or authentication weaknesses that let an attacker pivot from a connected third-party service into the core environment.
The control plane is where the real power sits. An adversary who compromises it can alter logging, erase evidence and spin up resources that never show up on a standard asset inventory, which is why cloud red teaming treats the control plane as a primary target rather than an afterthought.
One well-documented technique targets the instance metadata service on cloud compute instances. A server-side request forgery flaw in a public-facing application can be used to query the metadata endpoint and extract temporary IAM credentials, sometimes with administrator-level access attached if the instance role was scoped too broadly. The NSA and CISA issued a joint advisory in March 2024 highlighting the growing exploitation of SSRF in cloud environments, recommending organisations enforce the newer, session-token-based version of the instance metadata service to close this path. A cloud red team engagement should confirm that control is actually enforced across every account, not just documented in a standard.
An attacker who invokes a legitimate serverless function that already has read access to a sensitive data store doesn’t need custom malware to move it elsewhere. Endpoint-based tools have limited visibility into activity that looks like ordinary platform behaviour, the same blind spot fileless techniques rely on at the endpoint layer.
Modern CI/CD environments increasingly rely on OIDC federation to authenticate workloads without long-lived secrets, making the secure configuration of trust relationships just as important as protecting pipeline credentials. During reconnaissance, cloud red teams routinely search source repositories and pipeline configuration for hardcoded access keys, leaked Terraform state files and forgotten environment variables. Archived state files in particular tend to contain plaintext secrets and database connection strings that were never meant to leave a developer’s laptop.
A joint NSA and CISA advisory on the most common cybersecurity misconfigurations found in large organisations, based on the agencies’ own red and blue team assessments, singled out improper separation of user and administrator privilege as one of the systemic weaknesses that shows up repeatedly, even in organisations with otherwise mature security postures. That finding maps directly onto CI/CD risk, a pipeline that runs with standing administrative access to production is one injected pull request away from becoming attacker infrastructure.
As organisations integrate large language models (LLMs) and AI agents into cloud operations, the orchestration layer itself becomes another part of the attack surface that cloud red teams must evaluate. An AI-connected tool operating with privileged workload identities and broad cloud permissions can be manipulated into leaking internal data or bypassing controls that would otherwise stop a human operator.
Cloud red teaming programmes are increasingly extending their scope to assess these AI-connected workflows, validating whether an agent’s credentials, memory or logs can be abused in the same way as a compromised service account. This is particularly relevant for AI agent runtimes, where credentials, memory and execution traces require dedicated security controls, as explored in our blog, Securing the Agentic Runtime: How Credentials Leak from AI Memory, Logs and Traces.
Consistent methodology, not any single tool, is what makes a cloud red team engagement repeatable and defensible. Most mature programmes lean on a small set of reference points rather than an ad-hoc toolkit:
The output that matters isn’t a vulnerability count. It’s proof, tied to a named framework, of which attack paths were exploitable and whether they were detected.
Cloud environments evolve too quickly for an annual engagement to provide lasting assurance. New workloads, identities, third-party integrations and infrastructure changes are introduced continuously, creating attack paths that may not have existed when the previous assessment was performed. As a result, many organisations are moving beyond point-in-time exercises toward continuous security validation that assesses live cloud environments as they evolve.
As a baseline, cloud red teaming should be conducted following every architectural change, major cloud migrations or the deployment of critical applications and services. Organisations operating mature DevOps and CI/CD environments should integrate continuous attack path validation into their security programme to keep pace with rapid infrastructure changes.
Rather than treating cloud red teaming as a periodic compliance exercise, security leaders should view it as an ongoing capability that validates whether preventive controls, governance of cloud-native identities and detection mechanisms remain effective against realistic attacker behaviour. This approach enables organisations to identify emerging risks earlier and strengthen resilience as their cloud environment continues to grow.
Cloud security extends beyond firewalls and open ports. It’s now a question of trust boundaries, identity sprawl and the automation pipelines that stitch an environment together. A cloud red team engagement that only checks for misconfigurations is answering a narrower question than the one that actually matters, can this environment withstand an adversary who moves the way real attackers move, through identity, through the control plane, through the pipeline and through the AI tools now sitting inside all three.
SECNORA provides cloud security assessment, testing and advisory across major cloud platforms, helping organisations secure their cloud environments and get shared responsibility right. Talk to our team.
SECNORA® is a CREST Accredited cyber security focused consulting firm with expertise in Information Security and Governance, Risk, Compliance.
Copyright @ 2026 SECNORA®