Detecting and Mitigating Container and Resource Discovery (T1613)

Container and Resource Discovery (T1613) is a Discovery technique for the Containers platform. Adversaries try to find out which containers and other resources exist: images, deployments, pods, nodes and the status of the cluster.

That map shapes everything that follows, including lateral movement and execution choices. Cutting off the map makes every later step harder.

How attackers use it

The information can come from web applications such as the Kubernetes dashboard, or from queries to the Docker and Kubernetes APIs. MITRE also notes that Docker logs may leak details about the environment, including its configuration, which services are available and which cloud provider the victim uses.

Examples listed on the page show how ordinary the commands are:

• TeamTNT checked for running containers with docker ps and for specific container names with docker inspect, and searched for Kubernetes pods on a local network.
• Hildegard used masscan to look for kubelets and then used the kubelet API to find other running containers.
• Peirates can list the pods in a namespace.
• CanisterWorm fingerprinted the environment and checked for the service account path under /var/run/secrets/kubernetes.io/serviceaccount and for the KUBERNETES_SERVICE_HOST variable.
• TeamPCP Cloud Stealer identifies Docker and Kubernetes environments in order to find credentials.

How to detect it

MITRE's analytic looks for anomalous API calls to Docker or Kubernetes, such as docker ps, kubectl get pods and kubectl get nodes, unusual account activity against the Kubernetes dashboard, and unexpected queries against container metadata endpoints. These should be correlated with user context and network activity.

Discovery is noisy and normal at the same time, so context matters:

• Listing calls from a service account that has never listed anything before.
• Large sweeps across all namespaces from a workload that only needs its own.
• Scans of kubelet ports from inside the cluster network.
• A process inside a container reading its own service account token and then calling the API.

How to reduce the risk

MITRE lists three mitigations:

1. Network segmentation. Deny direct remote access to internal systems through proxies, gateways and firewalls.
2. Limit access to the container service over the network. Use secured channels such as local Unix sockets or SSH, require TLS for API access, disable unauthenticated access to the Docker and Kubernetes APIs, and in cloud clusters use platform features to restrict the IP ranges allowed to reach the API server. Consider just-in-time access to the Kubernetes API.
3. Least privilege for dashboards. Limit dashboard visibility to the users who need it. Avoid wildcard permissions and the system:masters group, and prefer RoleBindings to ClusterRoleBindings.

Check your own environment

Read-only checks (Kubernetes with kubectl):

# What can the current identity list?
kubectl auth can-i list pods -A
kubectl auth can-i list nodes

# What can a given service account do? Replace NAMESPACE and NAME
kubectl auth can-i --list --as=system:serviceaccount:NAMESPACE:NAME

Also confirm that the Kubernetes dashboard is not reachable from untrusted networks, and that workloads which do not talk to the API are not given a service account token they do not need.

Quick check

Sources

• MITRE ATT&CK T1613 Container and Resource Discovery