liveBook · Manning

Container escape vulnerability

As explained in Cyber Threat Hunting

An adversary technique in which an attacker escapes a container to execute actions on the underlying host.

A container escape vulnerability lets an adversary use a container as a launchpad into other parts of a Kubernetes environment, breaking the isolation containers are expected to provide. Privileged containers are especially dangerous because access to host devices lifts ordinary container limitations. A successful escape can put nodes, pods, and potentially the wider environment under adversary control. section 5.1.1

Hunt for escape activity by treating Kubernetes API-server use as a key boundary-crossing signal. Successful API calls from unexpected locations, accounts, or user agents—and unknown pods in the cluster—are indicators worth investigating. This focus matters because the API server fronts the cluster’s shared state and serves REST-based operations for other components. section 5.1.1 section 5.1.3

A repeatable investigation starts with expected behavior, then narrows anomalies:

  • Inventory legitimate API-call sources: administrator systems, internal management and health-check addresses, node external IPs, and cloud-provider metrics ranges. section 5.1.3
  • Search recent API-server events for caller IPs outside that baseline, and group results by caller IP, user agent, and authorization decision. section 5.1.3
  • Prioritize allowed calls from unusual sources. Recheck suspicious addresses with the associated account, client identity, permissions, and API methods. section 5.1.3
  • Inspect container behavior for Kubernetes-client execution and unexpected connections from containers to the API server. section 5.1.3
  • Review service-account activity and RoleBinding changes when a workload account appears to be used beyond its expected role. section 5.1.3

From a privileged portal container to cluster activity

A portal deployment configured as privileged is a high-risk starting point. In the investigation scenario, a Kubernetes client is found inside the container, then Falco reports that client creating a deployment and contacting the API server from the container. The resulting workload activity can be correlated with API-server audit events, service-account actions, and newly deployed pods. section 5.1.3

Listing 5.5 Searching Kubernetes API events in the data store, Humio
sourcetype="gcp:k8s:api"                                       #1
| callerIp := rename("protoPayload.requestMetadata.callerIp")  #2
| decision := rename("labels.authorization.k8s.io/decision")   #3
| callerSuppliedUserAgent := rename(                                    \
   protoPayload.requestMetadata.callerSuppliedUserAgent)       #4
| !cidr(callerIp, subnet=[                                               \
   "193.188.105.36", "111.65.33.215", "108.177.73.0/24",                 \
   "108.177.67.0/24", "74.125.209.0/24", "66.249.84.0/24",               \
   "10.138.0.168", "34.83.195.160", "127.0.0.1", "::1"])       #5
| groupby(field=[callerIp,                                               \
   callerSuppliedUserAgent, decision], function=count())       #6
| sort(_count, order=desc)                                     #7

Use the query as a starting pattern: normalize API-event fields, exclude known source ranges, then group remaining calls by source, client, and decision. section 5.1.3

Detection is strongest when API audit evidence and runtime evidence agree. API events identify who called which resource from where; runtime alerts connect that activity to a specific container, command line, image, namespace, and network connection. Together, they turn an unusual API request into an investigation of possible container-to-cluster movement. section 5.1.3

How Cyber Threat Hunting covers it

How deep it goes
Works through baselining, event searches, account checks, runtime rules, and alert evidence without detailing an exploit mechanism.
Examples
Uses a privileged portal deployment, anomalous API callers, in-container kubectl, Falco events, and suspicious workload pods.
What it assumes
Assumes familiarity with Kubernetes pods, API calls, and service accounts while defining container escape and expected call sources.
What you can do after
Diagnose/debug with it by baselining API callers and correlating anomalous audit events with container runtime alerts.
How it connects
Connects container isolation with privileged containers, Kubernetes API server, service accounts, RoleBindings, and Falco.
Cover of Cyber Threat Hunting
liveBookmanning.com
Read Cyber Threat Hunting on liveBook Get the book at manning.com

Also explained in

Compare how 2 books explain container escape vulnerability →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Cyber Threat Hunting. The section links point to the parts of the book it draws on.