Enumeration commands and common local privilege-escalation vectors on Linux hosts. Use inside authorized labs, CTFs, or engagements — never on systems you do not own or have written permission to assess.
Initial enumeration
id # current uid/gid and groups
sudo -l # commands the user may run via sudo
uname -a # kernel and architecture
cat /etc/os-release # distribution and version
hostname; ip a # host and network info
ps aux --forest # running processes
env # interesting env vars (credentials, PATH)
ls -la /home # sibling users and exposed files
Capture id, sudo -l, and uname -a first. Many escalation paths are decided by those three lines alone.
Common vectors
| Vector | Find it | Notes |
|---|---|---|
| Sudo rights | sudo -l | Check the binary on GTFOBins for a shell escape |
| SUID binaries | find / -perm -4000 -type f 2>/dev/null | Root-owned SUID may be abusable |
| SGID binaries | find / -perm -2000 -type f 2>/dev/null | Group-escalation primitives |
| Capabilities | getcap -r / 2>/dev/null | e.g. cap_setuid on an interpreter |
| Cron jobs | cat /etc/crontab; ls -la /etc/cron.* | Writable scripts run by root |
| Systemd timers | systemctl list-timers --all | Writable unit/script equivalents |
| Writable PATH dirs | echo $PATH | Hijack a binary a privileged job calls |
| Passwords / keys | `grep -RiE "password | secret" /etc /var/www 2>/dev/null` |
| World-writable files | find / -writable -type f 2>/dev/null | head | Config or script tampering |
| Docker socket | ls -la /var/run/docker.sock | Often equivalent to root on the host |
| NFS no_root_squash | cat /etc/exports | Classic shared-folder root map |
Capability abuse patterns
Linux capabilities split root powers. Look for dangerous combos on interpreters:
getcap -r / 2>/dev/null | grep -E 'cap_setuid|cap_sys_admin|cap_dac_override'
Examples of intent (lab patterns, not copy-paste exploits):
python3/perl/rubywithcap_setuid→ spawn a setuid shell from an authorized lab exercise.tar/rsyncwith broad caps → overwrite or read protected paths depending on the cap set.- Always verify the binary path (
which,readlink -f) so you do not escalate via a shadowed copy in a user-writable PATH entry.
Kernel and container boundaries
| Check | Why it matters |
|---|---|
uname -r + distro | Maps to known local CVEs — verify against your lab kernel, do not invent |
cat /proc/1/cgroup | Helps detect containerized contexts |
ls -la /.dockerenv | Quick Docker hint (presence is suggestive, not proof) |
| `mount | grep -E 'nfs | squash'` |
ip link; iptables-save 2>/dev/null | Network namespace / egress clues |
Inside containers, prefer:
- Mounted docker.sock or privileged flag indicators.
- Writable hostPath volumes.
- Over-permissive service accounts (Kubernetes) rather than random kernel exploits.
Kernel exploits are last-resort: high crash risk, noisy, and often unnecessary when sudo/SUID/cron is open.
Sudo and GTFOBins methodology
- Run
sudo -land noteNOPASSWDentries and env reset rules (env_reset,secure_path). - For each allowed binary, open the GTFOBins page and prefer sudo / SUID recipes that match your exact flags.
- If sudo allows editors (
vim,less,man), look for shell escapes (:!sh,!sh) rather than downloading new payloads. - If sudo allows package managers or language REPLs, treat them as full shell equivalents.
Document the exact command that worked. “Got root somehow” is not a finding.
Cron, timers, and PATH hijack
cat /etc/crontab
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
systemctl list-timers --all
# For each script invoked by root, check writability:
namei -l /path/to/script
PATH hijack pattern (lab): if a root cron runs backup.sh without an absolute path and a directory earlier in PATH is writable by you, planting a malicious backup.sh is the classic demo. Fix on the defense side: absolute paths + non-writable script dirs + secure_path.
Credentials and misfiled secrets
# History and user files (authorized shells only)
ls -la ~/.*history 2>/dev/null
find /home /opt /var/www -name '*.env' -o -name '*id_rsa*' 2>/dev/null | head
grep -RniE 'BEGIN OPENSSH PRIVATE KEY|AWS_SECRET|password\s*=' /opt /var/www 2>/dev/null | head
Reuse of DB passwords as sudo passwords remains common in student labs and poorly managed appliances.
Useful references
- GTFOBins (https://gtfobins.github.io) — shell escapes for SUID/sudo binaries.
- LinPEAS (PEASS-ng) — automated enumeration; still read the output.
linux-exploit-suggester— maps kernel version to candidate local issues; verify before use.- HackTricks Linux privilege escalation notes — methodology depth beyond this sheet.
Defensive quick wins
- Remove unnecessary SUID bits; prefer capabilities with audit.
sudoallow-lists with absolute paths; avoid shell wrappers.- Make cron scripts root-owned
0644/0755as appropriate and not group/other-writable. - Do not expose
docker.sockto app users; use rootless or tightly mediated APIs. - Ship SSH keys and secrets via a manager, not world-readable config trees.
Ethics
Only run these against systems you own or are explicitly authorised to assess. Privilege escalation practice belongs in labs (local VMs, intentionally vulnerable images), not production curiosity.
