DC0036: Image Modification
Changes made to a virtual machine image, including setting and/or control data (ex: Azure Compute Service Images PATCH)
Analyst context for executives and security teams
Image Modification is a cloud/virtualization evidence source: it represents changes made to a virtual machine image, such as updates through an image service API. For leaders, the practical value is not that this object describes an attack by itself, but that VM images are often part of how organizations standardize servers, rebuild systems, and recover operations. If image-change activity is not logged, reviewed, and tied to authorized change processes, teams may struggle to prove what changed, when it changed, and whether deployed systems still match approved baselines.
Executive priority
Prioritize this as a governance and resilience control point for environments that rely on virtual machine images. Executives should ask whether image changes are traceable to approved owners, whether image integrity is part of audit evidence, and whether incident responders can determine if a deployed system came from an expected image version. Because ATT&CK provides no tactic, platform list, or detection guidance for this data component, local cloud and virtualization architecture should drive the risk ranking.
Technical view
SOC, detection, and IR teams should validate whether they collect administrative and API-level records for VM image modification events, including image metadata changes, version updates, and changes to settings or control data. The supplied ATT&CK description gives Azure Compute Service Images PATCH as an example, but the object does not define supported platforms broadly. Detection engineering should therefore map this data component to the organization’s actual image services and change-management workflows rather than assuming universal coverage.
Likely telemetry
- Cloud or virtualization control-plane audit logs for VM image update or PATCH-style operations
- Image service API request records, including caller identity, timestamp, target image, and modified fields where available
- Administrative activity logs from consoles, automation pipelines, or infrastructure-as-code systems that can change VM images
- Change-management records linking image modifications to approved requests
- Image metadata, version history, and configuration state before and after modification
Detection direction
- Confirm that image modification events are logged at the control plane and retained long enough to support investigations and audit needs.
- Correlate image changes with authenticated identity, role, source context, approval ticket, and deployment pipeline activity to distinguish expected maintenance from unusual changes.
- Tune alerts around modifications to production, golden, recovery, or widely reused images, while accounting for legitimate patching and image lifecycle operations.
- Validate blind spots in automation accounts, service principals, privileged administrators, and regions or tenants where image services may not be consistently logged.
- Because ATT&CK provides no official detection text or relationships for this object, detections should be locally derived from actual platform logs and operational baselines.
Mitigation priorities
- Maintain an inventory of approved VM images, owners, and expected update paths.
- Require image changes to flow through governed change control, privileged access controls, and auditable automation where possible.
- Restrict who can modify images and periodically review permissions for image administration roles.
- Preserve image versioning, metadata, and audit logs to support incident response and compliance evidence.
- Include critical images in integrity, backup, and recovery planning so unauthorized or mistaken changes can be investigated and rolled back.
Analyst notes and limits
This is a data component, not a technique. Its value is in confirming whether defenders can observe changes to VM images that may affect system baselines, recovery trust, and infrastructure governance. The only supplied example is Azure Compute Service Images PATCH, so references to broader cloud or virtualization environments should be treated as local mapping requirements, not ATT&CK-confirmed platform coverage.
No ATT&CK tactics, platforms, official detection guidance, aliases, labels, or relationship context were supplied. This take does not assert malicious use, active exploitation, attribution, or detection coverage. Defensive conclusions require validation against the organization’s actual cloud, virtualization, logging, identity, and change-management environment.
Image Modification
Changes made to a virtual machine image, including setting and/or control data (ex: Azure Compute Service Images PATCH)
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.0 | Current bundle | fd017a70f2c1… |
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 DC0036Open 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.