Courses Advanced Linux securityPrivilege escalation

Kernel & credential escalation

Kernel exploits, cron, PATH, and secrets.

Advanced14 min · lesson 4 of 17

When configuration is tight, attackers turn to the kernel and to stealing credentials. The shared kernel is a single, huge codebase running as the ultimate authority, and a local privilege-escalation vulnerability in it (Dirty COW, Dirty Pipe, and a steady stream of others) lets an unprivileged process become root directly. You cannot configure your way out of a kernel bug — the defenses are the sysctl hardening from the previous course (which raises the bar), reducing local attack surface, and above all patching the kernel promptly, because these exploits are public and reliable.

terminal

# an attacker fingerprints the kernel to pick an exploit; you use the same info to prioritize patching
$ uname -r
5.15.0-89-generic
# a host running a kernel with a known local-root CVE is a privesc waiting to happen —
# track kernel versions across the fleet and patch the ones with public exploits first

Scheduled tasks and writable PATH

Some of the most reliable escalations abuse things that already run as root. A cron job or systemd timer that runs a script as root, where the script (or a directory in its path) is writable by a lower-privileged user, means the attacker edits what root will execute. A related trick: a root-run script that calls a command by name without a full path, combined with a writable directory early in root’s PATH, lets the attacker plant a malicious binary that gets run as root. Both are configuration flaws you can audit for.

terminal

# attacker (and defender) checks: what runs as root, and can I write to any of it?
$ cat /etc/crontab; ls -la /etc/cron.*      # scheduled root jobs
$ find / -writable -type f 2>/dev/null | grep -E 'cron|\.sh$'   # root scripts you can edit
# any world/group-writable file that root executes on a schedule = root for whoever can write it

Harvesting credentials

Escalation is not always to root on this box — often it is sideways or onward by stealing credentials the host holds. Attackers grep the filesystem and process memory for secrets: passwords in config files and environment variables, private SSH keys in home directories, cloud credentials in ~/.aws, tokens in application config, and .bash_history for commands that leaked a secret. Every credential on the host is a potential pivot to another system, which is why the hardening course was so insistent about secrets in files and environment variables.

terminal

# the credential hunt — what an attacker greps for, and what you must keep off the host:
$ grep -riE 'password|secret|api[_-]?key' /etc /opt /home 2>/dev/null
$ find /home -name id_ed25519 -o -name id_rsa 2>/dev/null   # private keys to steal
$ cat ~/.aws/credentials ~/.bash_history 2>/dev/null         # cloud creds, leaked commands

Patch the kernel; keep secrets off the host

Two durable defenses against this family. Kernel local-root exploits are public and weaponized quickly, so kernel patch latency is a direct measure of your privesc exposure — track versions and patch on a short clock. And every credential sitting readable on a host is one an attacker who lands there can steal and reuse elsewhere, turning one compromised box into many; use short-lived tokens, a secrets manager, and mounted-not-baked credentials so there is little to harvest. The blast radius of a foothold is decided by what the host is holding.

Local privesc: SUID, sudo,…Finding privesc before they do