AN0481: Analytic 0481
Defenders should monitor for suspicious enumeration of cloud infrastructure components via APIs or CLI tools. Observable behaviors include repeated listing or description operations for compute instances, snapshots, storage buckets, and volumes. From a defender’s perspective, risky activity is often identified by new or untrusted identities making discovery calls (e.g., DescribeInstances, ListBuckets, az vm list, gcloud compute instances list), enumeration from unusual geolocations or IPs, or rapid multi-service discovery in sequence. Correlating discovery API usage with later snapshot creation or instance modification provides further context of adversary behavior.
Analyst context for executives and security teams
This analytic matters because broad cloud enumeration is often an early signal that an identity, access key, or session is being used to map an IaaS environment. For leaders, the decision value is whether cloud logging, identity context, and SOC workflows can distinguish normal administration from a new or untrusted identity rapidly listing instances, snapshots, buckets, and volumes across services.
Executive priority
Prioritize this as a cloud security and incident readiness validation item. The business risk is not the listing activity alone, but what it can enable: faster attacker understanding of critical infrastructure, data stores, backups, and modification targets. Security leaders should ask whether cloud audit logs are retained, whether identities and source locations are baselined, and whether the SOC can correlate discovery calls with later snapshot creation or instance modification for incident escalation and evidence.
Technical view
For IaaS environments, validate monitoring for cloud API and CLI-driven discovery activity such as DescribeInstances, ListBuckets, az vm list, and gcloud compute instances list. Detection should focus on repeated listing or description operations across compute, snapshots, storage buckets, and volumes, especially when performed by new or untrusted identities, from unusual geolocations or IP addresses, or in rapid multi-service sequences. Since no tactic or relationship context is supplied, treat this analytic as a cloud discovery behavior requiring local baselining and correlation rather than a standalone determination of malicious activity.
Likely telemetry
- Cloud control-plane audit logs for API calls
- Identity and access logs showing principal, role, access key, or session context
- CLI/API user agent and request metadata where available
- Source IP address, geolocation, and network origin data
- Cloud asset inventory for instances, snapshots, buckets, and volumes
Detection direction
- Confirm logging coverage for IaaS listing and description operations across compute, storage, snapshots, buckets, and volumes.
- Baseline expected enumeration by administrators, automation, inventory tools, backup tools, and compliance scanners to reduce false positives.
- Alert more strongly on new or untrusted identities, unusual source locations, or rapid enumeration across multiple services.
- Correlate discovery operations with later snapshot creation or instance modification to add incident context.
- Review blind spots where API logs are not centralized, short-retained, missing identity enrichment, or not mapped to cloud assets.
Mitigation priorities
- Ensure cloud control-plane audit logging is enabled, centralized, and retained for investigation and compliance evidence.
- Apply least-privilege access so identities only have required list, describe, snapshot, and modification permissions.
- Use identity governance to review stale, unused, or overly broad cloud roles and access keys.
- Require SOC playbooks to triage suspicious enumeration with identity trust, source location, asset sensitivity, and follow-on actions.
- Harden incident response readiness by preserving cloud logs and defining escalation criteria when enumeration is followed by snapshot or instance changes.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for IaaS cloud infrastructure enumeration via APIs or CLI tools. Its strongest operational use is as a validation checklist for cloud audit telemetry, identity baselining, and correlation logic. The behavior can be legitimate during administration or inventory operations, so local allowlisting and business context are essential.
Official detection text, tactics, labels, aliases, and relationship context were not supplied. This take does not assert active exploitation, attribution, impact, or guaranteed detection coverage. Organizations must validate applicability against their own cloud providers, logging configuration, identity model, and administrative workflows.
Analytic 0481
Defenders should monitor for suspicious enumeration of cloud infrastructure components via APIs or CLI tools. Observable behaviors include repeated listing or description operations for compute instances, snapshots, storage buckets, and volumes. From a defender’s perspective, risky activity is often identified by new or untrusted identities making discovery calls (e.g., DescribeInstances, ListBuckets, az vm list, gcloud compute instances list), enumeration from unusual geolocations or IPs, or rapid multi-service discovery in sequence. Correlating discovery API usage with later snapshot creation or instance modification provides further context of adversary behavior.
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 | 1.0 | Current bundle | a3282603321e… |
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 AN0481Open 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.