PLAYBOOKSNETHOSTATTRIBDETECT
← all playbooks
ENVIRONMENT
Kubernetes and Container
Containers are ephemeral. If an attacker compromises a pod, pulls a tool, runs an exploit, and the pod terminates ten minutes later, the telemetry is gone forever unless you are capturing runtime behavior at the kernel level. The blind spot infrastructure.
K8s audit logs · eBPF / Falco / Tetragon · container escape · API server abuse · service account token theft
Why Kubernetes is a hunting nightmare

Traditional endpoint telemetry assumes the host persists. Containers don't. A pod can spin up, execute a workload, and terminate before a scheduled scan runs. If an attacker compromises a container, the evidence dies with the container unless you have runtime monitoring hooked at the kernel level (eBPF) or API-level audit logging capturing every request.

The default posture is weak. Developers routinely run containers as root (privileged), mount the host filesystem for convenience, leave the internal Kubernetes API service account tokens accessible inside every pod at /var/run/secrets/kubernetes.io/serviceaccount/token, and deploy with overly permissive RBAC roles. Every one of these defaults is an attack surface.

Cryptomining is the canary. If you find unauthorized cryptominers running in your cluster, you have a much bigger problem than wasted compute. The miner proves someone can deploy arbitrary workloads. The same access that deploys a miner deploys a reverse shell, a data exfiltration tool, or a lateral movement pivot. Treat every cryptominer as evidence of a compromised cluster, not just a nuisance.
Hunt checklist
  1. 1. Hunt for container escapes Attackers break out of container namespaces to control the underlying node. Search eBPF/Falco telemetry for: processes inside containers accessing host PID namespace, mount namespace escapes via /proc/1/root, writes to host filesystem paths from container contexts, and nsenter or chroot execution inside containers. Falco: container.id != host AND (proc.name in (nsenter, chroot) OR fd.name startswith /proc/1/root)
  2. 2. Detect shells spawning inside production containers Production containers should not have interactive shells. Any bash, sh, or interactive process inside a running production pod is suspicious. Configure Falco or Tetragon to alert on shell spawning inside containers. Falco: container.id != host AND proc.name in (bash, sh, dash) AND not user.login
  3. 3. Audit Kubernetes API server requests Enable K8s audit logging and search for: anomalous User-Agent strings querying the API, rapid impersonate verb requests, unauthorized create or exec requests for pods, and requests from service accounts that don't normally interact with the API. API server abuse is how attackers spin up rogue pods. K8s audit log: verb=create resource=pods from unexpected service accounts
  4. 4. Hunt for service account token theft Every pod gets a service account token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token by default. Attackers read this token to authenticate to the K8s API from inside the pod. Search for: processes reading the token file, outbound connections to the K8s API endpoint (typically 443 on the cluster IP), and token use from unexpected source pods. Falco: open read /var/run/secrets/kubernetes.io/ · K8s audit: bearer token from unexpected source
  5. 5. Check for privileged containers and host mounts Audit running pods for: privileged: true in the security context, host PID/network/IPC namespace sharing, host filesystem mounts (especially /, /etc, /var/run/docker.sock), and containers running as UID 0 (root). Each is an escape vector. kubectl get pods -o json | jq for securityContext.privileged
  6. 6. Monitor for rogue pod deployment Search K8s audit logs for pod creation events that don't match your CI/CD pipeline: pods created by service accounts other than your deployment pipeline, pods with images from unexpected registries, pods with hostNetwork or hostPID enabled, and DaemonSets or CronJobs created outside change management. K8s audit: verb=create resource=pods NOT from CI/CD service account
  7. 7. Hunt for lateral movement between namespaces Kubernetes namespaces provide logical isolation, not network isolation (by default). Search for: network connections between pods in different namespaces that don't have a defined communication path, DNS lookups for services in other namespaces, and RBAC bindings that grant cross-namespace access. Network policy audit · Cilium/Calico flow logs · K8s RBAC review
  8. 8. Verify image integrity and supply chain Compromised container images are a supply chain attack vector. Check for: images pulled from public registries without signature verification, images with known vulnerabilities (Trivy, Grype scans), base images that have been modified since initial deployment, and images with embedded cryptominers or backdoors. Supply Chain playbook · Cosign signature verification · Trivy/Grype scanning
Required telemetry

eBPF-based runtime monitoring (Falco, Tetragon, Tracee). Hooks directly into the Linux kernel of the host nodes. Captures process execution, file access, network connections, and syscalls from inside containers in real time, regardless of container lifecycle. This is the primary detection source. Without it, you are blind to in-container activity.

Kubernetes audit logs. API server request logging. Captures every kubectl command, every API call, every pod creation/deletion. Must be configured explicitly (not enabled by default on most distributions). Store externally so they survive cluster compromise.

Network flow logs (Cilium, Calico). Pod-to-pod and pod-to-external network flows. Required for detecting lateral movement between namespaces and unexpected egress to C2 or mining pools.

Related playbooks

Linux Server Fleet (the underlying nodes are Linux hosts)
Supply Chain Indicator (container image compromise)
Cloud Control Plane (K8s often runs on cloud infrastructure with shared IAM)
C2 Beacon Found (post-compromise C2 from inside containers)