---
{
  "title": "Modify Cloud Compute Infrastructure",
  "summary": "Cloud compute modification changes infrastructure to enable access or reduce visibility.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1578"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1578: Modify Cloud Compute Infrastructure",
      "url": "https://attack.mitre.org/techniques/T1578"
    }
  ],
  "editorialVersion": 2
}
---

## Infrastructure changes can alter the evidence and access

Modification of cloud compute infrastructure creates, deletes, reverts, or changes resources such as instances and snapshots. Legitimate operations use these actions constantly. In an intrusion, the same capabilities can bypass restrictions, change the environment available to an actor, or remove evidence of earlier activity.

The investigation should identify the exact resource action and result. A snapshot request, a new instance, and deletion of an existing workload are different events with different implications. Avoid collapsing every unexpected cloud change into a generic compromise claim.

## A snapshot is followed by a new instance

In a fictional academy, an infrequently used role creates a snapshot and launches a new instance outside the normal deployment workflow. The analyst reviews management audit events, resource identifiers, role assumption context, configuration, and available workload activity.

A disaster-recovery test might explain the sequence. The team checks the approved exercise, participating accounts, intended regions, and resource scope. A legitimate snapshot operation does not automatically authorize access to all data represented by the resulting resource.

The investigator determines whether the requests completed and which resources actually existed. API acceptance, provisioning completion, attachment of storage, and subsequent access are separate evidence stages.

## Preserve resource history promptly

Cloud resources can be deleted or replaced quickly. Keep relevant configuration, identifiers, audit records, and authorized evidence exports before routine cleanup removes useful context. A later instance with a similar display name may be a different resource.

[[cloud-audit-logs]] explains management-event coverage. Data access and workload behavior may require separate sources. If a deleted instance's local records were not preserved elsewhere, document the resulting limitation rather than implying complete reconstruction.

Review the authority that performed the changes and other resources it could affect. [[least-privilege]] helps evaluate whether broad infrastructure permissions were necessary, but the incident scope should still follow evidence.

## Restrict changes without impairing recovery

Contain the abused identity or role as justified and coordinate resource actions with operations. Deleting an unfamiliar instance immediately may remove evidence or disrupt an approved recovery task; leaving harmful activity running also has consequences. Record the decision and expected effect.

Recovery should address the original access path and review artifacts or credentials exposed through the modified resources. Removing one instance does not necessarily remove snapshots, images, or additional access created during the case.

For practice, compare an approved recovery exercise with an unexplained snapshot-to-instance sequence. Identify approval, identity, resource-state, and access evidence. [[cloud-incident-response]] coordinates the investigation, while [[incident-reporting]] separates configuration changes from confirmed data use.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[incident-response]]