Persistence Mechanisms in Compromised Cloud Environments

Cloud persistence hides in legitimate access as well as malicious software. Valid accounts, service principals, federation settings, and long-lived tokens can keep attackers inside after the breach that first let them in is closed. Understanding those mechanisms is the first step toward a cloud environment that can actually be cleared after a compromise. The goal is durable revocation.

Why cloud persistence is a different problem from ordinary account compromise

Disabling the breached account and patching the vulnerability can stop the original route in. Either step can leave in place access that an attacker set up afterward. In a cloud environment, that access may sit in permissions and trust relationships.

This makes cloud persistence a control-plane problem involving the governance of identities, permissions, and resources. The platform accepts an attacker’s requests because an access relationship still authorizes them. Application registrations, service accounts, access keys, and OAuth permissions are ordinary administrative tools, so their presence alone does not reveal abuse. A responder looking mainly for malicious files is looking at only part of the environment.

Google Cloud Threat Horizons H1 2026 found that identity compromise underpinned 83% of cloud compromises. That puts identity at the center of incident response, but identifying the breached user is not enough. The relevant scope is every access path the attacker could create, change, or retain through that identity. Persistence is what survives when the original compromise is removed.

How the attack surface shifted from hardened infrastructure to cloud ecosystem edges

Attackers have increasingly targeted the connections around hardened infrastructure. IBM X-Force 2026 describes how attackers can use OAuth grants, API tokens, and trust relationships between connected services for lateral movement. Administrative platforms that link on-premises and cloud environments spread that risk across domains. As integrations expand faster than security governance, inconsistent access controls and overly permissive roles give attackers more room to establish durable access.

The route into those relationships is also changing. Google Cloud Threat Horizons H1 2026 found that third-party software-based entry accounted for 44.5% of initial access in H2 2025, when software vulnerability exploitation overtook weak credentials for the first time. An application flaw can therefore become the handoff to the identity layer. The same report found that the window between vulnerability disclosure and active exploitation collapsed from weeks to days, leaving less time to intervene before attackers establish another route in.

Stolen credentials still matter within this shift. IBM X-Force 2026 describes how infostealer malware targets browser-stored credentials and session cookies, and how valid-account abuse remains one of the top initial access vectors in the cases it investigates. Application flaws and stolen sessions are different entry points, but both can expose the permissions needed to make access last.

The IAM persistence techniques attackers use after initial access

SSRF-to-metadata credential chains show how an application weakness becomes a cloud access problem. With a Server-Side Request Forgery vulnerability, an attacker can reach a cloud instance’s metadata service through the application. The responses it sends back can reveal IAM credentials, configuration details, and user-data scripts that hold secrets. The danger then depends on the instance role’s permissions. If that role is overly permissive, the credential chain can lead into the control plane.

Account manipulation and phantom account creation give attackers a more direct way in. An attacker with enough privilege creates another account or role assignment before the breached account is disabled. The replacement identity survives because it is separate from the one responders remove. MITRE ATT&CK maps cloud account creation as T1136.003. The hunting target is therefore not only suspicious activity by the original user, but access that user could have provisioned.

Alternate authentication material preserves access without necessarily creating another visible account. Long-lived tokens, access keys, and federated material can survive password resets. An attacker may also add a federated trust or token issuance path that bypasses the credentials being changed. Conditional access exceptions and tenant-level policy edits can keep a way back open through legitimate settings.

OAuth application abuse moves persistence into an application’s granted permissions. Attackers create malicious applications or hijack legitimate ones and trick users into granting consent. Once consent is granted, the application can issue OAuth tokens independently of the user’s credentials. The durable access sits in the application relationship, so a response focused only on the consenting user can miss it.

Compromised service principals and non-human identities create a similar separation between a person and the access used by software. A workload identity or service credential can remain active after the human operator’s account is disabled. Google Cloud Threat Horizons H1 2026 describes supply chain attacks that use LLM-assisted automation to move from a developer’s local environment toward full cloud administration access by abusing the OpenID Connect trust between a CI/CD provider and a cloud platform. Here, the trust between systems is the bridge. Human-account cleanup does not remove that bridge by itself.

Infrastructure-as-code and deployment pipeline persistence can restore access that responders have already deleted. An attacker alters automation or IaC so the next deployment recreates the malicious state. Instructions stored upstream in the deployment process stay in place when an instance is rebooted or rebuilt. Google Cloud Threat Horizons H1 2026 saw a supply chain attack in H2 2025 that used AI-assisted attempted living-off-the-land techniques along with CI/CD pipeline abuse. The important boundary is the pipeline that creates the environment.

AI-agent and editor configuration is becoming another place where attackers can keep a foothold in developer workflows. Mini Shai-Hulud, observed in May 2026, compromised npm packages and wrote a SessionStart hook into .claude/settings.json and a folder-open task into .vscode/tasks.json. Those changes re-executed the credential harvester before ordinary interaction and scanned for other repositories to infect. Such startup instructions stay in place when conversation history is cleared or model weights are replaced. The affected state includes project hooks, editor tasks, skills, plugins, and synchronized configuration.

Why defenders consistently miss these techniques during incident response

UNC1549, a threat group, maintained access to a victim environment for over two years using stolen VPN credentials and the MINIBIKE backdoor. It exfiltrated nearly a terabyte of proprietary data. The case illustrates the cost of a surviving foothold, even though its mechanisms are not exclusively IAM-based. An intrusion can remain productive long after its first visible activity.

