DC0089: Instance Stop
The deactivation or shutdown of a virtual machine instance within a cloud infrastructure. This action typically involves stopping a running instance, which halts its operation and releases certain associated resources, such as CPU and memory. Examples:
- Google Cloud Platform (GCP): `instance.stop` events recorded in GCP Audit Logs indicate the deactivation of an instance. - Amazon Web Services (AWS): `StopInstances` actions in AWS CloudTrail indicate EC2 instances being stopped. - Microsoft Azure: `Microsoft.Compute/virtualMachines/deallocate` or `stop` events in Azure Activity Logs represent a virtual machine being stopped or deallocated.
Analyst context for executives and security teams
Instance Stop is a cloud audit evidence category for when a virtual machine is stopped, deallocated, or otherwise shut down. For leaders, this matters because unexpected VM stoppage can affect service availability, incident containment decisions, cost controls, and change accountability. The ATT&CK object is not a technique by itself; it identifies the telemetry defenders should have available when they need to prove who or what stopped cloud compute resources.
Executive priority
Prioritize this as a cloud operations and resilience evidence requirement. Security, infrastructure, and audit teams should be able to answer: Which VM instances were stopped, when, by which identity or service, from where, and whether the action matched an approved change or incident response activity. This supports business continuity reviews, cloud IAM governance, incident timelines, and compliance evidence around privileged administrative actions.
Technical view
Validate collection and retention of cloud control-plane logs that record VM stop or deallocate activity. The official examples are GCP Audit Logs for `instance.stop`, AWS CloudTrail for `StopInstances`, and Azure Activity Logs for `Microsoft.Compute/virtualMachines/deallocate` or `stop`. SOC and IR teams should confirm that these events can be correlated with the target instance, initiating identity, API/action name, timestamp, source context, and related change or ticketing data. Because ATT&CK provides no detection logic, local baselining and environment context are required.
Likely telemetry
- GCP Audit Logs containing `instance.stop` events
- AWS CloudTrail events containing `StopInstances` actions
- Azure Activity Logs containing `Microsoft.Compute/virtualMachines/deallocate` or VM `stop` events
- Cloud identity and authorization context for the actor or service principal performing the stop action
- Cloud asset inventory or configuration data identifying the affected virtual machine instance
Detection direction
- Validate that cloud control-plane logging is enabled, centrally retained, and searchable for VM stop/deallocate actions across relevant cloud accounts, projects, or subscriptions.
- Create review logic for VM stop events involving critical systems, unusual identities, unexpected time windows, or instances without matching change records.
- Tune for expected operational patterns such as scheduled shutdowns, autoscaling, maintenance, cost-optimization workflows, and approved incident response actions to reduce false positives.
- Correlate stop events with identity activity and asset criticality so alerts are not limited to the API action name alone.
- Check for blind spots where logs are retained only in the cloud console, excluded from SIEM ingestion, or missing service principal and automation context.
Mitigation priorities
- Establish least-privilege access for roles that can stop or deallocate virtual machine instances.
- Require change control or approved automation for planned instance stoppage, especially for business-critical workloads.
- Ensure cloud audit logs for VM stop actions are enabled, protected from tampering, centrally collected, and retained long enough for investigations and audit needs.
- Maintain an accurate inventory of critical cloud instances so unexpected stops can be prioritized by business impact.
- Periodically test incident response procedures for reconstructing the timeline and authorization context of a stopped instance.
Analyst notes and limits
This object is a data component, so its value is evidentiary: it tells teams what type of cloud activity should be observable. The supplied ATT&CK content gives cloud-provider examples but no tactic, platform list, technique relationships, or official detection guidance. Treat this as a logging and validation requirement rather than a standalone indicator of malicious activity.
No official detection text or relationship context was supplied. The object does not state attacker intent, affected tactics, or guaranteed security impact. Determining whether an instance stop is suspicious requires local asset criticality, identity context, automation records, and approved change data.
Instance Stop
The deactivation or shutdown of a virtual machine instance within a cloud infrastructure. This action typically involves stopping a running instance, which halts its operation and releases certain associated resources, such as CPU and memory. Examples:
- Google Cloud Platform (GCP): `instance.stop` events recorded in GCP Audit Logs indicate the deactivation of an instance. - Amazon Web Services (AWS): `StopInstances` actions in AWS CloudTrail indicate EC2 instances being stopped. - Microsoft Azure: `Microsoft.Compute/virtualMachines/deallocate` or `stop` events in Azure Activity Logs represent a virtual machine being stopped or deallocated.
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 | 54a0e60acf28… |
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 DC0089Open 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.