How to correlate Kubernetes audit logs with container runtime data
Elastic Security Labs shows how to join Kubernetes audit logs with Defend for Containers runtime data to investigate service account abuse and container escapes.
Elastic Security Labs demonstrates correlating Kubernetes audit logs with Defend for Containers (D4C) runtime telemetry in Elastic. In an Amazon EKS lab, a compromised workload service account performed discovery, read secrets, minted a token, created a privileged pod, and execed into it to attempt a container escape via nsenter and chroot. The escape wrappers appeared only in the decoded Kubernetes audit requestURI, not in runtime process events. The post covers join fields, prebuilt EQL sequence rules, and continues the control-plane correlation thread from the TeamPCP container attack scenario and the Hugging Face intrusion write-up.
- Kubernetes audit logs show who called APIs and which objects changed; D4C shows what ran inside containers
- nsenter and chroot escape wrappers appeared in audit logs but not in runtime process events
- Two join patterns: pod caller identity, and service account plus objectRef, scoped by namespace, cluster, and time window
- Prebuilt EQL rules like Service Account Token or Certificate Access Followed by Kubernetes API Request use these joins
- ATT&CK
- T1613 Container and Resource DiscoveryT1552.007 Container APIT1610 Deploy ContainerT1609 Container Administration CommandT1611 Escape to Host
- Vendors
- Elastic
- Victims
- Hugging Face
- Organizations
- Elastic Security LabsTeamPCP
From the original article
12 min read at elastic.co
Two fields join the Kubernetes API to what ran inside the pod, and one turns up a container escape your process events never recorded.
By Isai Anthony · elastic.co
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.