Privilege Escalation

A foothold usually lands with limited privileges, and the attacker's next move is to become root — because a low-privilege shell can look around, but root can do anything. Privilege escalation exploits misconfiguration and vulnerable software already on the host: an overly broad sudo rule, a writable service file, a SUID binary, a kernel bug.

This topic shows the common Linux escalation paths against a Meridian host so you can find and close them before the intruder walks them — running the attacker's own enumeration first, as a defensive audit.

Why Escalation Matters

The gap between a user shell and root is the difference between a nuisance and a full compromise. But it should not be game over either way: limiting what root-level access can even reach — through least privilege and segmentation (Chapters 3 and 4) — is why a single escalation on one host does not have to mean the network. Escalation matters, and so does bounding what it wins.

Misconfiguration Paths

Most escalation is misconfiguration, not a novel exploit. An overly broad sudo rule — sudo to an editor or an interpreter is sudo to root, since both can spawn a shell — a writable service file or PATH directory, weak permissions on a sensitive file, a cron job running as root over an attacker-writable script. Each is a configuration mistake that hands root to anyone who finds it.

SUID/SGID and Capability Abuse

SUID binaries run as their owner, often root, so a SUID program with a shell-escape hands root to whoever runs it — the well-known list of such binaries is a standard escalation reference. Linux capabilities on the wrong binary do the same at finer grain. Auditing and minimizing SUID/SGID binaries and file capabilities is core hardening, because each one is a potential direct path to its owner's privileges.

# what can this user run as root, and how? (an editor or interpreter = root)
sudo -l

# every SUID/SGID binary — cross-check against known shell-escapes
find / \( -perm -4000 -o -perm -2000 \) -type f 2>/dev/null

# Linux capabilities granted to binaries (cap_setuid on the wrong one = root)
getcap -r / 2>/dev/null

# writable files owned by root that a service or cron runs
find / -writable -type f 2>/dev/null | grep -vE '^/proc|^/sys'

This is exactly what an attacker runs on a fresh foothold, and running it first is how Priya closes the paths before they do. The findings are actionable: narrow a too-broad sudo rule, remove the SUID bit from a binary that does not need it, drop a stray capability, and fix the permissions on a root-run script a low-privilege user could edit.

Kernel and Software Exploits

An unpatched local kernel bug or a vulnerable privileged service escalates directly, with no misconfiguration required — which is why local patching (the next topic) is a security control, not just maintenance. "It is not internet-facing" is not a reason to skip a kernel patch, because local privilege-escalation bugs are exactly how a foothold becomes root.