The Core Anatomy of Modern Cloud Threats
Cybersecurity Awareness Month is built on the principle of understanding where your real exposure lies. In cloud-native and hybrid environments, that exposure rarely looks like a rogue executable running on a monitored server; it looks like legitimate automation doing catastrophic damage in plain sight. Non-human identities—spanning service accounts, CI/CD pipeline secrets, and autonomous AI agents—now dwarf human users and hold vast, ungoverned privileges across enterprise environments.
In Part 2 of our series, What Cloud Incidents Are Actually Telling Us, we break down the four dominant threat archetypes defining cloud incidents today: the sprawling machine and agentic identity crisis, CI/CD software supply chain compromises, cloud-native living-off-the-land techniques that evade traditional EDR, and the calculated destruction of backup fabrics to paralyze incident recovery.
Identity and Credential Compromise
Identity has become the primary attack surface in cloud environments, not just as an initial access mechanism, but as the means of lateral movement, privilege escalation, and persistence across the entire incident lifecycle.
The reason is structural, as noted above: compromise a sufficiently privileged identity and you don’t just gain access; you gain the ability to rewrite who can access what. This is not account takeover in the traditional sense. It is control-plane compromise: reprogramming the trust graph of the organization.
What makes this especially difficult to defend is the scale and governance gap around non-human identities. Service accounts, API keys, OAuth tokens, CI/CD credentials, and workload identities now significantly outnumber human users (recent industry research puts the ratio around 82:1 in the average enterprise, and as high as 144:1 in cloud-native and DevOps environments specifically). These identities authenticate constantly, often access sensitive systems, and in many organizations carry permissions that would trigger immediate review if a human account held them.
AI agents add a new layer to this problem rather than replacing it. Agentic workloads are typically provisioned with their own service identities and permission sets, often broader than the task requires, because scoping an agent’s access precisely is harder than scoping a human role. Like any other identity, an AI agent’s permissions can be stolen, but the more distinctive risk is that an agent operating entirely within its own legitimate permissions can be manipulated, through prompt injection, tool misuse, or chained actions, into taking actions a narrower, well-governed permission set would have blocked outright. In several documented cases, newly introduced guardrails meant to constrain agent behavior have been bypassed simply because the underlying identity still held the broader permissions the guardrail was supposed to compensate for, a restriction implemented at the application or policy layer becomes significantly less effective if the identity layer underneath was never tightened. This makes AI agents a fifth category of non-human identity that needs the same governance — discovery, ownership, least privilege, rotation — as service accounts and API keys, not a separate problem to solve later.
According to Veza’s 2026 State of Identity and Access Report, just 0.01% of non-human identities control 80% of all cloud permissions, making a small number of ungoverned machine accounts disproportionately powerful targets. The same report documents billions of active entitlements across its dataset; no team can manually reason about that volume, and the small fraction of identities holding most of the permissions are exactly the ones that should be under the tightest scrutiny and rarely are.
These accounts accumulate over years. They are created by engineers who have since moved on. They sit in configuration files and infrastructure-as-code templates. They never expire. And in most organizations, they receive essentially no governance — not because anyone is negligent, but because no governance process was ever designed to catch them.
The practical takeaway is that cloud compromises increasingly begin with the abuse of existing identities rather than sophisticated exploitation. It is far more often a forgotten service account with broad permissions that no one has reviewed since it was created eighteen months ago.
CI/CD and Software Supply Chain Compromise
The identities described above don’t only belong to people and workloads sitting still. They also move through pipelines, and that’s where this category connects directly back to identity. CI/CD systems are where non-human identity risk becomes concentrated and operational: modern application deployment depends on interconnected pipelines, including CI/CD systems, third-party actions and packages, container registries, secrets managers, and artifact repositories, and these pipelines carry some of the most privileged credentials in the environment: cloud deployment keys, container registry tokens, service account credentials with broad infrastructure permissions. In most organizations, those credentials are ungoverned, unrotated, and largely invisible for the same structural reasons described in the identity section above, applied to a part of the environment that moves faster and is reviewed less often.
Supply chain attacks exploit this concentration at scale: they target the shared dependencies that thousands of organizations use simultaneously, multiplying the impact of a single compromise. The attack doesn’t target any one organization; it targets the shared component, and every organization downstream inherits the exposure.
The tj-actions/changed-files incident of March 2025 is the clearest recent example at cloud scale. Attackers compromised a widely-used GitHub Action by gaining access to a GitHub Personal Access Token associated with a bot account in the dependency chain, then retroactively modified multiple version tags to reference a malicious commit. The compromised action dumped CI/CD runner memory to workflow logs, exposing AWS access keys, GitHub Personal Access Tokens, npm tokens, and private RSA keys. Over 23,000 repositories were potentially affected during the 15-to-24-hour window before the malicious commit was removed.
Mandiant documented a related case pattern in which a compromised npm package harvested CI/CD credentials, including an OIDC token with broad cloud permissions. The full environment was compromised within 72 hours of the initial package installation. In cases like this, the gap was rarely missing tooling — it was the absence of inventory, baselines, and clear ownership over the credentials the pipeline was carrying.
This pattern is becoming more common, not less. Unit 42 reports that SaaS supply chain attacks (abuse of OAuth tokens and API keys through third-party SaaS integrations) have increased 3.8x since 2022, accounting for 23% of all attacks in 2025. Google’s H1 2026 Cloud Threat Horizons Report found that 21% of all cloud intrusions tracked in 2025 involved the compromise of a trusted third-party relationship.
The structural problem behind all of these cases is the same: the CI/CD pipeline sits at the intersection of development and cloud infrastructure, carries production-level credentials, and is typically owned by neither the cloud team nor the security team. In most organizations, it’s genuinely difficult for any single team to maintain a complete inventory of what credentials the pipeline is carrying, where they’re stored, when they were last rotated, or what level of access they actually provide, not because the work is being skipped, but because the pipeline spans organizational boundaries that ownership models haven’t caught up with yet.
Cloud-Native Living off the Land
Living-off-the-land techniques, using legitimate, built-in tools and APIs rather than deploying custom malware aren’t new in endpoint environments. EDR itself was originally built to answer exactly this problem: traditional antivirus, which relies on signature-based detection of known malicious files, struggled badly against fileless malware and “LOLBins” (legitimate binaries like PowerShell or WMI repurposed for malicious ends), because there was no malicious file to fingerprint. EDR’s behavioral approach, watching what a process does rather than what it is, was the answer on the endpoint.
The cloud breaks that answer in a specific and underappreciated way. A cloud environment isn’t one continuous surface that a single security team controls end to end, instead it splits into infrastructure an organization actually operates (its own compute, its own containers) and SaaS or managed platform components where the underlying infrastructure security is the provider’s responsibility, not the customer’s. EDR depends on an agent running on the host to observe process behavior. That agent is rarely deployed on managed and ephemeral cloud-native compute the way it would be on a traditional endpoint, short-lived containers spin up and down in seconds, serverless functions have no persistent host to install an agent on, and managed services don’t expose the underlying compute layer at all. The result is a visibility gap that has nothing to do with EDR being ineffective and everything to do with EDR simply not being present where the activity is happening. It’s not that detection failed; it’s that nothing was installed to detect anything in the first place.
This raises the obvious follow-up question security teams should be asking themselves: where the organization does control the underlying compute, self-managed containers, in particular, why isn’t EDR routinely deployed there the way it is on traditional endpoints? In practice, the answer is rarely a deliberate decision; it’s closer to an oversight born of how container fleets get built and scaled (by platform and DevOps teams, often outside the workflows that provisioned endpoint EDR in the first place), combined with real friction — agent overhead in ephemeral environments, compatibility across container runtimes, and the fact that container-aware EDR/CWPP tooling is a newer, less mature category than endpoint EDR. None of that makes it optional; it makes it a gap worth treating as a standing investigation item, not an afterthought.
This is precisely why cloud-native living-off-the-land techniques are so effective: native automation primitives, EventBridge rules that trigger Lambda functions on a schedule, CloudFormation stacks that deploy infrastructure for persistence, storage lifecycle policies that delete logs to reduce visibility, IAM trust policies rewritten to include attacker-controlled principals can be weaponized by an attacker with sufficient permissions, and there is often no agent anywhere nearby to observe the behavior. These actions are indistinguishable from legitimate cloud operations using standard API calls with valid credentials. They leave traces only in cloud audit logs; the same logs most subject to delivery delays, most likely to be deprioritized in cost-reduction exercises, and least covered by existing detection rules.
While operating across a hybrid footprint rather than being exclusively cloud-native, Volt Typhoon’s philosophy is exactly what attackers are now replicating inside cloud management planes. CISA’s joint advisory (February 2024, with NSA, FBI, and international partners) confirmed that this PRC state-sponsored actor maintained persistence in US critical infrastructure environments for at least five years using exclusively living-off-the-land techniques: native OS tools, legitimate credentials harvested at regular intervals, and targeted log deletion to conceal activity. No malware. No custom implants. Just cloud APIs and native OS commands under valid authentication.
Where the organization does not control the underlying compute (most SaaS and fully managed services) the equivalent control isn’t an agent at all; it’s behavioral monitoring at the API and audit-log layer, because that’s the only vantage point available. That points to the real detection challenge, which is not a tooling problem so much as a baseline problem. You cannot detect unusual Lambda execution patterns without a baseline of normal Lambda behavior. You cannot identify anomalous IAM trust policy modifications without a map of what legitimate trust relationships look like. Most organizations don’t yet have these baselines, and that’s understandable. Building them requires investment that doesn’t show up on a compliance checklist and doesn’t produce an immediate, visible security outcome, which makes it easy to deprioritize even with the best intentions.
Backup and Recovery Infrastructure Targeting
While this threat is often categorized under traditional ransomware, the cloud transforms the problem entirely due to shared infrastructure and trusted control planes. Ransomware operations have evolved from simple endpoint encryption-focused attacks to the systematic denial of an organization’s recovery capability. The economics are straightforward: encrypting data creates leverage only if the target cannot restore from backup. Ransomware groups understood this and adapted.
Sophos’ State of Ransomware in Enterprise 2025 report found that in 2025, the use of backups dropped to a four-year low of 53%, down from 73% the previous year, a significant reduction in organizations’ ability to recover without paying. Veeam’s 2024 ransomware data found that 96% of ransomware attacks specifically targeted backup repositories, with 76% of those attempts succeeding in compromising backups.
The reason this has become a critical cloud-specific issue is structural architecture. Backup systems, disaster recovery infrastructure, and production workloads increasingly share the same cloud trust fabric; the same IAM system, the same network perimeter, the same management plane. A ransomware group that achieves cloud control-plane access can reach backup infrastructure through the same identity and permission paths they used to reach production. The physical separation that made traditional backup strategies effective doesn’t exist by default in cloud environments; it requires deliberate architecture.
It’s also worth naming the budget tension directly, and this is becoming a bigger constraint, not a smaller one. Properly isolated backup architecture including immutable storage, cross-account replication, independent credentials, and air-gapped copies costs meaningfully more than a single shared-account backup configuration, and that gap has been widening as cloud storage and egress pricing rise and as backup retention requirements grow alongside data volumes. This puts security and finance teams in a genuine trade-off, not a simple oversight: the cheaper backup configuration is also the one that shares the most blast radius with production. Recognizing that trade-off explicitly, rather than treating it as a default cost-cutting decision made elsewhere, is itself part of the fix.
Unit 42 reports that ransomware groups now explicitly and systematically target identity services, virtualization management planes, and backup infrastructure as primary objectives — not as secondary collateral. Encryption appeared in only 78% of extortion cases in 2025, down from above 90% in previous years. Increasingly, attackers rely on data theft and the threat of exposure as primary leverage, without needing to encrypt anything.
Understanding These Threat Types
It’s tempting to read the four threat types above as a list of failures. They are better understood as the predictable output of how cloud environments actually get built and operated across multiple teams, multiple platforms, and multiple cost pressures, none of which were designed with this specific threat model in mind.
In the final installment of our series, we will look at why these gaps persist, and provide a threat vs action matrix which helps enterprises understand what to do next.
In the meantime, learn more about how CyberProof can help you secure your cloud environment.
