Tutorials - Auditing container escape and privilege risks

This lesson shows how to use cdxgen's container executable inventory together with the container-risk BOM audit rules to spot:

• container-escape helpers
• privileged GTFOBins execution primitives
• offensive toolkit binaries inspired by Peirates, CDK, and DEEPCE
• seccomp-sensitive namespace escape helpers
• exfiltration-capable binaries
• mutable-path remote execution tooling

1) Generate a container SBOM with executable collection and audit enabled

Use a container image reference or an exported OCI layout.

cdxgen -t container \
  --deep \
  --bom-audit \
  --bom-audit-categories container-risk \
  --bom-audit-fail-severity high \
  -o bom.json \
  docker.io/library/ubuntu:24.04

Why this matters:

• --deep enables richer binary collection for container images
• --bom-audit evaluates built-in audit rules immediately
• container-risk focuses the findings on container breakout and post-exploit tooling

2) Understand what the analyzer enriches

When cdxgen recognizes a collected executable from GTFOBins-derived data or curated container-tradecraft knowledge, it adds properties such as:

• cdx:gtfobins:functions
• cdx:gtfobins:privilegedContexts
• cdx:gtfobins:riskTags
• cdx:gtfobins:reference
• cdx:container:attackTechniques
• cdx:container:offenseTools
• cdx:container:seccompBlockedSyscalls

These properties let BOM audit distinguish between:

• ordinary package inventory
• known post-exploitation helpers
• binaries that become much riskier when setuid/setgid bits or capability-backed execution are present
• helpers that map to MITRE ATT&CK for Containers or offensive playbooks such as Peirates, CDK, and DEEPCE
• helpers that stay partially constrained only while the runtime keeps the default seccomp profile in place

3) Review findings and inspect matched binaries

Quickly list the matched audit findings:

jq '.annotations[]?.text // empty' bom.json

Inspect the enriched executable records:

jq '
  .components[]
  | select(
      (.properties // [])
      | any(.name == "cdx:gtfobins:matched" and .value == "true")
    )
  | {
      name,
      purl,
      srcFile: ((.properties // [])[] | select(.name == "SrcFile") | .value),
      functions: ((.properties // [])[] | select(.name == "cdx:gtfobins:functions") | .value),
      privilegedContexts: ((.properties // [])[] | select(.name == "cdx:gtfobins:privilegedContexts") | .value),
      riskTags: ((.properties // [])[] | select(.name == "cdx:gtfobins:riskTags") | .value),
      attackTechniques: ((.properties // [])[] | select(.name == "cdx:container:attackTechniques") | .value),
      offenseTools: ((.properties // [])[] | select(.name == "cdx:container:offenseTools") | .value),
      seccompBlockedSyscalls: ((.properties // [])[] | select(.name == "cdx:container:seccompBlockedSyscalls") | .value)
    }
' bom.json

4) What to fix first

Prioritize findings in this order:

1. CTR-001 and CTR-002 — setuid/setgid or container-escape helpers
2. CTR-003 and CTR-004 — privileged escalation, library-load, or exfiltration helpers
3. CTR-005 and CTR-006 — mutable-path helpers and dedicated offensive toolkits
4. CTR-007 — seccomp-sensitive namespace escape helpers

Strong remediation patterns:

• move production workloads to distroless or minimal base images
• strip setuid/setgid bits from runtime images
• remove docker, ctr, kubectl, nsenter, and similar admin/debug tools from app images
• never ship peirates, cdk, deepce, or similar red-team binaries in production images
• keep debug or break-glass tooling in separate images
• block access to Docker/containerd sockets and avoid privileged containers
• keep the default seccomp profile unless you have a narrowly-scoped and reviewed exception

5) Where the extra context comes from

The current container enrichment combines four complementary knowledge sources:

• MITRE ATT&CK for Containers for tactic and technique IDs such as host escape, cluster discovery, and container administration
• Peirates / CDK / DEEPCE for practical cluster-pivot, service-account, runtime-socket, and breakout playbooks
• Docker default seccomp guidance for syscalls like setns, unshare, and open_by_handle_at that should stay blocked in most app workloads
• GTFOBins for executable-level abuse primitives and privileged execution context

6) Suggested CI gate

Use a high-severity fail gate for production images:

cdxgen -t container \
  --deep \
  --bom-audit \
  --bom-audit-categories container-risk \
  --bom-audit-fail-severity high \
  -o bom.json \
  your-registry.example.com/team/app:release

This keeps obviously dangerous helpers out of runtime images while still allowing lower-severity findings to flow into triage.