DC0091: Container Enumeration
"Container Enumeration" data component captures events and actions related to listing and identifying active or available containers within a containerized environment. This includes information about running, stopped, or configured containers, such as their names, IDs, statuses, or associated images. Monitoring this activity is crucial for detecting unauthorized discovery or reconnaissance efforts. Examples:
- Docker Example: `docker ps`, `docker ps -a` - Kubernetes Example: `kubectl get pods`, `kubectl get deployments` - Cloud Container Services Example - AWS ECS: API Call: ListTasks or ListContainers - Azure Kubernetes Service: API Call: List pod or container instances. - Google Kubernetes Engine (GKE): API Call: Retrieve deployments and their associated containers.
Analyst context for executives and security teams
Container enumeration is the visibility point for seeing when someone or something lists containers, pods, deployments, tasks, or container instances. For leaders, this matters because container inventories often reveal application topology, workloads, images, and operational state. If unauthorized, this type of discovery can help an intruder understand where business-critical services run before taking further action.
Executive priority
Prioritize this as a cloud and container security visibility question: can the organization prove who is querying container inventory, from where, and under what authorization? The business value is not only detection; these records support incident scoping, access review, audit evidence, and validation that container management interfaces are monitored. Because ATT&CK provides no specific detection logic or relationships for this object, teams should treat it as a required evidence class rather than a complete detection by itself.
Technical view
SOC, cloud security, and IR teams should validate collection of container listing activity from container runtimes, Kubernetes control-plane/audit sources, and cloud container service APIs where used. The official examples include Docker commands such as `docker ps` and `docker ps -a`, Kubernetes queries such as `kubectl get pods` and `kubectl get deployments`, and cloud API activity such as AWS ECS ListTasks/ListContainers, Azure pod or container instance listing, and GKE deployment/container retrieval. Detection engineering should focus on whether enumeration is expected for the actor, role, source, time, and workload context, since routine administrator, CI/CD, monitoring, and orchestration activity may look similar.
Likely telemetry
- Container runtime command or API activity showing container list/enumeration requests
- Kubernetes audit/control-plane events for pod, deployment, and container listing
- Cloud provider API logs for container service list or retrieve operations
- Identity and access records tying enumeration activity to users, roles, service accounts, or automation
- Source context such as management host, CI/CD runner, administrative workstation, or workload identity
Detection direction
- Confirm that enumeration events are logged with actor identity, source, target namespace/project/cluster/service, and result status.
- Baseline expected enumeration by administrators, monitoring tools, CI/CD systems, and orchestration components to reduce false positives.
- Look for unusual enumeration scope, frequency, source location, or identity, especially broad listing across clusters, namespaces, services, or accounts.
- Correlate enumeration with authentication, privilege changes, new access tokens, or subsequent container-management actions when available.
- Document blind spots where local runtime commands, Kubernetes audit logs, or cloud API logs are not collected or are retained for too short a period.
Mitigation priorities
- Restrict container inventory visibility using least-privilege access for users, service accounts, and automation.
- Require strong identity governance around container management interfaces and cloud container service APIs.
- Enable and retain audit logging for container runtime, Kubernetes, and cloud container service enumeration events where applicable.
- Separate routine automation identities from human administrative identities so SOC teams can distinguish expected from suspicious enumeration.
- Review access and logging coverage during incident readiness, compliance evidence collection, and cloud/container security assessments.
Analyst notes and limits
This data component is useful as a coverage and evidence requirement: it tells defenders what class of activity should be observable in containerized environments. Its value increases when combined with identity, source, and authorization context. No ATT&CK relationships were supplied, so this take does not tie the component to specific techniques, tactics, actors, or campaigns.
The supplied ATT&CK object has no official detection text, no specified platforms or tactics, and no relationship context. Local architecture determines which telemetry sources exist and which enumeration patterns are normal. This summary should not be read as evidence of active exploitation or as a complete detection strategy.
Container Enumeration
"Container Enumeration" data component captures events and actions related to listing and identifying active or available containers within a containerized environment. This includes information about running, stopped, or configured containers, such as their names, IDs, statuses, or associated images. Monitoring this activity is crucial for detecting unauthorized discovery or reconnaissance efforts. Examples:
- Docker Example: `docker ps`, `docker ps -a` - Kubernetes Example: `kubectl get pods`, `kubectl get deployments` - Cloud Container Services Example - AWS ECS: API Call: ListTasks or ListContainers - Azure Kubernetes Service: API Call: List pod or container instances. - Google Kubernetes Engine (GKE): API Call: Retrieve deployments and their associated containers.
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 | 66be6f4539a3… |
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 DC0091Open 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.