Detect Container API in Sumo Logic CSE
Adversaries may gather credentials via APIs within a container environment. Docker API and Kubernetes API allow remote management of containers and cluster components. An adversary with code execution on a container or with access to an exposed Docker daemon socket (/var/run/docker.sock) can collect container logs containing credentials, environment variables with secrets, and mounted secret volumes. Via Kubernetes API with a pod's service account token, adversaries can retrieve Kubernetes Secrets containing database passwords, API keys, and credentials for cloud services. Peirates is an offensive Kubernetes tool specifically designed to exploit these APIs. Unit 42 documented unsecured Docker daemons exposing credentials.
MITRE ATT&CK
- Tactic
- Credential Access
- Technique
- T1552 Unsecured Credentials
- Sub-technique
- T1552.007 Container API
- Canonical reference
- https://attack.mitre.org/techniques/T1552/007/
Sumo Detection Query
(_sourceCategory=linux/audit OR _sourceCategory=kubernetes/audit OR _sourceCategory=container/events)
// Parse auditd EXECVE records
| parse regex field=_raw "type=EXECVE.*?a0=\"?(?<a0>[^\" ]+)\"?" nodrop
| parse regex field=_raw "a1=\"?(?<a1>[^\" ]+)\"?" nodrop
| parse regex field=_raw "a2=\"?(?<a2>[^\" ]+)\"?" nodrop
| parse regex field=_raw "a3=\"?(?<a3>[^\" ]+)\"?" nodrop
| parse regex field=_raw "a4=\"?(?<a4>[^\" ]+)\"?" nodrop
| tostring a0, a1, a2, a3, a4
| concat(a0, " ", a1, " ", a2, " ", a3, " ", a4) as CommandLine
// Pattern 1: kubectl secret access
| eval IsKubectlSecret = if(
matches(CommandLine, ".*kubectl.*(get|describe).*(secret|serviceaccount|sa|configmap).*"),
1, 0)
// Pattern 2: Docker credential extraction
| eval IsDockerCred = if(
matches(CommandLine, ".*docker.*(inspect|logs|exec|env|cp).*") AND
matches(CommandLine, ".*(pass|secret|token|credential|key).*"),
1, 0)
// Pattern 3: Direct docker.sock access
| eval IsDockerSock = if(
matches(CommandLine, ".*docker\\.sock.*"),
1, 0)
// Kubernetes API audit events
| parse field=_raw "\"verb\":\"(?<k8s_verb>[^\"]+)\"" nodrop
| parse field=_raw "\"resource\":\"(?<k8s_resource>[^\"]+)\"" nodrop
| parse field=_raw "\"username\":\"(?<k8s_user>[^\"]+)\"" nodrop
| parse field=_raw "\"namespace\":\"(?<k8s_namespace>[^\"]+)\"" nodrop
| eval IsK8sSecretAPI = if(
k8s_verb in ("get","list","watch") AND
k8s_resource in ("secrets","serviceaccounts","configmaps") AND
!matches(k8s_user, "system:serviceaccount:kube-system:.*") AND
!matches(k8s_user, "system:node:.*"),
1, 0)
| eval RiskScore = IsKubectlSecret + IsDockerCred + IsDockerSock + IsK8sSecretAPI
| where RiskScore > 0
| fields _messageTime, _sourceHost, CommandLine, k8s_user, k8s_verb, k8s_resource, k8s_namespace, IsKubectlSecret, IsDockerCred, IsDockerSock, IsK8sSecretAPI, RiskScore
| sort by RiskScore desc, _messageTime descSumo Logic query correlating four container API credential access patterns: kubectl commands targeting secrets/service accounts/configmaps, Docker CLI commands extracting environment variables or container data, direct docker.sock access by non-daemon processes, and Kubernetes API audit events for secret reads from non-system accounts. Risk scoring surfaces highest-confidence events first.
Data Sources
Required Tables
False Positives & Tuning
- GitOps controllers such as Flux or ArgoCD that continuously sync Kubernetes secrets from a Git source of truth, triggering frequent get/list operations on secrets resources
- Cluster autoscalers and admission webhooks that inspect pod specs including mounted secret volumes as part of scheduling decisions
- Legitimate sysadmin troubleshooting sessions where engineers run kubectl logs or kubectl exec to debug application crashes that happen to involve credential-related configuration
Other platforms for T1552.007
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1List All Kubernetes Secrets with kubectl
Expected signal: Linux auditd EXECVE for kubectl with 'get secrets' args. Kubernetes API audit log: GET/LIST verb on 'secrets' resource by the calling user. Network connection to Kubernetes API server (typically port 6443).
- Test 2Access Docker Container Environment Variables
Expected signal: Linux auditd EXECVE for docker with 'ps' and 'inspect' commands. Docker daemon interaction via /var/run/docker.sock. Process chain: bash -> docker ps -> xargs -> docker inspect.
- Test 3Read Kubernetes Service Account Token
Expected signal: Linux auditd OPEN syscall for /var/run/secrets/kubernetes.io/serviceaccount/token. EXECVE for cat command. Token content is a JWT that can be decoded to reveal the service account identity.
- Test 4Access Exposed Docker API
Expected signal: Linux auditd EXECVE for curl with localhost:2375 (Docker TCP port). Network connection to 127.0.0.1:2375. If Docker TCP API is exposed on 0.0.0.0:2375, this represents a critical misconfiguration.
References (8)
- https://attack.mitre.org/techniques/T1552/007/
- https://docs.docker.com/engine/api/
- https://kubernetes.io/docs/reference/access-authn-authz/rbac/
- https://github.com/inguardians/peirates
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1552.007/T1552.007.md
- https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/
- https://unit42.paloaltonetworks.com/attackers-tactics-and-techniques-in-unsecured-docker-daemons-revealed/
- https://falco.org/docs/
Unlock Pro Content
Get the full detection package for T1552.007 including response playbook, investigation guide, and atomic red team tests.