How T1578 modify cloud compute infrastructure shows up in IaaS environments
For a SOC lead running an IaaS estate, cloud compute changes are routine. Instances are started, resized and replaced constantly, and most of that activity is legitimate. The hard question is how to separate a suspicious change to compute infrastructure from normal operations. T1578, Modify Cloud Compute Infrastructure, describes an adversary who alters virtual machines, their configuration or the storage attached to them, so that a workload, a recovery path or a visibility control changes without a deliberate deployment. Snapshots deserve particular attention because they are copies of disk state. Creating one can move data out of the environment, and deleting one can remove the recovery points a team relies on after an incident. Changes to instance state matter for a similar reason, since a stopped or reconfigured instance can quietly stop producing the logs defenders expect.
This page targets Enterprise ATT&CK version 20.0. T1578 has five sub-techniques. Read their names and definitions directly from the STIX bundle rather than from a summary, and do not build detections from memory. Technique and sub-technique names, mappings and telemetry references can change between ATT&CK releases, so check them against the bundle for the version your team uses. The enterprise-attack 20.0 bundle is published in the attack-stix-data repository. T1578 sits under the Defense Impairment tactic (TA0112), which covers adversary actions that weaken the security mechanisms, pipelines and tooling defenders depend on to see and trust their environment.
The first decision is to build a baseline of approved change paths before tuning any alert. Ask the cloud platform owners to list the sanctioned routes for compute changes, such as infrastructure-as-code pipelines, managed service accounts and scheduled snapshot policies, along with their change windows. Then confirm with your cloud provider which audit log categories record snapshot and instance changes, and how long those records are retained, because every detection in this topic depends on that telemetry. Finally, agree who triages a snapshot deletion or instance change that falls outside both the baseline and an approved change window, and how quickly they must respond.
Which cloud telemetry reveals T1578 on IaaS
This table maps each cloud signal linked to T1578 on IaaS to its data source, what defenders should look for, and the open-source collector or SIEM component that can ingest it. Read it as a checklist: confirm each provider audit feed is enabled, retained long enough to investigate, and parsed by your collector before you rely on any single signal.
| Signal | What to look for | Collector or SIEM component |
|---|---|---|
| Snapshot creation | Snapshot or image creation events on production volumes, especially by identities that do not normally create them or outside change windows | Wazuh cloud integration or Security Onion log ingestion of the provider audit trail, confirmed per provider module |
| Snapshot deletion | Deletion of snapshots or images that protect recovery points, particularly bulk deletions or deletions following unusual snapshot creation | Wazuh cloud integration or Security Onion log ingestion of the provider audit trail, confirmed per provider module |
| Cloud service metadata | Instance, image and volume metadata fields changed or read in patterns that differ from baseline, such as unexpected tags or ownership changes | Provider audit log ingestion into Wazuh or a SIEM, with field mapping reviewed against the provider's event schema |
| Cloud service modification | Configuration changes to compute resources, including instance type, disk, network attachment or image references made outside approved pipelines | Wazuh rules or Sigma rules applied to normalized audit events, validated in a cyber range |
| Audit trail retention | Confirm the retention period for control-plane and data-plane logs covers your investigation window and is stored outside the account it monitors | Object storage or archival tier owned by the security team, with retention settings confirmed in writing with the provider |
| Provider module coverage | Verify which event types and regions your collector ingests, since coverage can differ by provider and by service | Vendor documentation for each Wazuh or Security Onion integration, checked against your provider account setup |
Detection logic for snapshot and compute changes
These four cards describe detection ideas for T1578 Modify Cloud Compute Infrastructure on IaaS, where an adversary changes snapshots, instance state or configuration to weaken recovery and hide activity. Each idea is written as Sigma-style logic in words, and each must be tested against your own cloud audit logs before it is trusted, since backup, scaling and deployment patterns differ widely between environments.
Snapshot volume per identity
Count snapshot creation and deletion events per identity and per account over a sliding window, then alert when one principal departs sharply from its own history. Deletions are the higher-risk signal because removing recovery points can precede destructive activity. Tune the window to your backup schedule so that routine retention jobs establish a baseline rather than fire alerts. Check first whether the identity is a backup service role, a lifecycle policy or a human operator, and record the expected owner for each snapshot class.
Instance state changes outside windows
Flag stop, terminate, detach or resize events on compute instances when they occur outside approved change windows or outside the tagged deployment pipeline. The logic pairs the action type with the time of day, the calendar of change freezes and the principal that issued the call. Changes that come from a pipeline role during its scheduled run should be excluded by role and source, not by broad exemptions. Confirm which instances are production-critical so the rule weights them higher than sandbox workloads.
Metadata edits from unfamiliar sources
Alert when instance metadata, user data, tags or launch configuration change from a source address, user agent or role that has not previously modified that resource. The rule compares the source against a learned set of automation paths and administrator workstations. Autoscaling groups and infrastructure-as-code tools legitimately rewrite launch templates, so allow-list their known roles and review the diff of each change rather than the event alone. Confirm that your provider records the full request context for these edits.
Bulk changes across accounts and regions
Detect the same compute or snapshot action repeated across several accounts, subscriptions or regions within a short period, which is a pattern that manual administration rarely produces. The logic groups events by action, principal and time bucket, then escalates when the spread crosses a qualitative threshold you set with your cloud platform team. Infrastructure pipelines that roll out to many regions on purpose are the main source of noise, so match them against the deployment calendar. Confirm whether your organization's central logging captures every account in the organization.
How to validate that the T1578 detection fires
This sequence proves, in a private cyber range, that control plane changes to cloud compute resources produce the expected events, reach the SIEM with usable fields, and trigger the detection within a measured latency. It ends with a recorded baseline and a clear path for filing gaps.
Define the test scope in a non-production account
The detection owner and the cloud platform lead agree in writing which non-production account, region and IaaS resource types the test will touch, such as virtual machine instances, disks and snapshots. The scope names the T1578 sub-techniques being emulated and the ATT&CK version the detection targets, so the results can be compared across releases. The step is done when the signed scope sheet is stored with the test record and no production account appears in it.
Agree expected events with the cloud platform team
Before any change is made, the detection engineer and the cloud platform team list the audit events each planned action should generate, including the event name, the actor identity, the resource identifier and the source address fields. They also agree which fields the Snapshot Deletion, Snapshot Creation and Cloud Service Metadata telemetry should carry in the provider's logs. The output is a expected-events table that the test will be scored against. Ask the provider for the exact log schema for your service, since field names differ by platform.
Run planned control plane changes in a controlled window
During an agreed window, a named operator performs the planned changes in the test account, such as creating and deleting snapshots and modifying instance metadata, using the same identity type a real attacker would be expected to hold in your environment. Each action is logged with a timestamp in the run sheet, and the operator records the time the change was submitted. The step is done when every planned action has a start time, an end time and an outcome in the run sheet.
Confirm events arrive at the SIEM
The SIEM engineer checks that each expected event from the provider's audit trail reached the collector, was parsed, and is searchable in the SIEM index. Gaps between the run sheet and the indexed events are recorded as ingestion issues, separate from rule issues. The step is complete when every expected event is present or each missing one has a logged reason, such as a collector outage or a dropped log stream.
Check the rule fires with the expected fields
The detection engineer runs the detection rule against the test events and confirms that it produces an alert for each action it is designed to catch. The engineer also checks that the alert carries the actor, resource, action and source fields the triage team needs, and that no alert fires for the benign control actions included in the run. The output is a match table with each planned action marked as detected, missed or noisy.
Record detection latency and gaps
For each detected action, the engineer calculates the time between the operator's submitted change and the alert appearing in the case queue, then notes the difference between submission, ingestion and alerting. Any action that did not alert, or alerted without key fields, is written up as a gap with the rule ID, the ATT&CK version and the data component involved. The step is done when latency values and gap entries are saved in the test record.
File a finding when a rule does not fire
When a planned action does not produce the expected alert, the engineer opens a finding in the team's tracker with the run ID, the expected events, the observed events, the rule version and the reproduction steps described in words. The finding is assigned to the detection owner, and the rule is retested after the fix in the same test account. The output is a closed finding with a retest result attached, or an accepted risk signed by the security lead.
Store the run record for each test
Each run is archived with the scope sheet, expected-events table, run sheet, match table, latency values, gap entries and any findings, so a later run can be compared against it. The record also notes the rule version, the SIEM version, the cloud provider's log schema version and the ATT&CK version used. The step is complete when the record is saved to the team's repository and linked from the detection's tracking entry.
Tuning snapshot and compute rules without blinding the SOC
The central tuning problem for T1578 is that legitimate backup, patching and autoscaling pipelines produce the same snapshot and compute events as misuse. A backup service snapshotting volumes, a patch tool replacing instances from a golden image, and an autoscaling group launching and terminating hosts can each look like an attacker creating or deleting resources at scale. Suppressing those events is necessary, but the way the suppression is written determines whether the SOC keeps any visibility into the activity it was meant to watch. Start by inventorying every automated actor that calls snapshot and compute APIs in each cloud account, and record the identity, the pipeline or tool that owns it, and the resource scope it touches. Confirm these with the platform and backup owners in your own environment rather than assuming them from naming conventions.
Write allowlists against service identity and pipeline, not against broad accounts. An exception that says "ignore all activity from the platform engineering role" removes every human misuse path that role can reach. A better rule matches a specific workload identity, a source network or CI runner, the specific API actions it needs, and the resource tags or accounts it is permitted to touch. For example, an illustrative rule might permit snapshot creation by a named backup role only for volumes tagged with its backup policy, and still alert on snapshot sharing or cross-account copy by that same role. Review exceptions on a fixed schedule set by your change process, remove any whose owning pipeline no longer exists, and keep a written record for each suppression that names the owner, the justification, the approval, the date it was added and the date it must be reviewed. Confirm with your cloud provider's audit log documentation which fields are available for these keys in your environment.
Over-suppression is itself a form of defense impairment. When a noisy rule is silenced rather than narrowed, the detection stops working for the adversary behaviors it was built for, and the SOC may not notice because the dashboard looks healthy. Treat the suppression list as a monitored control: periodically sample the events that were suppressed, compare their volume and resource targets with what the owning pipeline is documented to do, and alert when a suppressed identity starts acting outside its documented pattern. Ask your managed or internal SOC to show how suppressed events are still retained and searchable, because a suppression that also deletes the telemetry removes the evidence needed for investigation. Record the outcome of each periodic review so auditors and leadership can see that exceptions are challenged over time, not accumulated.
Preventive controls that make T1578 harder to hide
T1578 changes compute and snapshot state, so the most useful preventive work happens before an incident: complete audit logging and tight control over who can alter instances, images and snapshots. The cards below cover the two ATT&CK mitigations that map to this technique and the change process that keeps both honest.
Keep audit logging on everywhere
Audit (M1047) is the mitigation that makes T1578 visible at all. For IaaS compute, confirm that the provider's control plane logging is enabled in every account, subscription or project, and in every region where workloads run, including regions nobody expects to use. Check that logs for instance, image and snapshot API calls are written to storage that the workload accounts cannot edit or delete. Ask your cloud provider which compute and snapshot events are recorded by default and which need explicit configuration.
Limit who can change compute state
User Account Management (M1018) covers how accounts are created, scoped and removed. For T1578, the question is which identities can create, modify, stop, resize or delete instances, images and snapshots. Review role assignments for these actions, separate snapshot deletion rights from snapshot creation rights where the provider allows it, and remove standing administrative access that automation no longer needs. Review dormant service accounts, since they are a common path to unexpected compute changes.
Protect snapshots and images
Snapshots and machine images can be used to copy or replace workloads, so their permissions deserve the same scrutiny as the instances they come from. Confirm that snapshot sharing to other accounts or projects is restricted and monitored, and that retention or deletion of backup snapshots requires a separate, approved identity. Verify whether your provider supports deletion protection or locks on snapshots and images, and test that these settings hold under the roles your teams actually use.
Require change records for compute policy
Compute and snapshot policies, such as backup schedules, retention rules, tagging standards and allowed instance images, should change only through a tracked change process. Require a ticket, a named approver and a peer review for edits to these policies, and alert when a policy changes outside that path. Compare the live configuration against the approved baseline on a regular schedule. Ask your provider which policy settings can be exported and versioned, because drift is hard to spot without a recorded baseline.
Confirm controls against provider documentation
The exact logging defaults, permission names, retention behavior and snapshot protections differ between IaaS providers and change over time. Before relying on any control above, check the current documentation of your own cloud provider and record the setting, owner and evidence for each one. Treat the vendor's documentation as the authority for your environment, and use it to confirm which events your Audit configuration captures for T1578 activity.
Triage and response when a T1578 alert fires
When a T1578 alert fires, the first decision is whether the change was authorized. Check the change record for the snapshot deletion, snapshot creation or instance modification against the time stamp in the cloud provider audit log, then compare it with the pipeline logs from the infrastructure-as-code or backup tooling that normally makes such changes. A change that matches an approved ticket and a scheduled job is usually a routine event, but a change with no ticket, run outside the pipeline, or made by a person who does not own that environment is a probable incident. Record the identity, the source IP address, the user agent and the session identifier from the audit event before you touch anything else. Confirm which snapshots or instances were affected and whether they hold regulated or critical data, such as payment records or patient data, using the asset inventory and data classification tags. Those answers decide how fast you move and who you call.
Preserve evidence before containment changes the state you are investigating. Export the relevant audit events for the affected account, region and time window to write-once storage that the investigating identity cannot modify, and note the retention settings of that log source so you know how far back the evidence goes. Then contain in the narrowest way that stops further damage. Suspend the suspicious identity or its access keys, restrict the role or policy it used, and apply deletion protection or a retention lock to the affected snapshots while review is pending. Freezing deletion is usually safer than reverting a change, because reverting can overwrite the evidence you are trying to keep. Hand off to the incident team with a short written record covering the alert, the identity, the affected resources, the preserved log locations and the containment steps taken, with the time of each action.
Recovery depends on the integrity of your snapshots and backups, so confirm early which recovery points are protected. Ask the platform team whether backups are stored in a separate account or tenant, whether immutability or object lock is enabled, and whether the restore path has been tested recently. If an attacker removed or altered recovery points, the incident team needs to know which restore options remain before they decide on eradication. Confirm these facts with your cloud provider documentation and your own backup configuration, since the available protections differ by provider and service. Review the MITRE ATT&CK technique page for T1578 against the version your detections target, so the response playbook names the same sub-techniques your alerts map to.
Rehearsing T1578 detection and response in a private cyber range
SOC analysts receive the first alerts from the range and decide whether a change to cloud compute infrastructure is an incident, a sanctioned change or noise. The range should give them a private cloud-like IaaS test account, a self-hosted logging stack that receives control plane events, and a seeded set of benign pipelines that create and update instances, snapshots and images on a normal schedule. The exercise tests whether analysts can separate those routine events from injected ones.
- Alert timing: Confirm that alerts for injected snapshot deletion or snapshot creation appear within the window agreed before the exercise starts.
- Enrichment: Check that each alert carries the account, the calling identity, the source address, the affected resource and the change ticket, if one exists.
- Triage decisions: Record whether the analyst matched the event to a seeded pipeline or escalated it, and why.
- Handoff: Require a written handoff to the platform team that names the resources, timestamps and containment options considered.
- Feedback: Capture where the runbook was unclear or where the logging stack dropped or delayed events.
At the end of the session, check that the handoff is complete enough for the platform team to act without re-asking the analyst for basic facts.
Detection engineers own the logic that turns cloud control plane events into alerts. In the range, they test whether their rules, written against the ATT&CK version their organization targets, fire on the injected activity and stay quiet on the benign pipelines. Logic should be described in words and stored as version-controlled rules, so the team can show what changed between exercises.
- Rule coverage: Map each rule to the T1578 sub-technique it addresses and to the telemetry it depends on, such as Snapshot Deletion, Snapshot Creation and Cloud Service Metadata.
- False positives: Measure how often seeded pipelines trigger alerts and adjust logic with a documented reason for each change.
- Field completeness: Verify that the fields the rule needs are present in the logging stack's normalized events, not only in the raw source.
- Versioning: Tag the rule set with the exercise date and the ATT&CK version used, because releases can rename, deprecate or revoke techniques.
- Gap log: Record each injected change that produced no alert, with the reason the telemetry was missing or the logic did not match.
Before closing the exercise, confirm that every injected change either produced an alert or has a logged gap with an owner.
The cloud platform team operates the range's IaaS test account and the seeded pipelines, and it is the team that must verify and reverse changes during response. Its role in the exercise is to show that audit logging is enabled for the relevant services, that identity and access controls limit who can change compute resources, and that the team can establish the state of the environment quickly. Planned control plane changes are injected at a high level only, with the exact actions kept in the exercise control document rather than in shared notes.
- Audit coverage: Confirm that control plane audit logs are enabled and forwarded to the self-hosted logging stack for every account in the range.
- Access controls: Check that the User Account Management mitigation is reflected in who can create, modify or delete snapshots and compute resources in the test account.
- Baseline: Keep a documented inventory of the seeded resources so the team can tell injected changes from routine ones.
- Recovery: Test whether the team can restore an affected resource from a known good state within the agreed window.
- Change records: Require that every sanctioned change during the exercise is recorded with a ticket reference.
Ask your provider to confirm in writing which audit log sources are available in your cloud platform before the range is built.
Questions SOC leads and detection engineers ask about T1578
How does T1578 differ from other cloud resource changes that monitoring already flags?
T1578 covers changes to cloud compute infrastructure itself, such as creating, modifying, or deleting instances, images, snapshots, and their supporting configuration, so that defenders lose visibility or recovery options. Generic cloud resource change alerts often fire on routine administration, so they miss the cases where the change weakens defenses. Separate the two: map compute changes that alter logging, backups, or network exposure to T1578, and map changes to resource hierarchy or organization structure to the sibling topic T1666, Modify cloud resource hierarchy. Confirm the sub-technique mapping for your ATT&CK version (v20.0 in these pages) in the ATT&CK technique page before you write the rule.
How should we handle logging across multiple accounts and regions?
Treat every account, subscription, project, and region as a log source with a named owner and a known baseline, and confirm that each one forwards control-plane events to the central SIEM. The most common gap is an account or region that was created later and never added to the trail or sink. Check that organization-level trails or aggregators cover new accounts automatically, that log integrity and retention are enforced centrally, and that a health alert fires when a source stops sending. Ask your cloud team to show you the coverage list, not just the policy that describes it.
How do we keep T1578 detections current when ATT&CK versions change?
Record the ATT&CK version each rule targets in its metadata, and review the mapping whenever MITRE publishes a new release. ATT&CK v18 replaced technique-level detections with detection strategies and analytics and deprecated some data sources, so older rule references may point to retired material. Pull the Enterprise STIX bundle for the version you target from the attack-stix-data repository and diff the technique and sub-technique objects against your rule set. Assign an owner to that review so it happens on a fixed schedule rather than only after an incident.
How can we test a T1578 rule without touching production?
Test in a private cyber range or a dedicated sandbox account that mirrors your logging pipeline, not in the production environment. Use controlled, approved test actions that generate the same control-plane events the rule expects, then confirm the event reaches the SIEM with the fields the rule uses. Record the expected result, the actual result, and any gaps in a test log so that the rule can be re-run after each change. Keep the test scope and approvals in writing, and make sure the sandbox has its own identities so that tests cannot affect real workloads.
Which fields should we normalize in the SIEM for compute change events?
Normalize the fields that let one rule work across providers and accounts:
- Event time, event name, and the action category (create, modify, delete)
- Acting identity, including principal type and whether it is a human, role, or service identity
- Account or subscription ID, region, and resource identifier
- Source IP, user agent, and the result or error code
- Request parameters that change security posture, such as network exposure, encryption settings, or snapshot sharing
Document the mapping in one schema and version it. Test each mapping with a known event before relying on it.
How do we decide whether a suspicious compute change needs an incident?
Decide based on what the change did, who or what made it, and whether it was expected. Open an incident when a change weakens logging, removes or shares snapshots, alters images or network exposure, and the actor cannot be tied to an approved change record. Treat changes that match a documented maintenance window and an approved ticket as operational events, but still review them. Write the criteria into the runbook with named decision owners, so the on-call analyst does not have to decide alone at night. Validate the criteria during cyber range exercises by checking whether analysts reach the same decision on the same scenario.
How DeployOpen builds T1578 detections and range exercises
DeployOpen approaches T1578 Modify cloud compute infrastructure as a self-hosted implementation inside your own cloud accounts, data centers or air-gapped networks. The work starts with a written scope, then builds and tests the detections against your actual IaaS telemetry before handing them over.
How we scope
- Confirm which IaaS accounts, regions and compute services are in the written scope for T1578 detection.
- Inventory snapshot, instance and metadata logging sources, and record which are already forwarded to your SIEM.
- Agree which sub-techniques are covered, and name the ATT&CK version the detection mapping targets before work begins.
How we build
- Map Snapshot Deletion, Snapshot Creation and Cloud Service Metadata telemetry to open-source detection logic in Wazuh or Sigma.
- Verify that cloud audit logs carry the account, source identity and resource fields needed to attribute each change.
- Test detection logic against benign administrative activity in a private cyber range before it reaches production monitoring.
How we hand over
- Deliver detection rules, data source mappings and tuning notes, each tied to its ATT&CK technique and version.
- Document the response runbook, including who validates a flagged snapshot or metadata change and how it is escalated.
- Run a recorded cyber range exercise with your team so analysts can reproduce the detection and close the gaps found.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing separately from the initial work.
- Review detection performance when ATT&CK releases rename, deprecate or revoke mappings that affect T1578.
- Ask any provider to confirm the exact cloud audit log retention and export capabilities of your platform before relying on them.
