DC0083: Cloud Service Enumeration
Cloud service enumeration involves listing or querying available cloud services in a cloud control plane. This activity is often performed to identify resources such as virtual machines, storage buckets, compute clusters, or other services within a cloud environment. Examples include API calls like `AWS ECS ListServices`, `Azure ListAllResources`, or `Google Cloud ListInstances`. Examples:
AWS Cloud Service Enumeration: The adversary gathers details about existing ECS services to identify opportunities for privilege escalation or exfiltration. - Azure Resource Enumeration: The adversary collects information about virtual machines, resource groups, and other Azure assets for reconnaissance purposes. - Google Cloud Resource Enumeration: The attacker seeks to map the environment and find misconfigured or underutilized resources for exploitation. - Office 365 Service Enumeration: The attacker may look for data repositories or collaboration tools to exfiltrate sensitive information.
Analyst context for executives and security teams
Cloud Service Enumeration is the evidence of someone listing or querying what exists in a cloud control plane, such as virtual machines, storage buckets, compute clusters, collaboration repositories, or other services. For leaders, this matters because enumeration is often how an intruder turns initial access or weak permissions into an actionable map of the environment. Even without confirmed impact, this behavior can expose whether cloud visibility, identity permissions, and incident response processes are ready to explain who queried what, from where, and why.
Executive priority
Prioritize this as a cloud security and identity governance validation point. The business decision is not simply whether enumeration happened, but whether the organization can distinguish normal administrative discovery from suspicious mapping of cloud resources. Executives should ask whether cloud control-plane logs are retained, reviewed, and usable for incident response; whether identities have excessive read/list permissions; and whether audit evidence can show resource inventory access across major cloud and collaboration services.
Technical view
SOC, detection, and IR teams should validate visibility into cloud control-plane API activity that lists or queries resources. The ATT&CK description cites examples such as AWS ECS ListServices, Azure ListAllResources, Google Cloud ListInstances, and Office 365 service/resource discovery. Because no official detection text, platforms, tactics, or relationships are supplied, teams should build local baselines around expected administrative, automation, inventory, and compliance-scanning behavior, then investigate unusual enumeration by identity, source location, volume, timing, resource scope, or first-time access patterns.
Likely telemetry
- Cloud control-plane audit logs for list, describe, get, query, and resource inventory API calls
- Identity and access management logs showing which user, role, service account, or application performed enumeration
- Cloud resource inventory and configuration logs for virtual machines, storage, compute clusters, resource groups, and service listings
- Administrative console and API access records, including source IP, user agent, session context, and authentication method
- Office 365 or collaboration service audit logs where service or repository enumeration is available
Detection direction
- Confirm that control-plane audit logging is enabled and retained long enough to support investigations into cloud resource discovery.
- Tune detections around unusual breadth or frequency of resource listing rather than any single list call, because many legitimate administrators and automation tools enumerate resources.
- Correlate enumeration with identity context: new credentials, unusual roles, first-time API use, anomalous source location, or access outside normal administrative windows.
- Compare activity against known asset inventory, vulnerability management, compliance scanning, and cloud management tools to reduce false positives.
- Look for enumeration that spans multiple resource types or services, since broad mapping may be more suspicious than routine service-specific administration.
Mitigation priorities
- Ensure cloud control-plane audit logging is enabled, centralized, protected from tampering, and included in incident response procedures.
- Review identity permissions for excessive read, list, describe, and inventory capabilities, applying least privilege where operationally feasible.
- Maintain an approved inventory of administrative, compliance, vulnerability management, and automation tools that legitimately enumerate cloud services.
- Use conditional access, strong authentication, and role governance to reduce the chance that compromised identities can map the environment broadly.
- Create response playbooks for suspicious enumeration that include identity containment, session review, API key or token assessment, and follow-on search for access to sensitive resources.
Analyst notes and limits
This data component is useful as a coverage checkpoint: if teams cannot see cloud service enumeration, they may also struggle to investigate cloud reconnaissance, privilege exploration, or preparation for data access. The supplied ATT&CK object is a data component, not a technique, and no relationship context is provided, so analysis should remain focused on telemetry and defensive validation rather than assigning motive or campaign context.
MITRE did not provide an official detection section, platforms, tactics, or relationships for this object in the supplied fields. The description includes cloud and Office 365 examples, but local cloud providers, tenants, logging configuration, identity model, and administrative workflows are required to determine what is normal, suspicious, or auditable in a specific environment.
Cloud Service Enumeration
Cloud service enumeration involves listing or querying available cloud services in a cloud control plane. This activity is often performed to identify resources such as virtual machines, storage buckets, compute clusters, or other services within a cloud environment. Examples include API calls like `AWS ECS ListServices`, `Azure ListAllResources`, or `Google Cloud ListInstances`. Examples:
AWS Cloud Service Enumeration: The adversary gathers details about existing ECS services to identify opportunities for privilege escalation or exfiltration. - Azure Resource Enumeration: The adversary collects information about virtual machines, resource groups, and other Azure assets for reconnaissance purposes. - Google Cloud Resource Enumeration: The attacker seeks to map the environment and find misconfigured or underutilized resources for exploitation. - Office 365 Service Enumeration: The attacker may look for data repositories or collaboration tools to exfiltrate sensitive information.
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 | 3.0 | Current bundle | c68001416989… |
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 DC0083Open 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.