MITRE ATT&CK T1613 Container and Resource Discovery: Spotting Enumeration Early

The first thing an attacker does after landing in a container or reaching an exposed Docker or Kubernetes API is ask what else is there, and that question is visible in your logs if you collect the right ones. MITRE ATT&CK T1613 Container and Resource Discovery is a Discovery (TA0007) technique on the Containers platform: adversaries enumerate containers, images, deployments, pods, nodes and cluster status through the Kubernetes dashboard, the Docker and Kubernetes APIs, or leaky container logs. What they learn decides their next move: which pods hold service account tokens, which nodes to escape to, where to deploy a miner. This guide covers the technique as ATT&CK v20 defines it, real cases, the detection analytic and how to tune it, mitigations and testing. It is for detection engineers, platform and SOC teams. For investigating a container incident after the fact, see the Container and Kubernetes Forensics Guide.

Key takeaways

• Discovery is the cheapest place to catch a container intrusion. It happens early, it needs API calls you can log, and legitimate callers are a short, knowable list.
• Service accounts are both the tool and the signal. Most enumeration uses a pod's mounted service account token or a stolen kubeconfig, so an identity listing pods or nodes it has never listed before is the core alert.
• Unauthenticated APIs make discovery invisible. Hildegard used anonymous kubelet access and the TeamTNT worm used open Docker APIs: there was no meaningful identity to alert on.
• ATT&CK lists three mitigations. M1035 Limit Access to Resource Over Network, M1018 User Account Management (RBAC least privilege) and M1030 Network Segmentation.
• Tune with ATT&CK's own levers. The v20 analytic AN1352 names an allow list of expected identities, a correlation window and a pod query threshold.

What T1613 covers

ATT&CK describes adversaries discovering containers and other resources in a container environment, including images, deployments, pods, nodes and cluster status, viewed through web applications such as the Kubernetes dashboard or queried through the Docker and Kubernetes APIs. It adds that Docker logs may leak the environment's configuration, available services and the cloud provider in use. T1613 has no sub-techniques. Nearby techniques have their own pages: MITRE ATT&CK T1609 Container Administration Command for running commands in containers, MITRE ATT&CK T1610 Deploy Container, T1611 Escape to Host Defensive Guide, T1552.007 Container API for credentials, and T1580 Cloud Infrastructure Discovery for the cloud control plane around the cluster.

How adversaries have used it

ATT&CK v20 procedure examples, with the research behind them:

• TeamTNT (G0139): ATT&CK records the group checking for running containers and specific container names through Docker commands (citing Trend Micro) and searching for Kubernetes pods on a local network (citing Cisco Talos). ATT&CK describes TeamTNT as focused on cloud and container resources for cryptocurrency mining since at least October 2019. In August 2020 Cado Security reported a TeamTNT worm that used masscan to find Docker APIs exposed without access control, started containers on them, and uploaded AWS command line credential and configuration files from each host. See TeamTNT Worm 2020.
• Hildegard (S0601): Unit 42 reported in February 2021 a TeamTNT-attributed campaign that entered through kubelets accepting anonymous requests, used masscan to find kubelets on port 10250 across the internal network, and used the kubelet API to list running containers on each node before spreading a miner and searching for cloud keys, Docker credentials and Kubernetes service tokens.
• Peirates (S0683): an open-source Kubernetes penetration testing tool that ATT&CK records enumerating pods in a namespace. Its presence on a node without an authorised test is a strong signal.
• TeamPCP (G1056) in 2026: ATT&CK records TeamPCP Cloud Stealer (S9041) identifying Docker and Kubernetes environments for credentials, and CanisterWorm (S9042) fingerprinting environments for Kubernetes by checking for a mounted service account path and the KUBERNETES_SERVICE_HOST variable (citing Unit 42 and Aikido research from March 2026). These payloads arrived through compromised CI/CD and security tooling, which means discovery started inside build runners and clusters, not from the Internet. See the TeamPCP Threat Actor Profile Guide and the Trivy Supply Chain Attack 2026 analysis.

Two exposure cases show why the dashboard is in the technique description. At Tesla, disclosed by RedLock in February 2018, a Kubernetes administration console without password protection let attackers find AWS credentials stored in a pod and run mining software (Tesla Kubernetes Cryptojacking 2018). In the Kubeflow campaign Microsoft disclosed in June 2020, users had exposed the internal dashboard through a public load balancer, and the attacker used the mounted service account in notebook containers, which by default could deploy containers in its namespace, to spread an XMRig image across tens of clusters (Kubeflow Cryptomining Attacks 2020).

Where identity fits

Container discovery is almost always performed by a non-human identity. A pod's service account token, a CI/CD deployer's kubeconfig, a cloud role mapped into the cluster, or an anonymous identity when authentication is off. That makes three identity controls decisive. Workloads that never call the Kubernetes API should not mount a token at all (automountServiceAccountToken: false). Workloads that do should have Roles scoped to their namespace and verbs. Human and pipeline access should use short-lived credentials tied to a named owner rather than long-lived kubeconfigs copied onto laptops and runners. See the Kubernetes Service Account Token Guide, the Kubernetes RBAC Guide and the Kubernetes NHI Security Guide.

What to detect and where

ATT&CK v20 detection strategy DET0490 has one analytic, AN1352, on the Containers platform. It points at anomalous Docker and Kubernetes API calls, unusual account activity against the dashboard and unexpected queries against container metadata endpoints, correlated with user context and network activity.

NHI Mgmt Group recommends turning that into these concrete detections:

