Modify Cloud Compute Infrastructure (T1578) is a technique in the defense impairment tactic, scoped to IaaS. The adversary changes a cloud account's compute service infrastructure to evade defenses. That can mean creating, deleting or modifying compute instances, virtual machines and snapshots.
MITRE gives two reasons this helps an attacker. Permissions gained by modifying infrastructure may bypass restrictions that block access to existing resources. And modifying components may let the adversary evade detection and remove evidence that they were there.
How attackers use it
T1578 has five sub-techniques, each with its own post in this series:
- Create Snapshot (T1578.001): copy a volume or VM at a point in time.
- Create Cloud Instance (T1578.002): start a new VM inside the account.
- Delete Cloud Instance (T1578.003): remove an instance and the evidence on it.
- Revert Cloud Instance (T1578.004): roll an instance back to an earlier state.
- Modify Cloud Compute Configurations (T1578.005): change quotas, regions or tenant policy.
They chain. An adversary can snapshot a volume, create an instance, mount the snapshot there, and apply a looser network policy. The new VM sits outside the controls on the original, and later deletion removes the traces. Because these are normal cloud API calls made with valid credentials, they blend into administrative activity.
How to detect it
MITRE's analytic focuses on unauthorized or anomalous changes to compute components. The key signals:
- Creation, deletion or modification of instances, volumes and snapshots outside approved change windows
- A rapid snapshot creation followed by a new instance and a mount
- Repeated infrastructure changes by accounts that are rarely used
- Activity tied to an unusual geolocation, API client or automation script
The data source is your cloud audit log: management events for compute, plus identity context (who, from where, with which key). The question for each event is whether it matches a change you know about.
Build alerts around sequences, not single events. A snapshot alone is routine. A snapshot, a new instance and a security policy change in ten minutes from a rarely used identity is not.
How to reduce the risk
MITRE lists two mitigations.
- User account management. Limit permissions for creating, deleting and altering compute components to what each role needs. Keep the number of identities with administrative IAM roles small, work toward removing permanent privileged role assignments, and run periodic entitlement reviews on IAM users, roles and policies.
- Audit. Routinely check user permissions so only the expected identities can modify compute infrastructure.
In practice:
- Split roles so that the people who run workloads cannot also delete audit evidence or change tenant-wide policy.
- Use short-lived credentials for people and automation, and avoid long-lived access keys that can leak.
- Tag approved automation and alert on compute changes from anything else.
- Review who can create snapshots and who can share them. These permissions are often broader than anyone remembers.
Check your own environment
Read-only examples for AWS:
# AWS CLI: instances, with launch time and state
aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,LaunchTime,State.Name]' --output table
# AWS CLI: snapshots you own
aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[].[SnapshotId,StartTime,VolumeId]' --output table
# AWS CLI: recent snapshot creation events from CloudTrail
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=CreateSnapshot --max-results 20
Checklist (any provider):
- Which identities can create, delete or revert compute resources?
- Are cloud audit logs on in every account and region, and stored where an administrator of the monitored account cannot erase them?
- Do you alert on snapshot then instance then policy change sequences?
- Is there an inventory of expected instances to compare against?
- When were entitlements last reviewed?
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why are single events weak signals for this technique?
Snapshots, instance creation and deletion are routine operations. MITRE's analytics stress sequences, rarely used accounts and unusual locations or API clients.
Which two mitigations does MITRE list?
Least privilege through user account management for compute changes, and routine audit of who holds those permissions.
What does an attacker gain by mounting a snapshot on a new instance?
A copy of the data outside the restrictions and monitoring on the original instance, as MITRE describes for Create Snapshot and Create Cloud Instance.
