MITRE ATT&CK T1578 Modify Cloud Compute Infrastructure: Detecting Rogue Instances, Snapshots and Quota Changes

An attacker holding a cloud identity with compute permissions does not need to break into your existing servers: they can snapshot a disk, launch a fresh instance under their own rules, mount the copy and delete the evidence afterwards. MITRE ATT&CK T1578 Modify Cloud Compute Infrastructure covers the creation, deletion or modification of instances, virtual machines, snapshots and compute settings to evade defences. In ATT&CK v20 it sits in the Defense Impairment tactic (TA0112), applies to IaaS, and has five sub-techniques. Every step is a control-plane API call made by a cloud identity, usually a role, access key or service principal, so the technique is visible in audit logs if you know which calls to watch. This guide covers each sub-technique, the events and sequences that reveal it, preventive guardrails, and how to respond without losing forensic evidence. It is for cloud security, detection engineering and incident response teams. For the wider tactic see the ATT&CK Stealth and Defense Impairment Tactics Guide.

Key takeaways

• It is an identity problem first. Every T1578 action is an authorised API call; the question is always which identity made it and whether it ever should.
• Sequences matter more than single events. ATT&CK's v20 detection strategies all rest on chains: snapshot then volume then new instance, or create then delete within minutes.
• Snapshots bypass your network controls. A copy of a production disk attached to an attacker-launched instance with an open security group escapes every control on the original host.
• Quota and configuration changes are early warnings. Quota increase requests, VM size policy changes and newly enabled regions usually come before mass resource creation for cryptomining.
• Preserve before you delete. Deletion and revert sub-techniques destroy evidence, so retention rules, delete protection and log immutability need to be in place before an incident, not during one.

How the technique works

ATT&CK describes T1578 as modifying a cloud account's compute service infrastructure to evade defences, and notes that permissions gained from new components can bypass restrictions that protect existing infrastructure. The five v20 sub-techniques:

The technique rarely stands alone. A typical chain starts with stolen cloud credentials (T1078.004 Cloud Accounts), then discovery of what can be launched (T1580 Cloud Infrastructure Discovery), then T1578, and ends in data theft from a mounted disk (T1005, T1074.002 Remote Data Staging), cross-account sharing of the snapshot (T1537) or mining (T1496.001 Compute Hijacking). Moving resources into an unwatched region is the related T1535 Unused/Unsupported Cloud Regions technique.

Where it shows up

• Cryptomining at scale: in the AWS crypto-mining campaign of 2025, AWS reported the attacker calling GetServiceQuota, testing RunInstances with the DryRun flag, creating two launch templates and 14 Auto Scaling groups, and setting disableApiTermination to true through ModifyInstanceAttribute so victims had to re-enable termination before cleaning up. Miners were running within 10 minutes of access.
• App identities launching VMs: in the Storm-1283 OAuth apps abuse, Microsoft describes a compromised account granting a new Entra ID application Contributor on a subscription, then deploying mining VMs through application identities and naming them in the pattern [DOMAINNAME]_[ZONENAME]_[1-9] to look routine. Victims incurred compute fees from 10,000 to 1.5 million USD.
• Lateral movement and collection: CISA's November 2023 Scattered Spider advisory maps the group's creation of cloud instances to T1578.002 and says it moves to both existing and actor-created Amazon EC2 instances for lateral movement and data collection. See the Scattered Spider Threat Actor Profile.
• Destruction to force a crisis: ATT&CK records LAPSUS$ creating virtual machines after gaining cloud credentials and deleting cloud systems and resources to trigger the victim's crisis response, and Storm-0501 mass-deleting Azure data stores and resources. See the Lapsus$ Threat Actor Profile.
• Testing tools: ATT&CK notes that the open-source AWS exploitation framework Pacu can create EBS and RDS snapshots, so authorised red team exercises will exercise the same events. Agree a tagging convention with testers so detections can be validated without being muted.

Detection

ATT&CK v20 gives T1578 a parent detection strategy (DET0308) and one per sub-technique (DET0423, DET0449, DET0084, DET0337, DET0492). They share a theme: alert on compute changes made outside change windows, by rarely used or new identities, from unusual locations or API clients, and in suspicious sequences. Turn that into rules:

• Managed detections: AWS lists GuardDuty findings that fired in its 2025 campaign, including AttackSequence:EC2/CompromisedInstanceGroup, CryptoCurrency:EC2/BitcoinTool.B, Impact:Runtime/CryptoMinerExecuted and anomalous IAM behaviour findings. Microsoft Defender for Cloud names alerts such as "Suspicious creation of compute resources detected" and "Suspicious Azure role assignment detected". See the Amazon GuardDuty Guide.
• Logging prerequisites: management events in a multi-region trail delivered to a separate log account, Azure activity logs exported beyond the default retention, and GCP Admin Activity audit logs routed to a protected sink. See the AWS CloudTrail Guide.
• Baselines: build a per-identity profile of which compute APIs each role and service principal calls. Infrastructure as code pipelines and backup services should be the only callers of most of these APIs; everything else is an exception worth reviewing. See the Detection Engineering for Non-Human Identities Guide.

Metrics

• Compute-mutating identities: count of principals allowed to create, delete or snapshot compute resources, trending down.
• Out-of-pipeline changes: percentage of RunInstances, snapshot and delete calls not made by approved automation, per week.
• Chain alert latency: minutes from the last event of a snapshot-mount-launch chain to an analyst acknowledgement.
• Protected deletion coverage: share of production accounts with snapshot retention rules and delete protection enabled.
• Quota headroom: unused quota for GPU and large instance families in subscriptions that do not use them, which Microsoft advises keeping low.

Prevention and hardening

