DC0076: Instance Creation
The initial provisioning and construction of a virtual machine (VM) or compute instance within a cloud infrastructure environment. This activity involves defining and allocating resources such as CPU, memory, storage, and networking to spin up a new compute instance. Examples:
- AWS: creating an EC2 instance using RunInstances API calls. - Azure, creating a VM through the Azure Resource Manager (ARM). - GCP, an `instance.insert` action recorded.
Analyst context for executives and security teams
Instance Creation is the cloud evidence that a new VM or compute instance was provisioned. For leaders, this matters because unauthorized or poorly governed compute creation can affect cost, attack surface, data exposure, and incident scope. Even when legitimate, this event class is foundational for proving who created infrastructure, when it appeared, and whether it followed approved change and access processes.
Executive priority
Treat cloud instance creation telemetry as a control point for cloud governance and incident readiness. Security and risk leaders should ask whether cloud audit logs can reliably show new compute creation, the actor or service identity involved, the target account/subscription/project, and the network/storage configuration at creation time. This data component supports budget and control decisions around cloud security monitoring, identity governance, change management evidence, and rapid containment during cloud incidents.
Technical view
ATT&CK defines this data component as the initial provisioning and construction of a VM or compute instance in a cloud infrastructure environment, including allocation of CPU, memory, storage, and networking. The official examples include AWS EC2 RunInstances API calls, Azure VM creation through Azure Resource Manager, and GCP instance.insert activity. Because ATT&CK provides no detection text, SOC and detection teams should validate that cloud control-plane logs capture instance creation events and that detections can distinguish expected automation from unusual manual, cross-account, or out-of-process provisioning.
Likely telemetry
- Cloud control-plane audit logs for compute instance creation events
- API activity records such as RunInstances, Azure Resource Manager VM creation activity, or GCP instance.insert events where applicable
- Identity and access context for the creating user, role, service principal, or automation identity
- Account, subscription, project, region, and resource identifiers for the new instance
- Creation-time configuration details such as image, size, storage, network attachment, security group or firewall association, and tags or labels where logged
Detection direction
- Confirm that instance creation events are collected centrally and retained long enough for investigation and compliance evidence.
- Baseline approved provisioning paths, including infrastructure-as-code pipelines and authorized automation identities, before alerting on deviations.
- Tune for context rather than volume alone: actor, source location, target environment, region, image choice, network exposure, and absence of required tags can materially change priority.
- Watch for blind spots where logs exist only in individual cloud accounts, subscriptions, or projects and are not forwarded to the SOC.
- Account for false positives from autoscaling, scheduled deployments, disaster recovery tests, and legitimate engineering activity.
Mitigation priorities
- Ensure cloud audit logging is enabled and centrally monitored for compute provisioning events.
- Restrict who and what can create compute instances through least-privilege identity and access controls.
- Require approved provisioning workflows, tagging or labeling standards, and change records for new instances.
- Use preventive cloud governance controls where available to limit unapproved regions, images, instance types, network exposure, or storage configurations.
- Regularly reconcile active instances against asset inventory and approved deployment records.
Analyst notes and limits
This object is a data component, not a technique. Its value is evidentiary: it helps teams observe when cloud compute resources are created. The supplied ATT&CK record has no tactics, platforms, detection guidance, or relationship context, so defensive use should be tied to local cloud logging, identity, asset inventory, and change-management data.
The official object provides a description and cloud-provider examples but no ATT&CK detection text, no relationships, and no specified platforms or tactics. Any assessment of maliciousness, coverage, or priority requires local telemetry and environment context.
Instance Creation
The initial provisioning and construction of a virtual machine (VM) or compute instance within a cloud infrastructure environment. This activity involves defining and allocating resources such as CPU, memory, storage, and networking to spin up a new compute instance. Examples:
- AWS: creating an EC2 instance using RunInstances API calls. - Azure, creating a VM through the Azure Resource Manager (ARM). - GCP, an `instance.insert` action recorded.
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 | b54faa300f77… |
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 DC0076Open 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.