M ManySignal

Use Case: Container

Container escape detection

A process inside a privileged container mounted the host filesystem at /host. That's the escape. ManySignal flagged the syscall 3 seconds later and revoked the pod's service account.

Book a demo Container attack surface
Attack scenario

From container to cluster in 60 seconds

Container escapes are the cloud-native equivalent of privilege escalation. An attacker who compromises a containerized workload — via a vulnerable application, a malicious dependency, or a stolen API key — is initially contained by the container boundary. But if that container runs privileged, or has dangerous Linux capabilities, or mounts the host's Docker socket, the boundary is effectively non-existent.

Once on the host, the attacker has access to the node's kubelet credentials, the Kubernetes API, and all secrets mounted in any pod on that node. From the API, they can enumerate the cluster, create new backdoor deployments, and exfiltrate secrets — all using legitimate Kubernetes primitives that generate no alerts in a standard configuration.

Detection logic 
rule: container_escape_behavioral
type: syscall + k8s_audit
sources:
  - falco_events
  - tetragon_ebpf_events
  - kubernetes_audit_log
  - node_syslog
trigger:
  - OR:
    - condition: |
        syscall IN [mount, unshare, clone] AND
        container.privileged == true AND
        target_path.startswith("/host") OR target_path == "/"
    - condition: |
        process.name IN [nsenter, chroot, pivot_root] AND
        container.id != host
    - condition: |
        container.mounts.includes("/var/run/docker.sock") AND
        docker.api_call.method == "POST"
enrichments:
  - k8s_workload: pod_name, namespace, deployment
  - service_account_permissions: rbac_evaluation
  - node_lateral_potential: cluster_admin_check
mitre: T1611 (Escape to Host)
Triage agent questions
1

Was the container running with privileged flag or a dangerous capability like SYS_ADMIN or SYS_PTRACE?

Container runtime
2

Did the container process access host filesystem paths outside its volume mounts?

Falco / Sysdig
3

Were any kernel exploits attempted — CVE-2022-0492 (cgroups), CVE-2019-5736 (runc)?

Syscall audit
4

Did a process inside the container spawn a new process with host PID namespace access?

EDR / Falco
5

What was the container's workload — which deployment or pod does it belong to?

Kubernetes API
6

Did the container make any connection to the Kubernetes API server post-escape?

K8s audit log
Response playbook
1

Terminate the suspicious container and cordon the affected node from the cluster

Approve-gated
2

Capture container and node memory for forensic analysis

Autonomous
3

Revoke the service account token associated with the compromised pod

Autonomous
4

Rotate Kubernetes secrets that were mounted in the compromised pod

Approve-gated
5

Scan cluster for other pods with the same vulnerable configuration

Autonomous

MITRE ATT&CK mapping

T1611 — Escape to HostT1543 — Create or Modify System ProcessT1552.007 — Unsecured Credentials: Container API

Container escape FAQ

What sensor does ManySignal use for container escape detection?

ManySignal integrates with Falco (CNCF), Sysdig, Aqua Security, and Tetragon (eBPF-based) for container syscall monitoring. The raw syscall events are normalized and correlated with Kubernetes audit logs and EDR data from the underlying node to build a complete picture.

Does ManySignal detect escape attempts that don't succeed?

Yes. Attempted container escapes — failed kernel exploit attempts, blocked host filesystem access, denied privileged operations — are detected as high-confidence indicators of a compromised workload even if the escape itself failed. The workload is treated as potentially hostile and investigated.

How does ManySignal handle false positives from privileged containers used legitimately?

Legitimate privileged containers (monitoring agents, node management tools) are whitelisted by deployment name, namespace, and service account. Any privileged container not in the whitelist and exhibiting escape-like behavior triggers the alert. Whitelist changes go through a change management workflow.

What Kubernetes-specific post-escape activity does ManySignal detect?

Post-escape K8s activity includes: accessing the node's kubelet credentials, querying the K8s API server without going through expected proxy endpoints, creating new pods with elevated permissions, and modifying ClusterRole bindings. These are covered by the Kubernetes RBAC abuse use case, which shares entity context with this one.

Detect container escapes at the syscall level

Falco and eBPF-based detection correlated with Kubernetes audit logs. Real-time containment before the attacker reaches the cluster.

Book a demo Explore the platform