• New lister: a service account or user performing list or watch on pods, nodes, secrets or namespaces cluster-wide for the first time. Build the allow list from 14 to 30 days of audit history; controllers and monitoring agents are stable and few.
• Workload identity asking about itself: a pod's service account creating SelfSubjectAccessReview or SelfSubjectRulesReview objects, which is how tooling checks "what can I do". Application workloads rarely need this.
• Breadth burst: one identity touching many resource types or namespaces within the TimeWindow, especially when it ends with a create on pods or exec.
• Forbidden noise: bursts of 403 responses for one identity across resource types; attackers probe permissions, applications do not.
• Anonymous or unexpected source: any request as system:anonymous, and API or kubelet requests from source IPs outside node, control plane and administrator ranges.
• Docker socket use: processes other than the expected agents connecting to the Docker socket, and any traffic to TCP 2375 from outside the host.
• Runtime signal: a container reading its service account token and then making outbound connections to the API server when its image never has before. See the Container Runtime Security Guide.

Audit policy matters: the Kubernetes audit log only records what the policy asks for. Log at least Metadata level for reads of pods, nodes, secrets and RBAC objects, and keep request-level detail for writes. Managed services expose these logs through their cloud logging products and some do not enable them by default, so check. Detection queries and audit policy examples are in the Kubernetes Audit Log Detection Guide.

Noise sources to allow list explicitly: kube-controller-manager and scheduler, CNI and CSI agents, ingress controllers, GitOps and deployment controllers, monitoring and security agents, backup tools, and the identities your CI/CD pipelines use. Any change to that list should be a reviewed change.

Mitigations

The Kubernetes documentation states that, by default, requests to the kubelet's HTTPS endpoint that other authentication methods do not reject are treated as anonymous, with the username system:anonymous. Managed services configure this for you; self-managed clusters must set it. See Kubernetes Network Policy Guide for pod egress controls.

Implementation sequence

1. Close unauthenticated paths first: scan your own ranges for Docker API on 2375 and kubelet or dashboard endpoints reachable from outside the cluster network. These defeat every identity-based detection.
2. Turn on audit logging for every cluster with a policy covering reads of pods, nodes, secrets and RBAC objects, and ship it to the SIEM. Check retention.
3. Baseline for two to four weeks: record which identities list which resources, at what scope and volume.
4. Deploy detections in alert-only mode with the allow list, then review every hit with the platform team and fold genuine callers into the list.
5. Reduce what discovery can reach: disable token automount where not needed, replace ClusterRoleBindings with namespace RoleBindings, apply network policies to API server and kubelet egress.
6. Promote to paging alerts for anonymous access, new cluster-wide listers and workload identities running access reviews. Rollback is removing the alert rule; the logging stays.

Small teams on one managed cluster can start with the provider's audit log, a handful of the detections above and token automount off by default. Large estates with many clusters need the allow list managed as code, per cluster, owned by the platform team.

How to test

• Controlled enumeration: from an authorised test pod with a dedicated service account, list pods and nodes, then run an access review. Confirm each detection fires with the right identity and namespace.
• Permission check: confirm application service accounts get 403 on cluster-wide pod and secret listing.
• Exposure scan: confirm no Docker API, kubelet or dashboard is reachable from the Internet or from user networks.
• Adversary emulation: map an exercise to T1613 with your red team or an emulation plan, and measure time from first discovery call to alert.

Metrics

• Percentage of clusters with audit logging enabled and reaching the SIEM.
• Number of identities with cluster-wide list on pods, nodes or secrets, trend over time.
• Percentage of pods with a service account token mounted that actually call the API.
• Count of unauthenticated Docker, kubelet or dashboard endpoints found by scanning (target zero).
• Time from a test discovery call to SOC alert.

Common failure patterns

• Exposed management planes: open dashboards and Docker APIs were the entry in the Tesla, Kubeflow and TeamTNT cases.
• Default token mounts with broad roles: the Kubeflow notebook service account could deploy containers by default, which turned one exposure into lateral movement.
• Audit logs off on managed clusters: the activity happened, but nothing recorded it.
• Allow lists that include whole namespaces: exempting kube-system wholesale hides an attacker who lands in a system pod.
• Trusting CI/CD runners: TeamPCP's 2026 payloads started discovery from compromised build and security tooling, identities usually allow listed.

Framework mapping

Practitioner checklist

• No Docker API, kubelet or dashboard is reachable without authentication or from untrusted networks.
• Kubelet anonymous authentication is disabled and Webhook authorisation is on in self-managed clusters.
• Kubernetes audit logging is on everywhere, covering reads of pods, nodes, secrets and RBAC objects.
• An allow list of expected discovery identities exists per cluster, managed as code.
• Alerts exist for new cluster-wide listers, anonymous requests and workload access reviews.
• Token automount is off unless a workload calls the API.
• Cluster-wide bindings are reviewed quarterly; no wildcard roles or system:masters membership for people or pipelines.
• Network policies limit pod access to the API server, kubelet and metadata endpoints.

Standards and references

• MITRE ATT&CK: T1613 Container and Resource Discovery
• MITRE ATT&CK: G0139 TeamTNT
• Kubernetes: Auditing
• Kubernetes: Kubelet authentication and authorization
• Palo Alto Networks Unit 42: Hildegard, TeamTNT Cryptojacking Malware Targeting Kubernetes
• MITRE ATT&CK: G1056 TeamPCP
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: ATT&CK Discovery Tactic (TA0007) Guide, T1580 and T1619 Cloud Infrastructure and Storage Discovery Guide, Kubernetes Security Guide, Kubernetes Cluster Compromise Playbook and Cryptojacking Guide.