Modify Cloud Compute Infrastructure

Expanded Definition

Modify Cloud Compute Infrastructure refers to the abuse of legitimate cloud administration capabilities to change the state of compute assets in ways that conceal malicious activity or preserve attacker control. That can include altering virtual machine configurations, deleting or restoring instances and snapshots, changing startup scripts, adjusting security settings, or reverting systems to a prior state after detection pressure increases. The technique matters because it blends into routine cloud operations, which makes it harder to distinguish an attacker from an authorised operator.

In practice, the term sits at the intersection of cloud control-plane abuse, defence evasion, and persistence. It is narrower than general cloud compromise because the key action is not simply gaining access, but using that access to manipulate compute resources themselves. The most common misapplication is treating these actions as ordinary administration, which occurs when alerting and change control are weak or when responders assume every infrastructure change was approved.

Examples and Use Cases

Implementing cloud governance rigorously often introduces friction for administrators, requiring organisations to weigh operational agility against stronger visibility, approval, and recovery controls.

• An attacker creates a replacement virtual machine from a known-good image, migrates tooling or persistence to it, and terminates the original instance to disrupt forensics.
• After gaining cloud console access, an adversary changes startup behaviour so a workload launches attacker-controlled code on reboot, then blends the change into routine maintenance.
• A compromised account reverts a workload snapshot to restore an older configuration that weakens logging, monitoring, or endpoint protection.
• An operator account is used to modify instance metadata, security group settings, or autoscaling behaviour so malicious traffic persists while appearing like normal platform tuning.
• Security teams reviewing cloud activity through the NIST Cybersecurity Framework 2.0 often map these events to change management and asset visibility expectations rather than treating them as isolated technical anomalies.

Why It Matters for Security Teams

This technique matters because cloud compute systems are highly mutable by design, and that flexibility can erase evidence, disrupt incident response, and extend attacker dwell time if governance is weak. Security teams need to understand which changes are normal, which are approved, and which alter the integrity of investigation data. Without strong logging, role separation, and continuous configuration monitoring, a malicious change can look identical to a routine deployment or rollback.

The identity connection is direct: the technique usually depends on privileged cloud identities, automation credentials, or stolen session tokens. In NHI-heavy environments, service accounts, workload identities, and agentic tooling can all become the mechanism through which compute resources are modified at scale. Organisations typically encounter the impact only after a containment effort fails, at which point modify cloud compute infrastructure becomes operationally unavoidable to investigate and reverse.

Related resources from NHI Mgmt Group

• How should security teams govern AI cloud infrastructure differently from web apps?
• How should organisations respond when AI compute is being used as delivery infrastructure?
• How should security teams reduce cloud identity risk when credentials are stored in shared infrastructure?
• Why do privileged cloud permissions increase infrastructure hijacking risk?