DC0080: Instance Start
The initiation or activation of a virtual machine instance within a cloud infrastructure. This action typically involves starting an existing instance that had been stopped or paused, allowing it to resume operation. Examples:
- Google Cloud Platform (GCP): Starting an instance through `instance.start` API activity. - AWS: Logging of `StartInstances` in AWS CloudTrail for EC2 instances. - Azure: `Microsoft.Compute/virtualMachines/start` entries indicate a VM instance being started.
Analyst context for executives and security teams
Instance Start is a cloud audit evidence point showing that a stopped or paused virtual machine was activated. For leaders, its value is not that starting a VM is inherently malicious, but that unexpected starts can change cost, exposure, operational state, and investigation scope. It is especially useful for validating whether cloud teams can explain who or what reactivated compute resources and whether that activity aligns with approved operations.
Executive priority
Prioritize this data component as part of cloud governance and incident readiness. Security and operations leaders should be able to answer: which stopped VMs can be restarted, who is authorized to start them, whether start events are retained in audit logs, and whether unexpected starts trigger review. This supports cloud security oversight, compliance evidence for administrative activity, and incident decision-making when dormant infrastructure suddenly becomes active.
Technical view
SOC, cloud security, and IR teams should validate collection and normalization of cloud provider start events described by ATT&CK: GCP `instance.start` API activity, AWS CloudTrail `StartInstances` for EC2, and Azure `Microsoft.Compute/virtualMachines/start`. Because no ATT&CK detection logic or tactic relationships are supplied, treat this as a foundational telemetry source rather than a standalone detection. Useful analysis depends on correlating the start event with actor identity, API caller, source context, target instance, timing, change records, and subsequent activity on or from the VM.
Likely telemetry
- Cloud audit logs for VM start actions
- GCP API activity containing `instance.start`
- AWS CloudTrail events containing `StartInstances` for EC2
- Azure activity entries containing `Microsoft.Compute/virtualMachines/start`
- Identity and authorization context for the caller or service principal
Detection direction
- Confirm that VM start events are ingested from each relevant cloud audit source and retained long enough for incident investigation and compliance review.
- Tune alerts around unexpected starts of sensitive, dormant, production, internet-facing, or previously quarantined instances, using local asset criticality and change windows to reduce false positives.
- Correlate start events with the initiating identity, role, API source, automation account, and any immediately following administrative or network activity.
- Watch for blind spots where audit logging is disabled, not centralized, not parsed consistently across cloud providers, or missing service-principal context.
- Do not treat every instance start as suspicious; normal autoscaling, maintenance, backup, recovery, and administrative workflows may legitimately start VMs.
Mitigation priorities
- Ensure cloud audit logging for VM lifecycle actions is enabled, centralized, and protected from unauthorized alteration.
- Restrict permission to start virtual machines to approved users, roles, service accounts, and automation paths.
- Maintain asset ownership, criticality, and expected operating-state records so analysts can distinguish normal starts from unusual ones.
- Require change or maintenance documentation for planned starts of sensitive or previously stopped instances.
- Include VM start events in incident response playbooks for cloud investigations, especially when reviewing unauthorized access, unexpected cost increases, or reactivation of dormant infrastructure.
Analyst notes and limits
ATT&CK defines this as a data component, not a technique. The supplied object provides cloud-provider examples but no ATT&CK tactics, platforms, detection text, or relationship context. The practical value is in using the event as audit and correlation evidence for cloud compute lifecycle monitoring.
This take is limited to the official STIX fields, description, external reference, and absence of relationship context supplied. It does not establish malicious intent, active exploitation, attribution, or guaranteed detection. Local cloud architecture, logging configuration, IAM design, asset criticality, and change-management evidence are required to determine materiality.
Instance Start
The initiation or activation of a virtual machine instance within a cloud infrastructure. This action typically involves starting an existing instance that had been stopped or paused, allowing it to resume operation. Examples:
- Google Cloud Platform (GCP): Starting an instance through `instance.start` API activity. - AWS: Logging of `StartInstances` in AWS CloudTrail for EC2 instances. - Azure: `Microsoft.Compute/virtualMachines/start` entries indicate a VM instance being started.
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 | e1d311697134… |
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 DC0080Open 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.