DC0028: Image Metadata

contextual information associated with a virtual machine image, such as its name, resource group, status (active or inactive), type (custom or prebuilt), size, creation date, and permissions. This metadata is critical for understanding the state and configuration of virtual machine images in cloud environments. Examples:

- Azure Compute Service Image Metadata Example: - Name: MyCustomImage - Resource Group: MyResourceGroup - State: Available - Type: Managed Image - AWS EC2 AMI Metadata Example: - Image ID: ami-1234567890abcdef0 - Name: ProdImage - State: Available - Platform: Windows - Google Cloud Compute Engine Image Metadata Example: - Image Name: webserver-image - Project: my-project-id - Family: webserver - Source Disk: my-disk-id - VMware vSphere Template Metadata Example: - Name: LinuxTemplate - Disk Size: 40GB - Network Adapter: VM Network

EnterpriseDC0028Data ComponentObject v2.0 Modified Nov 12, 2025, 22:03 UTC (UTC+00:00)

Image Metadata is inventory and configuration context for virtual machine images, such as name, resource group or project, state, type, size, creation date, source disk, platform, and permissions. For security leaders, its value is not that it is an alert by itself, but that it helps determine whether cloud and virtualization images are approved, current, available, and properly governed before they become running workloads.

Executive priority

Prioritize image metadata governance as part of cloud security, vulnerability management, incident response, and compliance readiness. Executives should ask whether teams can quickly prove which VM images exist, who can use them, whether they are custom or prebuilt, whether they are active, and whether image permissions align with policy. Weak image visibility can slow incident scoping, weaken audit evidence, and allow outdated or unauthorized images to persist in build and recovery workflows.

Technical view

SOC, cloud security, and IR teams should validate that image metadata is collected from cloud and virtualization control planes and can be correlated with asset inventory, workload deployment records, access permissions, and change history. Because ATT&CK provides no detection logic for this data component, treat it as contextual telemetry that supports investigations and control validation rather than as a standalone detection source. Useful review points include image state, ownership context such as resource group or project, custom versus prebuilt type, creation date, size, source disk or template details, and permissions.

Likely telemetry

Cloud or virtualization image inventory records
Image identifiers, names, families, projects, resource groups, and template names
Image state or status such as active, inactive, available, or unavailable
Image type information such as custom, prebuilt, managed image, AMI, or template
Creation date, size, source disk, platform, and network adapter metadata where available

Detection direction

Confirm whether image metadata is centrally collected and retained across relevant cloud and virtualization environments described by local architecture.
Correlate image metadata with workload deployment events so responders can identify which running systems originated from a given image.
Tune reviews for unauthorized, stale, misnamed, unusually shared, or policy-noncompliant images, while accounting for legitimate image build pipelines and maintenance windows.
Use permissions and state fields to support governance checks, but avoid treating metadata presence alone as malicious activity.
Identify blind spots where image inventories exist only in provider consoles, isolated projects, resource groups, or virtualization management systems and are not available to SOC or IR workflows.

Mitigation priorities

Establish authoritative inventory ownership for VM images and templates.
Require standard naming, tagging, ownership, and lifecycle status for images where local platforms support it.
Review and restrict image permissions according to least privilege and approved deployment processes.
Integrate image metadata into vulnerability management and compliance evidence workflows so outdated or unauthorized images can be identified before deployment.
Ensure incident response procedures include image metadata collection for scoping affected workloads and recovery sources.

Analyst notes and limits

This ATT&CK object is a data component, not a technique. It describes image metadata used to understand virtual machine image state and configuration in cloud environments, with examples for Azure Compute Service, AWS EC2 AMIs, Google Cloud Compute Engine images, and VMware vSphere templates. The most defensible use is as enrichment and governance evidence for cloud, virtualization, SOC, IR, and compliance workflows.

ATT&CK provides no tactics, platforms field, detection text, or relationship context for this object. Local environment architecture, logging configuration, access-control model, and retention practices are required to determine whether this telemetry is available and useful.

Official MITRE ATT&CK definition

Image Metadata

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release: 19.1
Object version: 2.0
Created: Oct 20, 2021, 15:05 UTC (UTC+00:00)
Modified: Nov 12, 2025, 22:03 UTC (UTC+00:00)
Raw hash: 5ae9f977ee0796ff...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	2.0	Nov 12, 2025, 22:03 UTC (UTC+00:00)	Current bundle	`5ae9f977ee07…`

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

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 DC0028
Open source URL

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use