DC0075: Instance Enumeration
The process of retrieving or querying a list of virtual machine instances or compute instances within a cloud infrastructure. This activity provides a view of all available or running instances, typically including their associated metadata such as instance ID, name, state, and configuration details. Examples:
- AWS: instance enumeration involves the `DescribeInstances` API call, which retrieves information about running or stopped EC2 instances. - Azure: VM enumeration can be monitored via the `Microsoft.Compute/virtualMachines/read` operation. - GCP: instance enumeration is logged as an `instance.list` operation within GCP Audit Logs.
*Data Collection Measures:*
- AWS CloudTrail: CloudTrail logs stored in S3 or forwarded to CloudWatch. - Azure Activity Logs: Accessible via Azure Monitor or exported to a storage account. - GCP Audit Logs: Logs Explorer or BigQuery.
Analyst context for executives and security teams
Instance Enumeration is the cloud visibility event where someone queries the inventory of virtual machines or compute instances. For leaders, this matters because instance inventory is often the starting point for understanding cloud scope during an investigation, validating asset governance, and spotting unusual discovery behavior. The ATT&CK object does not define a specific adversary technique here, but it identifies the evidence teams should be able to collect from AWS, Azure, and GCP control-plane logs.
Executive priority
Prioritize this as a cloud security and audit-readiness control question: can the organization prove who queried compute inventory, when, from where, and under which identity? This supports incident response scoping, cloud asset accountability, least-privilege reviews, and compliance evidence around administrative access. Because no official detection logic is provided, the business decision is whether cloud logging, retention, and review processes are mature enough to make instance enumeration explainable during an incident.
Technical view
SOC, cloud, and IR teams should validate collection and retention of cloud control-plane events for compute inventory queries. The ATT&CK description identifies AWS DescribeInstances in CloudTrail, Azure Microsoft.Compute/virtualMachines/read in Azure Activity Logs, and GCP instance.list in GCP Audit Logs. Detection engineering should focus on baselining expected users, roles, automation, and service accounts that enumerate instances, then reviewing deviations by identity, source, timing, tenant/subscription/project scope, and volume. Since no tactics, platforms, or relationships are supplied, local cloud architecture and identity context are required to determine suspiciousness.
Likely telemetry
- AWS CloudTrail events stored in S3 or forwarded to CloudWatch, especially DescribeInstances activity
- Azure Activity Logs via Azure Monitor or exported storage, especially Microsoft.Compute/virtualMachines/read operations
- GCP Audit Logs available in Logs Explorer or BigQuery, especially instance.list operations
- Cloud identity context associated with the query, such as user, role, service account, or automation identity
- Request metadata such as time, source location, account/subscription/project, and queried scope when available
Detection direction
- Confirm that AWS, Azure, and GCP control-plane audit logs are enabled, centralized, retained, and searchable for instance enumeration events.
- Build baselines for legitimate inventory tooling, cloud management platforms, administrators, CI/CD jobs, and service accounts to reduce false positives.
- Review enumeration from unusual identities, unexpected source locations, new access paths, or identities without a normal operational reason to list instances.
- Correlate enumeration with nearby authentication, permission changes, or other cloud administration events where local telemetry permits.
- Avoid treating every instance list/read operation as malicious; these events are common in normal cloud operations and require identity and business-context tuning.
Mitigation priorities
- Ensure cloud audit logging is enabled and retained for compute inventory operations across relevant accounts, subscriptions, and projects.
- Apply least-privilege access so only approved users, roles, and service accounts can enumerate compute resources where business need exists.
- Regularly review permissions that allow broad read access to instance inventory, especially for cross-account, subscription-wide, or project-wide scopes.
- Document approved automation and inventory processes so SOC and IR teams can distinguish expected enumeration from activity requiring investigation.
- Test incident response playbooks to confirm responders can quickly identify who enumerated instances and what cloud scope was visible.
Analyst notes and limits
This is a data component, not a technique, and it is most useful for validating whether defenders collect the cloud audit evidence needed to investigate compute inventory discovery. The official object provides concrete AWS, Azure, and GCP examples but no detection analytic, tactics, platforms field, or relationship context.
No official detection text, ATT&CK tactics, platforms, or relationships were supplied. This take cannot assert malicious intent, active exploitation, attribution, or coverage. Determining whether instance enumeration is suspicious depends on local cloud identity baselines, logging configuration, retention, and business-approved automation.
Instance Enumeration
The process of retrieving or querying a list of virtual machine instances or compute instances within a cloud infrastructure. This activity provides a view of all available or running instances, typically including their associated metadata such as instance ID, name, state, and configuration details. Examples:
- AWS: instance enumeration involves the `DescribeInstances` API call, which retrieves information about running or stopped EC2 instances. - Azure: VM enumeration can be monitored via the `Microsoft.Compute/virtualMachines/read` operation. - GCP: instance enumeration is logged as an `instance.list` operation within GCP Audit Logs.
*Data Collection Measures:*
- AWS CloudTrail: CloudTrail logs stored in S3 or forwarded to CloudWatch. - Azure Activity Logs: Accessible via Azure Monitor or exported to a storage account. - GCP Audit Logs: Logs Explorer or BigQuery.
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 | 19ef63fd2192… |
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 DC0075Open 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.