iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

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…