Linux Privilege Escalation
Linux privilege escalation tested defensively: how attackers escalate, how to detect, and how to harden against the common vectors.
Ethical hacking — Linux privesc (defensively)
EXAMPLE
# RoE: authorised testing only on systems you own / have written permission to test. # ===== Why privesc ===== # Initial foothold is usually a low-priv user. Attackers escalate to root or # specific service accounts to expand access. Defenders need to know the vectors # to detect + prevent them. # ===== Common vectors (with defenses) ===== # 1. SUID / SGID binaries # Files with SUID run as the OWNER, not the caller. Misconfigured SUID = root shell. # Find them: find / -perm -4000 -type f 2>/dev/null # Defense: # - Remove SUID from binaries that don't need it (chmod u-s) # - Use file integrity monitoring on /usr/bin /usr/sbin # - Detection rule: new SUID binary appearing outside known list -> alert # 2. Writable PATH directories # If $PATH includes a writable dir before /usr/bin, attacker drops a malicious binary. echo $PATH # Defense: # - Never include '.' or world-writable dirs in root's PATH # - Use absolute paths in scripts run by root # 3. Sudo misconfiguration # sudoers entries like NOPASSWD on dangerous commands or specific binaries with # weird interactions (vim, tar, less can shell out). # Examples (DO NOT do this): # user ALL=(ALL) NOPASSWD: /usr/bin/find # find -exec /bin/bash; -> shell # user ALL=(ALL) NOPASSWD: /usr/bin/vim # !sh inside vim # Check: sudo -l # Defense: # - Limit sudo to specific commands with NO_EXEC # - Use Defaults !visiblepw + Defaults requiretty # - Audit sudoers via /etc/sudoers + /etc/sudoers.d/ # 4. Cron jobs running as root with weak permissions # A root cron job running a world-writable script -> attacker rewrites the script. ls -la /etc/cron.* /var/spool/cron/ # Defense: # - Cron scripts owned by root, mode 700 # - Avoid /tmp / /var/tmp paths in cron scripts # - Monitor cron jobs for writes to non-standard paths # 5. Kernel exploits # Old kernels have known CVEs (Dirty COW, dirty pipe, etc). uname -r # Defense: # - Patch kernels promptly (unattended-upgrades on Debian/Ubuntu) # - Enable kernel hardening (lockdown mode, KASLR, SMEP/SMAP) # - Run with seccomp / AppArmor / SELinux profiles # 6. Capabilities # Linux capabilities (CAP_NET_BIND_SERVICE, CAP_SYS_ADMIN, ...) on binaries can # give selective root-like powers. getcap -r / 2>/dev/null # Defense: # - Audit capabilities; only essential ones # - CAP_SYS_ADMIN is effectively root; treat it as such # 7. Docker / container escapes # - Docker socket mounted into a container = root on host # - --privileged containers # - Mounted /proc or /sys # Defense: # - No /var/run/docker.sock mounts to non-trusted containers # - Use rootless Docker / Podman where possible # - Pod security policies in Kubernetes # ===== Detection patterns ===== # - Sysmon-equivalent on Linux: auditd, sysdig, Falco # - Falco rules: 'Outbound or Inbound Traffic not to Authorized Server' # - Auditd rules: setuid changes, sudo commands run # - osquery: scheduled queries on system state # ===== Hardening checklist ===== # - Patch kernel + key packages within SLA # - Minimise SUID binaries # - Tight sudoers; require password for privileged commands # - Lock down cron + systemd units (mode 700, root-owned) # - SELinux / AppArmor enforcing mode # - Egress controls + network segmentation # - Audit log shipped to remote SIEM # - Regular CIS benchmark scans (lynis, openscap) # ===== Testing safely ===== # - In a LAB VM that you OWN, not on production # - Use vulnerable-by-design environments: HackTheBox, VulnHub, OverTheWire # - Restore from snapshot after each exercise # ===== Patterns to internalise ===== # - RoE FIRST; always # - Every offensive technique pairs with a detection + hardening note # - Patch + minimise + log; the three pillars of Linux defense # - Test in the lab; report findings constructively # ===== Pitfalls ===== # - Testing against systems you do not own # - Skipping the detection/hardening write-up # - Sharing exploits publicly without coordinating with the vendor # - Assuming SELinux 'permissive' is fine; switch to 'enforcing'
Why it matters
Linux privesc is mostly misconfigured SUID, weak sudoers, world-writable paths, missing patches, and over-permissioned containers. The defenses are concrete: audit SUID + capabilities, tighten sudoers, restrict cron scripts, patch the kernel, enable MAC (SELinux/AppArmor), ship audit logs. Every test in a lab; every finding paired with a hardening note.
Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.
Example
Example
# Linux post-exploitation enumeration (authorised hosts only): # - SUID binaries: find / -perm -u=s -type f 2>/dev/null # - Sudo rules: sudo -l # - Kernel version + capabilities + writable paths # Helpers: linpeas.sh, LinEnum.sh (run only where you have permission).Try it Yourself »
Discussion
Loading…