Linux Privilege Escalation: Detection and Prevention

On Linux the distance between a compromised web application account and root is often one misconfigured sudo rule, one setuid binary or one unpatched kernel, and most organisations do not watch that step. This guide is written for defenders and for authorised testers working under a signed scope; it describes techniques only at the level of the MITRE ATT&CK descriptions and contains no commands, exploit code or step-by-step procedures. It covers the Linux privilege escalation families in ATT&CK v20 (tactic TA0004), the audit and EDR telemetry that reveals them, kernel and userspace hardening that removes them, and response. It is for Linux administrators, platform and container engineers, detection engineers and SOC analysts.

Key takeaways

Root is a set of capabilities, not just UID 0. Membership of groups such as docker, file capabilities and broad sudo rules can be equivalent to root, so review them as privileged access.
Sudo and setuid are the most common routes. T1548.003 and T1548.001 rely on permitted elevation that was granted too broadly, and both are fixable through configuration.
Userspace and kernel flaws keep appearing in KEV. Polkit (CVE-2021-4034), sudo (CVE-2021-3156) and several kernel flaws are listed by CISA as exploited, two with known ransomware use.
Kernel sysctls shrink the attack surface cheaply. Yama ptrace_scope, kptr_restrict, dmesg_restrict, unprivileged_bpf_disabled and modules_disabled each remove a class of escalation aid.
auditd plus EDR gives you the transition. Logging processes whose effective UID differs from their real UID, and changes to sudoers, cron, systemd units and authorized_keys, catches most escalation attempts.

How Linux privilege works and where it breaks

Linux authorises actions by user and group IDs, file permissions, and capabilities that split root's power into units such as CAP_SYS_ADMIN, CAP_SYS_PTRACE and CAP_SYS_MODULE. Linux Security Modules (SELinux, AppArmor, Yama, Lockdown) add mandatory controls on top. A process can gain privilege legitimately through sudo, setuid or setgid binaries, file capabilities, polkit, or a service running as root that accepts requests from unprivileged users.

Privilege escalation is abuse of one of those legitimate paths, or exploitation of a bug in the kernel or a privileged program, to obtain root or an equivalent capability. On servers the starting point is usually a service account: the web server user, a CI runner, a database account or a container process. That makes Linux escalation as much about non-human identities as about interactive users. See the Linux Fundamentals for Defenders Guide for the underlying permission model.

Root-equivalent groups: membership of docker (control of the Docker daemon), disk, or other groups with write access to block devices or privileged sockets gives root in practice.
Root-equivalent capabilities: CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE and CAP_DAC_OVERRIDE on a binary or process should be reviewed with the same care as setuid root.
Containers: privileged containers, host mounts and access to the container runtime socket make T1611 Escape to Host a privilege escalation rather than a container issue.

Technique families mapped to ATT&CK v20

Family	ATT&CK v20 IDs	What the technique relies on	Primary detection	Primary prevention
Sudo abuse	T1548.003 Sudo and Sudo Caching	Broad sudo rules, commands that can spawn shells, cached credentials	sudo logs and I/O logs; root shells whose parent is sudo	Least privilege sudoers; NOEXEC; short timestamp_timeout
Setuid and setgid	T1548.001 Setuid and Setgid	Binaries that run as their owner and can be made to execute other code	File integrity on setuid inventory; execve with euid 0 and uid not 0	Minimal setuid set; nosuid mounts
Exploitation	T1068 Exploitation for Privilege Escalation	Kernel or privileged userspace bugs	EDR kernel telemetry; unexpected root processes from service accounts	KEV-driven patching; live patching; sysctl hardening
Scheduled execution	T1053.003 Cron, T1053.006 Systemd Timers	Root jobs that run writable scripts, or rights to add jobs	File monitoring on cron and timer paths; jobs calling writable files	Correct ownership of job scripts; restrict cron access
Service abuse	T1543.002 Systemd Service	Rights to create or modify unit files that run as root	Unit file creation or modification; daemon-reload events	Root-owned unit directories; change control
Kernel modules	T1547.006 Kernel Modules and Extensions	Ability to load unsigned or malicious modules	init_module and finit_module syscalls; new module names	Module signature enforcement; modules_disabled; Lockdown
Process injection	T1055.008 Ptrace System Calls	Attaching to a more privileged or same-user process	ptrace syscalls from unexpected processes	Yama ptrace_scope 1 or higher
Accounts and keys	T1078.003 Local Accounts, T1098.004 SSH Authorized Keys	Reused root passwords or writable root authorized_keys	Changes to /etc/passwd, /etc/shadow, root authorized_keys	Disable root SSH login; central key management
Container escape	T1611 Escape to Host	Privileged containers, host mounts, runtime sockets	Container runtime audit; host processes started from container namespaces	Pod security standards; rootless runtimes; seccomp