• Least privilege on compute APIs (M1018): ATT&CK's mitigation is to limit permissions for creating, deleting and altering compute components and reduce standing privileged role assignments. Remove ec2:CreateSnapshot, ec2:RunInstances, ec2:TerminateInstances and Azure Virtual Machine Contributor from roles that do not need them, and grant compute administration just in time. See the Cloud PAM and CIEM Guide.
• Audit entitlements (M1047): routinely review who can create instances, snapshots and quota requests; ATT&CK lists this audit as the second mitigation for every sub-technique.
• Organisation guardrails: service control policies that deny compute creation outside approved regions and instance families, and that deny ModifyInstanceAttribute for termination settings except to the pipeline role. See the AWS Organizations and SCPs Guide.
• Size and location policy in Azure: the built-in policy "Allowed virtual machine size SKUs" (definition cccc23c7-8427-4f53-ad12-b6a63eb452b3) limits which VM sizes can be deployed, and Microsoft recommends reducing unused quota. See the Azure Policy and Management Groups Guide.
• Protect snapshots and images from deletion: Amazon EBS Recycle Bin keeps deleted EBS volumes, snapshots and EBS-backed AMIs for a retention period and supports locking retention rules; Azure resource locks and immutable backup vaults serve the same purpose.
• Encrypt with customer managed keys: a snapshot copied or mounted by an attacker-launched instance still needs key access, which is a separate permission you can restrict and alert on. See the Cryptographic Key Management Guide.
• Short-lived credentials: AWS advises temporary credentials rather than long-term access keys, MFA, and least privilege after its 2025 campaign. See the AWS Access Keys Security Guide.

Choosing controls by situation

Phased rollout

1. Inventory callers: from 90 days of logs, list every identity that called snapshot, launch, delete, revert or quota APIs, and confirm an owner for each.
2. Deploy chain alerts in monitor mode: start with snapshot-mount-launch and DryRun probes; tune exceptions for backup tools for two weeks.
3. Remove unused permissions: strip compute-mutating actions from identities that did not use them, in a pilot account first; rollback is reattaching the previous policy version.
4. Apply guardrails: attach SCPs or Azure Policy to a test organisational unit or management group, watch for denied calls, then expand.
5. Enable deletion protection: create retention rules and resource locks for production snapshots and images.
6. Exercise: in an authorised test, snapshot a test volume, mount it on a new instance and terminate it, then confirm each alert fired and the evidence survived.

Response without losing evidence

• Contain the identity first: disable or revoke the access key, role session or application secret before touching the resources, or the attacker can recreate them. The Cloud Access Key Leak Playbook covers the steps.
• Capture before you terminate: snapshot the attacker's instance volumes and record instance metadata, security groups and attached roles before deletion; the Cloud Forensics Guide covers acquisition.
• Check for anti-cleanup: look for termination protection, scale-out groups and launch templates that will recreate instances, and remove them in order.
• Look for the persistence around it: in the AWS 2025 campaign the attacker also created a public Lambda function URL and an IAM user with access keys; in Storm-1283 credentials were added to existing applications (T1098.001 Additional Cloud Credentials).
• Review snapshot sharing: confirm no snapshot or image created during the window was shared outside the organisation. See the Cloud Incident Response Guide.

Where identity fits

T1578 is carried out by non-human identities more often than people: CI/CD roles with broad EC2 rights, leaked access keys, Terraform service principals with Contributor at subscription scope, and OAuth applications granted Azure roles. Those identities are also what defenders whitelist in detections, so an attacker who steals one inherits both the permission and the exemption. Scope pipeline identities to the accounts and resource types they deploy, bind them to workload federation rather than static keys, and alert when they act from outside their usual runner. See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.

Common failure patterns

• Allow-listing automation by name: excluding the deployment role from compute alerts means stolen pipeline credentials go unseen.
• Single-event rules: alerting on every CreateSnapshot drowns analysts in backup noise; rules need the sequence and the caller context.
• Generous unused quota: high GPU quotas in subscriptions that never use them hand miners ready capacity, as the Storm-1283 costs show.
• Deleting before capturing: terminating attacker instances in the first minutes of response destroys the only copy of their tooling and data staging.
• Region-scoped controls: retention rules, detectors and policies configured only in the main region leave the rest open; see the T1535 guide.

Framework mapping

Practitioner checklist

• List every identity able to snapshot, launch, delete or revert compute resources, with an owner for each.
• Alert on snapshot then volume then instance chains by the same principal.
• Alert on DryRun probes and quota increase requests where they are not normal.
• Alert on termination protection changes and new instances with open SSH or RDP.
• Restrict compute-mutating APIs to pipeline roles through SCPs or Azure Policy.
• Reduce unused quota, especially GPU families, and restrict VM sizes by policy.
• Enable snapshot and image retention rules and resource locks in every region used.
• Replace static keys for deployment identities with short-lived federated credentials.
• Capture volumes and metadata before terminating attacker-created instances.

Standards and references

• MITRE ATT&CK: Modify Cloud Compute Infrastructure (T1578)
• MITRE ATT&CK: Create Cloud Instance (T1578.002)
• AWS Security Blog: Cryptomining campaign targeting Amazon EC2 and Amazon ECS
• Microsoft Security Blog: Threat actors misuse OAuth applications to automate financially driven attacks
• CISA: Scattered Spider advisory AA23-320A
• AWS: Recycle Bin for Amazon EBS
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: ATT&CK Stealth and Defense Impairment Tactics Guide · MITRE ATT&CK T1535 Unused/Unsupported Cloud Regions · Cryptojacking Guide · Cloud Incident Response Guide · T1537 Transfer Data to Cloud Account Defensive Guide