Cloud intrusions also do not always produce an immediate demand that forces investigation. Google Cloud Threat Horizons H1 2026 found that 45% of cloud intrusions in H2 2025 led to data theft with no immediate extortion attempts, and that attackers stayed inside for long periods. A quiet environment is therefore not evidence of a cleared environment. If an attacker later returns through valid access, that continuation of the first intrusion may be mistaken for a fresh intrusion.

Host-focused playbooks have a structural limitation when access is spread across identity stores, permission graphs, orchestration layers, and connected tenants. Rapid containment can stop visible activity without finding all those relationships. Meanwhile, an identity able to mint tokens, alter policies, or provision access can widen the incident’s reach over time.

Tooling can reinforce that narrow view. Cloud posture management tools list policy violations, but those lists do not show how separate weaknesses work together to make an attack path. An SSRF and an over-permissive instance role may appear as separate findings while together enabling account takeover. Pipeline persistence can also be missed because a host that has been rebuilt can pick up the same malicious bootstrap instructions. In that case, recovery restores the compromise.

What a post-compromise environment actually looks like when persistence is active

Access that comes back is a stronger sign than files that look unfamiliar. When credentials or role assignments reappear after revocation, something that can create access is likely still running. Policy exceptions returning after removal suggest that the authority or automation behind them has survived. Scheduled tasks that recreate access paths make that restoration more explicit. Recurring downloads from the same command-and-control infrastructure confirm that a working channel remains.

For infrastructure-as-code and pipeline persistence, redeployment is a useful diagnostic test. If a redeployed instance reproduces the same malicious state, the mechanism sits in the pipeline or image. That connects the investigation directly to deployment templates, startup hooks, and automation. A rebuild is trustworthy only when its image, startup path, service definitions, and network indicators no longer reproduce the compromise.

OAuth and federation persistence is visible in administrative actions that should no longer be possible after account lockdown. API calls against connected tenants and token issuance that survives password resets point toward remaining application permissions or trust paths. These may be evidence that the earlier response revoked the wrong layer of access.

Deleted or tampered logs are a secondary signal because they show interference with visibility. Processes or services mimicking trusted names, locations, or metadata can also indicate a changed execution path. These signs widen the investigation beyond IAM without replacing the identity analysis. The practical question remains whether the observed activity depends on an access path that cleanup left behind.

How penetration testing validates whether cloud persistence paths actually exist

A misconfiguration review identifies what is configured badly. A cloud penetration test establishes what an attacker can actually do with it. That distinction matters because a policy violation does not, by itself, prove account takeover or durable persistence. Chaining weaknesses into a working exploit turns a possible relationship into a demonstrated attack path.

The SSRF-to-metadata chain makes this difference concrete. A tester can query the metadata service through the SSRF, extract credentials, and demonstrate AdministratorAccess where the exposed permissions allow it. A standard web application penetration test scope may not cover the wider cloud paths, including IAM privilege escalation, inter-service trust abuse, storage bucket exposure, and lateral movement across cloud-native services.

Pipeline persistence also changes the access a meaningful test requires. Whitebox access to source code, cloud configurations, and deployment pipelines is necessary for complete coverage of persistence embedded in the deployment process. A tester who cannot inspect that process cannot fully assess what it will recreate. Findings should be backed by working exploits rather than unverified possibilities, so the report establishes both the need for remediation and the real scope of exposure.

A cloud provider’s SOC 2 or ISO 27001 report covers the controls that the provider runs, including physical security, hypervisor isolation, and managed service availability. IAM policy, resource configuration, network exposure, application logic, and key management remain customer responsibilities. Evidence about the provider’s controls is not evidence that the customer’s access paths are safe.

Building a cloud environment that can actually be cleared after a compromise

The practical goal is an environment where every attacker-held access path can be identified and revoked. That starts with treating identity hygiene as standing work. Service principals, workload identities, OAuth grants, and long-lived tokens need the same inventory discipline as human accounts. Access that has no inventory is access responders cannot reliably revoke.

Short-lived, scoped tokens reduce the room for credentials to become durable footholds. A credential that expires in hours cannot, on its own, keep access open for months. Federation trusts and token issuance paths still need to be checked regularly because an attacker can use a relationship that survives to get fresh access after a credential expires. Credential lifetime and issuance authority are separate parts of the same problem.

Pipeline configurations, IaC templates, and deployment images belong in security reviews and incident response scope. Continuous pull-request scanning for permission changes, new role assignments, and trust modifications complements point-in-time testing by catching dangerous changes before production. That makes the source of a rebuild part of the security decision about recovery.

Forensic readiness gives responders the evidence they need to judge that recovery. Protected, centralized audit logs help distinguish a surviving foothold from a fresh intrusion and preserve the record of re-entry. Google Cloud Threat Horizons H1 2026 says the EU AI Act and updated SEC reporting mandates add pressure to be ready for forensic work in the cloud.

Remediation is complete only when the exploit no longer works. Another route through the same permission chain may still preserve access. On-demand retesting by the same tester who found the original issue closes the gap between an assumed fix and a demonstrated one. The test-remediate-retest loop gives engineering leaders a concrete standard for a cleared environment, namely evidence that the attacker’s path has been closed.