Sudo, setuid and capabilities

ATT&CK T1548.003 describes adversaries using sudo or sudo caching to run commands as root, including through overly permissive sudoers rules. T1548.001 describes abuse of binaries with the setuid or setgid bit, which run with the owner's or group's privileges.

Grant commands, not shells: sudoers rules that allow editors, pagers, interpreters, package managers or wildcard arguments let the allowed program run other programs as root. Allow specific commands with fixed arguments, and prefer wrapper scripts owned by root.
Use NOEXEC where it fits: the sudoers manual explains that the NOEXEC tag, where supported, stops a dynamically linked program from running further commands, which is how shell escapes from programs such as more or vi can be blocked.
Keep env_reset and secure_path: env_reset is on by default and runs commands in a minimal environment. Do not add variables to env_keep that influence loaders or interpreters.
Shorten credential caching: the default timestamp_timeout lets a user rerun sudo for 5 minutes without a password. Reduce it on shared or high-value hosts.
Turn on I/O logging for privileged sessions: log_input and log_output are off by default; enabling them records what was typed and displayed in sudo sessions.
Edit safely: make every change with visudo and keep sudoers and the includedir under configuration management.
Inventory setuid and capabilities: keep a baseline of every setuid, setgid and file-capability binary per image, remove the ones the role does not need, and alert on additions. Mount /tmp, /home, /var/tmp and removable media with nosuid.

Polkit is a further elevation framework on desktop and many server builds. CVE-2021-4034 in polkit's pkexec is listed in the CISA KEV catalogue with known ransomware use, which is a reminder to include polkit in patching scope and to remove pkexec where it is not needed.

Kernel and userspace vulnerabilities

T1068 on Linux covers kernel bugs and bugs in privileged userspace programs. Examples in the CISA KEV catalogue include CVE-2016-5195 (Dirty COW race condition), CVE-2021-3156 (sudo heap overflow), CVE-2022-0847 (Dirty Pipe), CVE-2023-0386 (kernel improper ownership management) and CVE-2024-1086 (kernel use-after-free, known ransomware use).

Patch by exploitation status: treat KEV-listed local escalation flaws as emergency changes on internet-facing and multi-tenant hosts. See the Patch Management Guide.
Reboot or live patch: a kernel package installed but not running protects nothing. Track running kernel versions, not installed ones, and use live patching where uptime demands it.
Reduce kernel attack surface: the kernel sysctl documentation defines controls that remove common exploitation aids, summarised in the table below.

Setting	Effect (per kernel documentation)	Recommended value	Trade-off
kernel.yama.ptrace_scope	1 restricts ptrace to descendants; 2 requires CAP_SYS_PTRACE; 3 disables ptrace and cannot be changed until reboot	1 on general servers; 2 or 3 where no debugging is needed	Breaks some debuggers and profilers at 2 and 3
kernel.kptr_restrict	1 hides kernel addresses from users without CAP_SYSLOG; 2 hides them from everyone	1 or 2	Kernel debugging needs adjustment
kernel.dmesg_restrict	1 requires CAP_SYSLOG to read the kernel log	1	Users can no longer read dmesg
kernel.unprivileged_bpf_disabled	1 disables unprivileged bpf() permanently until reboot; 2 disables it but allows an admin to re-enable	1 or 2	Unprivileged BPF tooling stops working
kernel.perf_event_paranoid	Higher values restrict unprivileged performance events (default 2)	2 or higher	Unprivileged profiling limited
kernel.modules_disabled	1 blocks module loading and unloading until reboot	1 on fixed-function hosts after boot	New hardware or modules need a reboot
kernel.kexec_load_disabled	1 disables kexec syscalls and cannot be reset	1 where kexec is not used	Disables kexec-based crash kernels loaded later

