DC0073: Instance Modification
Changes made to a virtual machine (VM) or compute instance, including alterations to its configuration, metadata, attached policies, or operational state. Such modifications can include updating metadata, attaching or detaching resource policies, resizing instances, or modifying network configurations. Examples:
- AWS: instance modifications include API actions like `ModifyInstanceAttribute`, `ModifyInstanceMetadataOptions`, or `RebootInstances`. - Azure: modifications can be tracked through operations like `Microsoft.Compute/virtualMachines/write`. - GCP: instance modification events include operations like `instances.setMetadata`, `instances.addResourcePolicies`, or `instances.resize`.
*Data Collection Measures:*
- AWS CloudTrail: Log Location: Stored in S3 or forwarded to CloudWatch. - Azure Activity Logs: Log Location: Accessible via Azure Monitor or exported to a storage account. - GCP Audit Logs: Log Location: Logs Explorer or BigQuery.
Analyst context for executives and security teams
Instance Modification is the audit evidence that a cloud VM or compute instance was changed: configuration, metadata, attached policies, size, network settings, or operational state. For leaders, this matters because small cloud control-plane changes can affect availability, exposure, identity permissions, and incident scope. The value is not just logging that a change happened, but being able to prove whether it was authorized, expected, and reversible.
Executive priority
Prioritize this data component where cloud compute supports critical services. It helps answer business-impact questions during incidents and audits: who changed a workload, what changed, when it changed, whether the change affected network exposure or policy attachment, and whether the organization can distinguish planned administration from suspicious or risky modification. Coverage should be validated as part of cloud security, incident response readiness, compliance evidence, and change-control assurance.
Technical view
SOC, cloud security, and IR teams should validate collection of cloud control-plane modification events for compute instances. The supplied ATT&CK description identifies AWS examples such as ModifyInstanceAttribute, ModifyInstanceMetadataOptions, and RebootInstances; Azure operations such as Microsoft.Compute/virtualMachines/write; and GCP operations such as instances.setMetadata, instances.addResourcePolicies, and instances.resize. Because ATT&CK provides no specific detection logic or tactic mapping for this data component, teams should use it as supporting telemetry for detections and investigations involving VM configuration, metadata, policy, network, resize, or state changes, correlated with identity, change-management, and asset criticality context.
Likely telemetry
- AWS CloudTrail events stored in S3 or forwarded to CloudWatch
- Azure Activity Logs accessible via Azure Monitor or exported to a storage account
- GCP Audit Logs available in Logs Explorer or BigQuery
- Cloud control-plane API operation names related to instance attribute, metadata, policy, resize, network, or state changes
- Actor identity, timestamp, target instance, region/project/subscription/account, request parameters, and response status where available
Detection direction
- Confirm that instance modification events are retained and searchable across AWS, Azure, and GCP environments in scope.
- Tune detections around sensitive changes such as metadata updates, policy attachment or detachment, network configuration changes, resizing, and reboot or operational-state changes.
- Correlate modification events with the calling identity, source context, affected asset criticality, and approved change windows to reduce false positives from routine administration.
- Watch for blind spots where logs remain only in provider consoles, are not exported centrally, have short retention, or are missing request details needed for investigation.
- Because no official ATT&CK detection is provided, treat this component as a required evidence source rather than a complete detection by itself.
Mitigation priorities
- Ensure cloud audit logging is enabled and exported to durable, centrally monitored storage for all relevant accounts, subscriptions, and projects.
- Apply least-privilege access to compute instance modification permissions, especially metadata, policy, and network-related changes.
- Require change-control evidence for production and critical workload modifications.
- Protect log storage and monitoring pipelines from unauthorized alteration or deletion.
- Periodically test incident response workflows by verifying that teams can reconstruct who modified a specific instance and what changed.
Analyst notes and limits
This ATT&CK object is a data component, not a technique. Its main decision value is evidence readiness: whether the organization can observe and investigate compute instance changes in cloud environments. The official object gives examples for AWS, Azure, and GCP collection sources but does not provide tactics, platforms, relationships, or detection analytics.
No relationship context, tactic mapping, platform field, or official detection content was supplied. Any assessment of maliciousness, business impact, or coverage requires local cloud architecture, identity context, asset criticality, logging configuration, and change-management data.
Instance Modification
Changes made to a virtual machine (VM) or compute instance, including alterations to its configuration, metadata, attached policies, or operational state. Such modifications can include updating metadata, attaching or detaching resource policies, resizing instances, or modifying network configurations. Examples:
- AWS: instance modifications include API actions like `ModifyInstanceAttribute`, `ModifyInstanceMetadataOptions`, or `RebootInstances`. - Azure: modifications can be tracked through operations like `Microsoft.Compute/virtualMachines/write`. - GCP: instance modification events include operations like `instances.setMetadata`, `instances.addResourcePolicies`, or `instances.resize`.
*Data Collection Measures:*
- AWS CloudTrail: Log Location: Stored in S3 or forwarded to CloudWatch. - Azure Activity Logs: Log Location: Accessible via Azure Monitor or exported to a storage account. - GCP Audit Logs: Log Location: Logs Explorer or BigQuery.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.1 | Current bundle | 5f5f9e6c6ce2… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0073Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.