DC0037: Pod Enumeration
Extracting a list of running or existing pods within a containerized cluster environment. Pods are the smallest deployable units in a Kubernetes cluster and typically represent an application or workload. Enumeration of pods provides insight into the structure and state of applications running in the cluster, such as the names of pods, their namespaces, and their associated metadata.
*Data Collection Measures:*
- Kubernetes API Server Audit Logs: - Enable Audit Logging in Kubernetes to capture API requests, such as GET `/api/v1/pods`. - Container Runtime Logs: - Collect runtime-level logs from tools like CRI-O, containerd, or Docker, which might show relevant API calls for pod enumeration. - EDR and SIEM: - Endpoint Detection and Response (EDR) tools, if configured with cluster-level visibility, can monitor user commands like `kubectl get pods`. - SIEM platforms (e.g., Splunk) can ingest Kubernetes API logs to detect enumeration patterns. - Host-Based Monitoring: - Monitor processes and commands executed on nodes where `kubectl` is installed using tools like auditd, Sysmon for Linux, or kernel modules.
Analyst context for executives and security teams
Pod Enumeration is evidence that someone or something is listing Kubernetes pods to understand what workloads exist, where they run, and how applications are organized across namespaces. For leaders, this matters because pod visibility can reveal sensitive operational structure and may be an early signal during investigation of suspicious activity in a containerized environment. The practical question is whether the organization can prove who queried pod information, from where, and whether that access was expected.
Executive priority
Prioritize this as a cloud/container visibility and audit-readiness issue. If Kubernetes audit logging, runtime logs, and host command monitoring are incomplete, incident responders may not be able to distinguish routine administration from suspicious reconnaissance. Security leaders should validate that Kubernetes API activity is retained, attributable to users or service accounts, and available to the SOC/SIEM for investigation and compliance evidence.
Technical view
This data component centers on extraction of running or existing pod lists in a Kubernetes cluster, including pod names, namespaces, and metadata. SOC and detection teams should validate collection from Kubernetes API Server Audit Logs, especially requests such as GET /api/v1/pods, and correlate those events with identity context, source location, namespace, and expected administrative patterns. Where kubectl is installed on nodes or administrative hosts, host-based process and command telemetry can help identify local pod enumeration activity. Runtime-level logs from CRI-O, containerd, or Docker may provide supporting context, but ATT&CK does not provide an official detection analytic for this object.
Likely telemetry
- Kubernetes API Server Audit Logs capturing pod-related API requests
- API request metadata such as user, service account, source address, verb, resource, namespace, and timestamp where available
- Container runtime logs from CRI-O, containerd, or Docker
- EDR telemetry with cluster-level visibility, including command execution such as kubectl get pods
- Host-based process and command monitoring on systems where kubectl is installed
Detection direction
- Confirm Kubernetes audit logging is enabled and captures pod list/read requests rather than only high-severity or write events.
- Baseline normal pod enumeration by administrators, automation, controllers, and service accounts to reduce false positives.
- Tune for unusual enumeration patterns such as unexpected users, namespaces, sources, timing, or broad cluster-wide listing where local policy defines what is abnormal.
- Correlate API audit events with host command telemetry when kubectl is used from managed systems.
- Validate SIEM parsing preserves Kubernetes fields needed for investigation, including user or service account, verb, resource, namespace, and source context.
Mitigation priorities
- Ensure Kubernetes API Server Audit Logging is enabled and retained for investigation and audit evidence.
- Restrict and periodically review access that can list pods, using least-privilege principles for users and service accounts.
- Centralize Kubernetes audit logs and relevant host/runtime telemetry into the SIEM or managed detection workflow.
- Monitor administrative hosts and cluster nodes where kubectl or similar tooling is installed.
- Review logging coverage during incident response readiness exercises to confirm responders can attribute pod enumeration activity.
Analyst notes and limits
This object is a data component, not a technique, and no ATT&CK tactics, platforms, relationships, or official detection logic were supplied. The strongest decision value is in validating whether the organization collects and correlates Kubernetes audit, runtime, EDR, SIEM, and host-based telemetry sufficient to investigate pod listing activity.
The supplied ATT&CK fields do not support claims about active exploitation, specific adversaries, impact, or guaranteed detection. Platforms are not specified in the object, although the description is Kubernetes-focused. Local cluster architecture, RBAC model, logging configuration, and operational baselines are required to determine risk and detection quality.
Pod Enumeration
Extracting a list of running or existing pods within a containerized cluster environment. Pods are the smallest deployable units in a Kubernetes cluster and typically represent an application or workload. Enumeration of pods provides insight into the structure and state of applications running in the cluster, such as the names of pods, their namespaces, and their associated metadata.
*Data Collection Measures:*
- Kubernetes API Server Audit Logs: - Enable Audit Logging in Kubernetes to capture API requests, such as GET `/api/v1/pods`. - Container Runtime Logs: - Collect runtime-level logs from tools like CRI-O, containerd, or Docker, which might show relevant API calls for pod enumeration. - EDR and SIEM: - Endpoint Detection and Response (EDR) tools, if configured with cluster-level visibility, can monitor user commands like `kubectl get pods`. - SIEM platforms (e.g., Splunk) can ingest Kubernetes API logs to detect enumeration patterns. - Host-Based Monitoring: - Monitor processes and commands executed on nodes where `kubectl` is installed using tools like auditd, Sysmon for Linux, or kernel modules.
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 | 976988ba82ac… |
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 DC0037Open 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.