Add Secure Boot with kernel module signature enforcement and the Lockdown LSM where the distribution supports them, so that T1547.006 requires a signed module. See the Linux Server Hardening Guide for wider baseline settings.

Scheduled jobs, services and writable paths

Cron and timers: root cron jobs and systemd timers that execute scripts writable by a less privileged user, or that run from a directory such a user can write to, give that user root. Check ownership and permissions of every file a root job runs and the directories in its path.
Systemd units: unit files under /etc/systemd/system and drop-in directories must be root-owned and not group or world writable. Service units should use User=, NoNewPrivileges=, ProtectSystem= and CapabilityBoundingSet= to limit what a compromised service can do.
Library and PATH hijacks: writable directories in the library search path or in the PATH of root jobs let a planted file run as root. Keep secure_path in sudoers and audit ld.so configuration.
Service accounts: web servers, CI runners and database accounts should own nothing they execute. A web application account that can write its own code directory can be turned into persistent code execution, and any sudo rule granted to it becomes an escalation path. See the Service Account Security Guide.

Containers and escape to host

T1611 Escape to Host describes adversaries breaking out of a container to the underlying host. On Linux this is a privilege escalation when the container's root becomes the host's root.

No privileged containers: the privileged flag removes most isolation. Enforce Pod Security Standards at the restricted or baseline level. See the Kubernetes Admission Control Guide.
Protect the runtime socket: mounting the Docker or containerd socket into a container, or adding a user to the docker group, grants root on the host.
Run as non-root: set runAsNonRoot, drop all capabilities and add back only what is needed, set allowPrivilegeEscalation to false, and use the runtime's default seccomp profile.
Use rootless or user namespaces: rootless runtimes map container root to an unprivileged host user, which limits the impact of escape.

See the Kubernetes Security Guide for cluster-level controls.

Detection: telemetry and analytics

Source	What to collect	What to look for
auditd execve	execve syscalls with uid, euid, auid and parent	Processes with euid 0 where auid is a non-admin or a service account; shells spawned by web, database or CI processes
auditd file watches	Writes to /etc/sudoers and sudoers.d, /etc/passwd, /etc/shadow, /etc/group, cron directories, systemd unit directories, root authorized_keys	Any change outside configuration management
auditd syscalls	init_module, finit_module, delete_module, ptrace, setuid family, chmod with setuid bits	Module loads after boot; ptrace by non-debug tools; new setuid files
sudo logs	sudo log entries and I/O logs	Denied attempts, unusual commands, sudo by service accounts
Authentication logs	journald or syslog auth facility, polkit messages	su to root, pkexec use, failed escalation bursts
EDR or eBPF sensor	Process lineage, credential changes, kernel exploit behaviour	Process credential changing to root without a legitimate elevation binary in the lineage
Container runtime and Kubernetes audit	Privileged pod creation, host mounts, exec into pods	Privileged workloads outside approved namespaces; processes on the host parented by container shims

Conceptual analytics:

Unexplained root: a process running as root whose ancestry contains a service account and no sudo, su, polkit or login service.
Privilege-relevant file change: a write to sudoers, passwd, shadow, cron, systemd units or root keys by any process other than the configuration management agent or package manager.
New setuid or capability: a file gaining a setuid bit or file capability outside a package install.
Kernel module after boot: a module load on a host whose baseline has none after startup.
Service to shell: an interactive shell or interpreter spawned by a network service process.

Rule design and log forwarding are covered in the Linux Logging and auditd for Defenders Guide and the Linux Detection and Response Guide. Relevant D3FEND techniques include D3-PSA Process Spawn Analysis, D3-SCA System Call Analysis, D3-SJA Scheduled Job Analysis and D3-LAM Local Account Monitoring.

Implementing the controls

