crictl is the CRI debugging CLI that talks directly to the node's container runtime (containerd/CRI-O) socket, bypassing the API server and kubelet policy entirely. From a compromised node, crictl ps lists running containers and crictl exec drops an interactive shell into any of them, including other tenants' workloads.
Use On a node, execute into any running container out-of-band of the Kubernetes API and its RBAC/audit.
Detection: Node-level process/auditd monitoring: exec of crictl (and containerd-shim/runc exec children) not originating from kubelet. These actions bypass API audit, so rely on host EDR and file/socket access to /run/containerd/containerd.sock or /var/run/crio/crio.sock.
Verified
✓ kubernetes.io crictl debug docs and cri-tools confirm `crictl ps` and `crictl exec -it`; crictl speaks directly to the CRI socket, bypassing apiserver/RBAC/audit. Not a GTFOBins/LOLBAS binary; T1609.
crictl inspect returns a container's full CRI status JSON including its environment variables, command line, mounts and labels. Applications commonly pass secrets (DB passwords, API keys, tokens) as env vars, so inspecting containers on a node reveals those plaintext values without touching Kubernetes Secret objects or the API server.
Use Read plaintext env-var secrets and mount layout of colocated containers straight from the node runtime.
Detection: Auditd/EDR for crictl inspect / inspectp / inspecti invocations on nodes outside of sanctioned tooling, and for reads of the containerd/CRI-O socket. Prefer mounting secrets as files with restrictive modes over env vars to shrink this exposure.