Mini Shai-HuludS9043 ↗
Has gathered unsecured API keys stored in container orchestrators.1
- Tactic
- Credential Access
- Platform
- Containers
- Version
- 1.2
- Created
- 31 March 2021
- Last modified
- 24 October 2025
- Contributors
- Center for Threat-Informed Defense (CTID); Jay Chen, Palo Alto Networks; Yossi Weizman, Azure Defender Research Team
ReconResource DevInitial AccessExecutionPersistencePriv EscStealthDef ImpairmentCred AccessDiscoveryLateral MoveCollectionC2ExfiltrationImpact
0
Threat groupsNone recorded
Threat groupsNone recorded · 29% of ATT&CK techniques have none either.0
CampaignsNone recorded
CampaignsNone recorded · 54% of ATT&CK techniques have none either.3
Tools & malware57th pct
Tools & malware57th percentile · 57% of ATT&CK techniques have this many tools implementing them or fewer.8
Detection rules71st pct
Detection rules71st percentile · 71% of ATT&CK techniques have this many detection rules written or fewer.Container API MITRE reference T1552.007
57th pctamong all ATT&CK techniques for number of tools
Offense vs defense T1552.007
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Range
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
Campaigns · 0Sigma rules (cumulative) · 4Splunk ESCU (cumulative) · 4
first rule: 2021 Q4Container API detection strategy DET0198
MITRE names one behaviour worth catching for this technique and breaks it into 1 analytic, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detect Abuse of Container APIs for Credential Access
1 platform
AN0571 · Containers
Detection correlates anomalous Docker or Kubernetes API requests with access to logs, secrets, or service accounts. Observes unauthorized use of docker logs, kubectl get secrets, or direct API calls to Kubernetes API server endpoints. Identifies behavioral patterns where adversaries escalate from basic pod/container interaction to privileged API calls exposing sensitive credential material.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account AuthenticationDC0002 | kubernetes:apiserver | get/list requests to /api/v1/secrets or /api/v1/namespaces/*/serviceaccounts |
| Process CreationDC0032 | kubernetes:apiserver | exec into pod followed by secret retrieval via API |
| Application Log ContentDC0038 | kubernetes:orchestrator | Access to orchestrator logs containing credentials (Docker/Kubernetes logs) |
| Command ExecutionDC0064 | docker:api | docker logs access or container inspect commands from non-administrative users |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| UserContext | Tune to exclude known orchestrator admin service accounts or CI/CD pipelines that legitimately access secrets |
| NamespaceScope | Restrict detection to sensitive namespaces (e.g., kube-system, production apps) |
| TimeWindow | Adjust correlation timing between pod execution and subsequent API secret retrieval |
| SourceIP | Filter based on allowed internal API calls vs anomalous external or cross-cluster access |
Limit communications with the container service to managed and secured channels, such as local Unix sockets or remote access via SSH. Require secure port access to communicate with the APIs over TLS by disabling unauthenticated access to the Docker API and Kubernetes API Server. In Kubernetes clusters deployed in cloud environments, use native cloud platform features to restrict the IP ranges that are permitted to access to API server. Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.
Network SegmentationM1030
Deny direct remote access to internal systems through the use of network proxies, gateways, and firewalls.
Use the principle of least privilege for privileged accounts such as the service account in Kubernetes. For example, if a pod is not required to access the Kubernetes API, consider disabling the service account altogether.
Enforce authentication and role-based access control on the container API to restrict users to the least privileges required. When using Kubernetes, avoid giving users wildcard permissions or adding users to the system:masters group, and use RoleBindings rather than ClusterRoleBindings to limit user privileges to specific namespaces.
Tests3Executorsbash 2 · sh 1Need elevation0 of 3Have prerequisites3Have cleanup1Platformscontainers, linux
| # | Test | Platform | Executor | Elevation | Prereqs | Cleanup | Ref | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 01 | List All Secrets | containers | bash | — | 1 | — | ||||||||||
A Kubernetes secret is an object that lets users store and manage sensitive information, such as passwords and connection strings in the cluster. Secrets can be consumed by reference in the pod configuration. Attackers who have permissions to retrieve the secrets from the API server (by using the pod service account, for example) can access sensitive information that might include credentials to various services or provide further access to the cluster.
More information about secrets.
This test will make a request to the Kubernetes api at the Attack command kubectl get secrets --all-namespaces Prerequisite kubectl must be installed Check which kubectl Satisfy echo "kubectl not installed, please install kubectl (https://kubernetes.io/docs/tasks/tools/)" GUIDde1f6cdc-76bb-4629-a247-099e9474fd1c | ||||||||||||||||
| 02 | ListSecrets | containers | bash | — | 1 | — | ||||||||||
A Kubernetes secret is an object that lets users store and manage sensitive information, such as passwords and connection strings in the cluster. Secrets can be consumed by reference in the pod configuration. Attackers who have permissions to retrieve the secrets from the API server (by using the pod service account, for example) can access sensitive information that might include credentials to various services. Input arguments
Attack command kubectl get secrets -n #{namespace}
Prerequisite kubectl must be installed Check which kubectl Satisfy echo "kubectl must be installed manually" GUID4123fdff-5bd5-4363-a6da-7823a5488798 | ||||||||||||||||
| 03 | Cat the contents of a Kubernetes service account token file | linux | sh | — | 6 | Yes | ||||||||||
Access the Kubernetes service account access token stored within a container in a cluster. Attack command kubectl --context kind-atomic-cluster exec atomic-pod -- cat /run/secrets/kubernetes.io/serviceaccount/token Cleanup command kubectl --context kind-atomic-cluster delete pod atomic-pod Prerequisite Verify docker is installed. Check which docker Satisfy if [ "" == "`which docker`" ]; then echo "Docker Not Found"; if [ -n "`which apt-get`" ]; then sudo apt-get -y install docker ; elif [ -n "`which yum`" ]; then sudo yum -y install docker ; fi ; else echo "Docker installed"; fi Prerequisite Verify docker service is running. Check sudo systemctl status docker Satisfy sudo systemctl start docker Prerequisite Verify kind is in the path. Check which kind Satisfy curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.10.0/kind-linux-amd64 chmod +x ./kind mv kind /usr/bin/kind Prerequisite Verify kind-atomic-cluster is created Check sudo kind get clusters Satisfy sudo kind create cluster --name atomic-cluster Prerequisite Verify kubectl is in path Check which kubectl Satisfy curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" chmod +x ./kubectl mv kubectl /usr/bin/kubectl Prerequisite Verify atomic-pod is running. Check kubectl --context kind-atomic-cluster get pods |grep atomic-pod Satisfy kubectl --context kind-atomic-cluster run atomic-pod --image=alpine --command -- sleep infinity GUID9647d7c7-e9b4-41cb-b044-7a10d64c7b41 | ||||||||||||||||
Tests from Atomic Red Team (MIT licence) · technique definition