Baseline: for each image, record sudoers rules, setuid, setgid and capability binaries, members of root-equivalent groups, root cron jobs and timers, and running kernel version.
Quick wins: patch KEV-listed escalation flaws and reboot, apply the sysctl settings in the table, disable root SSH login, mount temporary and home directories nosuid.
Audit mode: deploy auditd rules and run SELinux or AppArmor in permissive or complain mode on a pilot group, and tighten sudo rules with I/O logging on.
Enforce: move pilot hosts to enforcing, then expand by environment, keeping configuration management as the only path for privileged file changes.
Rollback: sysctls that can be reverted are applied through configuration management with the previous values stored; for one-way settings (ptrace_scope 3, modules_disabled, kexec_load_disabled) roll back by removing the setting and rebooting, so test them on non-critical hosts first.
Validate: have an authorised tester exercise each family against the baseline under a written scope. See the Penetration Test Scoping Checklist and the Building a Cybersecurity Home Lab Guide for safe practice environments.

Small versus large estates: a small team can get most of the value from a distribution hardening profile, unattended security updates with scheduled reboots, tight sudoers and a forwarded auditd rule set. Large estates need central sudo policy, fleet-wide setuid and capability baselines, live patching and an EDR or eBPF sensor that understands process credentials.

Response when escalation is detected

Isolate: cut network access through the host firewall or EDR; for containers, cordon the node and stop scheduling new workloads to it.
Preserve: capture memory if possible, auditd and journal logs, sudo I/O logs, changed configuration files and new setuid or module files before rebuilding.
Rotate: treat every secret readable by root on that host as exposed: SSH host and user keys, service credentials, tokens and cloud instance credentials.
Rebuild: rebuild from a known good image rather than cleaning, because root access allows persistence through modules and units.
Fix the class: apply the root cause fix to every host built from the same image.

Common failure patterns

Sudo ALL for convenience: service and operations accounts get unrestricted sudo, so any compromise of them is immediate root.
Installed but not running patches: kernel updates are applied but hosts are not rebooted, leaving KEV-listed flaws exploitable for months.
docker group as a developer perk: adding developers or CI runners to the docker group grants root on the host without anyone recording it as privileged access.
No auditd forwarding: audit rules exist locally but logs are not shipped, so an attacker with root deletes them.
Writable root job scripts: cron scripts owned by an application account but run by root.
Privileged containers in production: workloads run privileged because one feature needed a single capability.

Framework mapping

Framework	Reference	Relevance
MITRE ATT&CK v20	TA0004; T1548.001, T1548.003, T1068, T1053.003, T1053.006, T1543.002, T1547.006, T1055.008, T1078.003, T1098.004, T1611	Technique families in this guide
NIST SP 800-53 Rev. 5	AC-6, AC-6(1), AC-6(5), AC-6(9), AC-6(10)	Least privilege sudo and logging privileged functions
NIST SP 800-53 Rev. 5	CM-7, SI-2, SI-4, AU-12	Least functionality, patching and monitoring
NIST CSF 2.0	PR.AA-05, DE.CM-09	Access permissions and monitoring
MITRE D3FEND	D3-UAP, D3-SU, D3-SCF System Call Filtering, D3-KBPI Kernel-based Process Isolation, D3-DLIC, D3-PSA, D3-SCA, D3-SJA, D3-LAM	Countermeasures in this guide

Measuring progress

Unrestricted sudo count: number of accounts with sudo ALL, trending to named administrators only.
Setuid drift: setuid, setgid and capability binaries outside the image baseline.
Kernel exposure window: median days hosts run a kernel with a KEV-listed flaw, measured on running kernels.
Sysctl compliance: percentage of hosts meeting the hardening sysctl baseline.
auditd coverage: percentage of Linux hosts forwarding the escalation rule set centrally.
Privileged container count: privileged pods or containers outside approved system namespaces.

Practitioner checklist

Replace broad sudo rules with specific commands, enable NOEXEC where suitable and turn on I/O logging for privileged users.
Baseline and minimise setuid, setgid and file capability binaries per image.
Treat docker and other root-equivalent group membership as privileged access.
Patch and reboot or live patch for KEV-listed escalation flaws on an emergency timeline.
Apply ptrace_scope, kptr_restrict, dmesg_restrict, unprivileged_bpf_disabled and perf_event_paranoid settings fleet-wide.
Enforce module signing and Secure Boot where supported.
Audit ownership of every file run by root cron jobs, timers and units.
Forward auditd, sudo and authentication logs centrally with escalation analytics.
Block privileged containers and runtime socket mounts through admission control.
Validate controls with authorised testing under a written scope.

Linux Privilege Escalation Techniques Guide: Detecting and Preventing Escalation on Linux