Privilege Escalation Detection

Privilege escalation attack patterns

Attackers who gain access to a container running as an unprivileged user attempt to escalate to root or gain Linux capabilities that allow them to break container boundaries or access host resources.

• setuid binary abuse — executing setuid binaries (sudo, pkexec, su) from within a container where these shouldn't exist
• CAP_SYS_ADMIN exploitation — abusing containers granted broad Linux capabilities to perform privileged operations
• Kernel exploit execution — running exploit binaries that target known Linux kernel privilege escalation vulnerabilities
• /etc/passwd and /etc/shadow modification — attempting to add root-level users or modify credential files
• Capabilities manipulation via capset() — calling capset() to expand the process capability set beyond what was granted at container start

How Kubesentry detects privilege escalation

• setuid/setgid syscall monitoring — alerts when a process calls setuid(0) or setgid(0) from within a container namespace
• capset() call tracking — detects capability set expansion attempts, especially addition of CAP_SYS_ADMIN, CAP_NET_ADMIN, or CAP_SYS_PTRACE
• Sensitive file write monitoring — monitors write operations to /etc/passwd, /etc/shadow, /etc/sudoers from containerized processes
• sudo/su execution detection — flags execution of setuid privilege escalation binaries in contexts where they are not expected
• Process baseline deviation — alerts when a process's effective UID drops to 0 after starting as non-root, indicating successful escalation
• Known exploit signature matching — Falco-compatible rules match known privilege escalation exploit argument patterns

Response playbook

1. Assess escalation success. Check if the process achieved root (UID 0) or gained the targeted capability. The Kubesentry alert includes effective UID before and after the escalation attempt.
2. Isolate immediately if escalation succeeded. A process with CAP_SYS_ADMIN or root inside a container can potentially escape to host. Treat this as equivalent to a container escape alert.
3. Identify the escalation binary. Check if the setuid binary used is a system binary (sudo, pkexec) or a planted exploit binary. The latter indicates a more sophisticated attack.
4. Review container SecurityContext. Check runAsNonRoot, allowPrivilegeEscalation: false, and capability drop configuration. Missing these settings is the root misconfiguration.
5. Apply PodSecurityAdmission policies. Enable the restricted PodSecurityStandard profile for the affected namespace to prevent recurrence at the admission layer.
6. Update image policy. If a setuid binary like pkexec was present in the application image, add a build-time check or admission controller rule blocking images containing setuid binaries.

Related detections