DC0070: Cloud Service Metadata
Cloud service metadata refers to the contextual and descriptive information about cloud services, including their name, type, purpose, configuration, and activity around them. This metadata is essential for understanding the roles and functions of cloud services, their operational status, and their potential misuse. Examples:
- Azure Service Metadata: Metadata describing a resource in Azure, such as an Azure Storage Account or a Virtual Machine. - AWS Cloud Service Metadata: Metadata for an AWS EC2 instance collected using the `DescribeInstances` API call. - Google Cloud Service Metadata: Metadata for a Google Compute Engine instance collected using `gcloud compute instances describe`. - Office 365 Metadata: Metadata about an Office 365 SharePoint site.
Analyst context for executives and security teams
Cloud Service Metadata is the descriptive and contextual information that explains what cloud services exist, how they are configured, what purpose they serve, and what activity surrounds them. For leaders, its value is not a single alert; it is the inventory and context needed to understand whether cloud resources are expected, properly governed, and potentially misused. Without reliable metadata, cloud security, incident response, audit readiness, and ownership decisions become slower and less defensible.
Executive priority
Prioritize this as a cloud visibility and governance dependency. Executives and risk owners should ask whether the organization can quickly identify cloud service owners, purpose, configuration state, operational status, and recent activity across major cloud and SaaS environments. This data component supports incident scoping, compliance evidence, cloud asset accountability, and control prioritization, especially where unmanaged or poorly documented cloud services could disrupt business operations or weaken response decisions.
Technical view
SOC, cloud security, and IR teams should validate that cloud service metadata is collected, normalized, retained, and searchable for the relevant cloud services in scope. ATT&CK examples include Azure resource metadata, AWS EC2 instance metadata from DescribeInstances, Google Compute Engine instance metadata from describe commands, and Office 365 SharePoint site metadata. Because no ATT&CK detection text, tactics, platforms, or relationships are supplied, this object should be treated as a telemetry foundation rather than a standalone detection analytic.
Likely telemetry
- Cloud asset and resource inventory records
- Cloud service configuration metadata
- Cloud service name, type, purpose, and ownership context where available
- Operational status and activity context for cloud services
- AWS EC2 instance metadata such as DescribeInstances output
Detection direction
- Validate whether metadata collection covers the cloud and SaaS services that matter to the business; ATT&CK does not specify platforms for this data component.
- Tune detections to use metadata as enrichment for ownership, expected purpose, configuration context, and operational status rather than relying on raw events alone.
- Look for blind spots where resources exist without clear purpose, owner, configuration baseline, or activity context.
- Account for false positives caused by legitimate administrative changes, autoscaling, provisioning workflows, and expected service lifecycle events.
- Use metadata to improve incident triage and scoping, but require local baselines and environment-specific context before treating anomalies as suspicious.
Mitigation priorities
- Establish authoritative cloud asset inventory and metadata collection before building advanced detections that depend on cloud context.
- Define required metadata fields such as service name, type, purpose, configuration state, operational status, and ownership where organizationally feasible.
- Integrate cloud metadata into SOC, incident response, vulnerability management, and compliance evidence workflows.
- Regularly review metadata completeness and freshness to identify unmanaged, stale, or poorly documented cloud services.
- Use governance processes to ensure newly created cloud services are documented and traceable to a business purpose.
Analyst notes and limits
The supplied ATT&CK object is a data component, not a technique, and no relationship context is provided. Its main defensive value is enabling context-aware cloud monitoring, investigation, and governance. The official description provides examples across Azure, AWS, Google Cloud, and Office 365, but the object itself lists platforms and tactics as not specified.
No official detection guidance, tactics, platforms, or relationships were supplied. This take cannot assert specific attacker behavior, active exploitation, attribution, impact, or guaranteed detection coverage. Local cloud architecture, logging configuration, retention, asset inventory quality, and ownership data are required to determine practical coverage.
Cloud Service Metadata
Cloud service metadata refers to the contextual and descriptive information about cloud services, including their name, type, purpose, configuration, and activity around them. This metadata is essential for understanding the roles and functions of cloud services, their operational status, and their potential misuse. Examples:
- Azure Service Metadata: Metadata describing a resource in Azure, such as an Azure Storage Account or a Virtual Machine. - AWS Cloud Service Metadata: Metadata for an AWS EC2 instance collected using the `DescribeInstances` API call. - Google Cloud Service Metadata: Metadata for a Google Compute Engine instance collected using `gcloud compute instances describe`. - Office 365 Metadata: Metadata about an Office 365 SharePoint site.
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 | 984b5a2c34e0… |
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 DC0070Open 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.