DC0015: Image Creation
Initial construction of a virtual machine image within a cloud environment. Virtual machine images are templates containing an operating system and installed applications, which can be deployed to create new virtual machines. Monitoring the creation of these images is important because adversaries may create custom images to include malicious software or misconfigurations for later exploitation. Examples:
- Azure Compute Service Image Creation - Example: Creating a virtual machine image in Azure using Azure CLI: `az image create --resource-group MyResourceGroup --name MyImage --source MyVM` - AWS EC2 AMI (Amazon Machine Image) Creation - Example: Creating an AMI from an EC2 instance: `aws ec2 create-image --instance-id i-1234567890abcdef0 --name "MyAMI" --description "An AMI for my app"` - Google Cloud Compute Engine Image Creation - Example: Creating a custom image using gcloud: `gcloud compute images create my-custom-image --source-disk my-disk --source-disk-zone us-central1-a` - VMware vSphere - Example: Exporting a VM to create an OVF (Open Virtualization Format) template: This could later be imported into other environments with potential tampering.
Analyst context for executives and security teams
Image Creation is about the first creation of virtual machine images in cloud or virtualized environments. For leaders, this matters because images can become reusable templates for many future systems; if an image is created with malicious software or unsafe configuration, the risk can be multiplied every time it is deployed.
Executive priority
Treat image creation as a control point for cloud governance and resilience. Security leaders should ask who is allowed to create images, whether image creation is logged and reviewed, and whether newly created images are approved before reuse. This supports incident readiness, compliance evidence, and cloud risk management because image provenance can determine whether future workloads inherit trusted or unsafe baselines.
Technical view
ATT&CK provides this as data component DC0015, focused on the initial construction of a VM image in a cloud environment, with examples across Azure Compute images, AWS EC2 AMIs, Google Cloud Compute Engine custom images, and VMware vSphere OVF templates. SOC and cloud security teams should validate that image creation events are collected from the relevant control planes, correlated to the creating identity, source VM or disk, resource group/project/account context, timestamp, and subsequent image use. Because no official ATT&CK detection text or technique relationships were supplied, local cloud architecture and IAM model are required to define suspicious patterns.
Likely telemetry
- Cloud control-plane audit logs for VM image or template creation
- Identity and access logs showing the user, role, service account, or automation identity that created the image
- Resource metadata for the source VM, disk, image name, description, tags, account, project, subscription, or resource group
- Virtualization management events for template or OVF export where applicable
- Change-management or approval records for golden image creation and publishing
Detection direction
- Baseline expected image creation activity by approved teams, automation pipelines, environments, and naming/tagging conventions.
- Alert or review image creation by unusual identities, outside expected change windows, from unexpected source systems, or in accounts/projects/subscriptions where image creation is rare.
- Correlate image creation with IAM changes, source VM changes, and later VM deployments to understand whether a newly created image becomes an operational risk multiplier.
- Tune false positives for legitimate infrastructure-as-code, backup, migration, disaster recovery, and image pipeline activity.
- Check blind spots in cloud audit logging, retention, cross-account visibility, and virtualization management logs; lack of platform-level logging may make image provenance difficult to prove during IR.
Mitigation priorities
- Restrict image creation permissions to approved administrators, service accounts, and image pipeline roles using least privilege.
- Require change approval, tagging, ownership, and provenance records for reusable images and templates.
- Review or scan newly created images before promotion into shared catalogs or production deployment paths.
- Separate experimental or user-created images from approved baseline images used for production workloads.
- Retain audit logs long enough to support incident response, compliance evidence, and reconstruction of which systems were built from a specific image.
Analyst notes and limits
This object is a data component, not a technique. Its value is in confirming whether the organization can observe and govern a cloud or virtualization event that may influence many downstream workloads. The supplied ATT&CK description supports cloud and virtualization examples, but does not provide tactics, platforms, detections, or relationships to specific adversary behaviors.
No official detection guidance, tactics, platforms field, or relationship context was supplied. This take therefore avoids claims about specific adversary use, prevalence, or guaranteed detection and requires local cloud provider, virtualization, IAM, and logging details to operationalize.
Image Creation
Initial construction of a virtual machine image within a cloud environment. Virtual machine images are templates containing an operating system and installed applications, which can be deployed to create new virtual machines. Monitoring the creation of these images is important because adversaries may create custom images to include malicious software or misconfigurations for later exploitation. Examples:
- Azure Compute Service Image Creation - Example: Creating a virtual machine image in Azure using Azure CLI: `az image create --resource-group MyResourceGroup --name MyImage --source MyVM` - AWS EC2 AMI (Amazon Machine Image) Creation - Example: Creating an AMI from an EC2 instance: `aws ec2 create-image --instance-id i-1234567890abcdef0 --name "MyAMI" --description "An AMI for my app"` - Google Cloud Compute Engine Image Creation - Example: Creating a custom image using gcloud: `gcloud compute images create my-custom-image --source-disk my-disk --source-disk-zone us-central1-a` - VMware vSphere - Example: Exporting a VM to create an OVF (Open Virtualization Format) template: This could later be imported into other environments with potential tampering.
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 | 3d8c5edc9d99… |
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 DC0015Open 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.