AN1352: Analytic 1352
Detection of adversary attempts to enumerate containers, pods, nodes, and related resources within containerized environments. Defenders may observe anomalous API calls to Docker or Kubernetes (e.g., 'docker ps', 'kubectl get pods', 'kubectl get nodes'), unusual account activity against the Kubernetes dashboard, or unexpected queries against container metadata endpoints. These events should be correlated with user context and network activity to reveal resource discovery attempts.
Analyst context for executives and security teams
AN1352 focuses on spotting attempts to list containers, pods, nodes, and related resources in containerized environments. For leaders, this matters because resource discovery is often how an intruder learns what workloads exist, where sensitive services may run, and which cluster paths could support later movement or disruption. The decision value is whether the organization can see and explain unusual Docker, Kubernetes, dashboard, or metadata-query activity before it becomes an incident with broader operational impact.
Executive priority
Prioritize this analytic where containers support critical applications or regulated workloads. Executives should ask whether Kubernetes and Docker activity is logged centrally, whether user and service-account context is available during investigations, and whether SOC teams can distinguish normal administrative inventory from suspicious discovery. This supports incident readiness, cloud/container security assurance, and compliance evidence around monitoring of privileged and operational access.
Technical view
For SOC, detection engineering, and IR teams, validate visibility for anomalous API calls and commands associated with container resource enumeration, including Docker and Kubernetes activity such as container, pod, and node listing, Kubernetes dashboard access, and queries to container metadata endpoints. Because no ATT&CK detection logic is provided, teams should build environment-specific baselines by account, namespace, cluster, source host, and network path, then correlate enumeration events with user context and surrounding network activity as described in the object.
Likely telemetry
- Kubernetes API server audit logs showing resource listing or discovery-oriented requests
- Docker daemon or host command/activity logs where available
- Kubernetes dashboard authentication and activity logs
- Container metadata endpoint access logs or network telemetry
- Identity context for users, service accounts, roles, and source locations
Detection direction
- Confirm Kubernetes and Docker control-plane events are actually collected, retained, and searchable for container, pod, node, and related resource enumeration.
- Tune detections around unexpected use by accounts, service accounts, source systems, namespaces, or time windows rather than command strings alone.
- Correlate discovery-like API activity with dashboard access and metadata endpoint queries to reduce blind spots across control-plane, UI, and network views.
- Account for legitimate administrative, deployment, monitoring, and inventory tooling to reduce false positives.
- Review whether ephemeral containers, short-lived workloads, or unmanaged clusters create logging gaps that would hide enumeration activity.
Mitigation priorities
- Establish reliable audit logging for Kubernetes, Docker, dashboard, and metadata access before relying on detections.
- Limit container and cluster resource visibility using least-privilege roles for users and service accounts.
- Review exposure and access paths to Kubernetes dashboards, APIs, and metadata endpoints.
- Create IR playbooks for suspicious container resource discovery that include account validation, token review, source workload identification, and network context collection.
- Use periodic control validation to prove that expected enumeration events generate usable evidence in the SOC workflow.
Analyst notes and limits
The supplied object is a detection analytic for Containers and describes discovery of containerized resources. It does not specify tactics, relationships, adversary groups, malware, campaigns, mitigations, or an official detection query. The practical emphasis is therefore on telemetry validation, baselining, and correlation across Kubernetes/Docker activity, dashboard access, metadata queries, identity context, and network activity.
This take is limited to the official STIX fields, the MITRE external reference, and the provided relationship context. No active exploitation, attribution, impact outcome, or guaranteed detection coverage is implied. Local cluster architecture, logging configuration, RBAC design, and operational tooling are required to determine actual risk and detection quality.
Analytic 1352
Detection of adversary attempts to enumerate containers, pods, nodes, and related resources within containerized environments. Defenders may observe anomalous API calls to Docker or Kubernetes (e.g., 'docker ps', 'kubectl get pods', 'kubectl get nodes'), unusual account activity against the Kubernetes dashboard, or unexpected queries against container metadata endpoints. These events should be correlated with user context and network activity to reveal resource discovery attempts.
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 | b7a07ec48286… |
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 AN1352Open 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.