Linux Privilege Escalation: A Pentester Enumeration Guide

Linux privilege escalation is the process of moving from a low-privilege shell to root by systematically enumerating misconfigurations — weak sudo rules, SUID binaries, writable cron jobs, dangerous capabilities, and unpatched kernels — then exploiting the first viable vector. For authorised pentesters and Indian sysadmins hardening their own systems, the discipline is the same: enumerate exhaustively before touching a single exploit, because most Linux boxes are compromised not through zero-days but through configuration debt nobody audited. This guide walks the standard enumeration checklist, the common escalation vectors it surfaces, and the defensive controls that close each one.

Why Enumeration Comes Before Exploitation

Every experienced pentester repeats the same rule: enumeration is 90% of privilege escalation. A fresh low-privilege shell tells you almost nothing about what's exploitable until you've methodically checked sudo permissions, file ownership, running processes, scheduled tasks, and kernel version. Skipping this step and jumping straight to a kernel exploit is how testers crash production systems and miss the quiet, reliable misconfiguration sitting one command away.

Step One: sudo -l and Sudoers Misconfigurations

The first command on any authorised Linux engagement is sudo -l, which lists what the current user can run as another user (usually root) without a password, or with their own password.

sudo -l

Common findings include binaries listed with NOPASSWD, or entries pointing at interpreters and editors (vim, less, find, python3, awk) that were never meant to be run with elevated privileges. Any of these can typically be abused to spawn a root shell through the binary's built-in shell-out functionality — a pattern documented extensively on GTFOBins, the community-maintained reference for Unix binaries that can bypass local security restrictions when misused via sudo, SUID, or capabilities.

Step Two: SUID and SGID Binaries

SUID (Set User ID) and SGID (Set Group ID) bits let a binary execute with the permissions of its owner rather than the user running it. A SUID binary owned by root effectively runs as root regardless of who invokes it — which is exactly why unnecessary SUID bits are one of the most reliable escalation paths on a poorly hardened box.

find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null

The first command finds SUID binaries, the second SGID. Cross-reference every non-standard result against GTFOBins — custom or third-party SUID binaries that shell out, read arbitrary files, or write to arbitrary paths are the highest-value findings in this phase.

Step Three: Cron Jobs and Scheduled Tasks

Cron jobs running as root that reference a script writable by a lower-privilege user are a classic escalation path: edit the script, wait for the schedule to fire, and it executes as root.

cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/
crontab -l -u root 2>/dev/null

Also check the permissions on any script a root cron job calls, not just the crontab entry itself:

find / -writable -not -path "/proc/*" -type f 2>/dev/null

Step Four: Linux Capabilities

Capabilities split root's traditional all-or-nothing power into discrete, assignable privileges (CAP_SETUID, CAP_NET_RAW, CAP_SYS_ADMIN, and dozens more). A binary granted CAP_SETUID without being SUID root can still be abused to escalate, and capabilities are frequently overlooked because testers default to only checking SUID bits.

getcap -r / 2>/dev/null

Any binary returning cap_setuid+ep or similar is worth checking against GTFOBins' capabilities section — the abuse pattern is analogous to SUID exploitation but through a different kernel mechanism, and it's routinely missed in enumeration that stops at find -perm -4000.

Step Five: Kernel Version and Patch Level

Kernel exploits are a last resort in a careful engagement — they're higher-risk (crash potential) than a clean misconfiguration-based escalation — but an unpatched kernel is still worth identifying early, because it tells you how current the host's patch cadence actually is.

uname -a
cat /etc/os-release

Cross-reference the reported kernel version against known local privilege escalation CVEs for that release line before considering a kernel-level exploit, and prefer a userland misconfiguration path whenever one exists — it's more reliable and far less likely to destabilise the host.

Common Linux Privilege Escalation Vectors Summarised

Automated Enumeration: Where linPEAS Fits

Manual enumeration teaches the underlying logic, but on a real engagement it's paired with automated enumeration scripts — linPEAS being the most widely used in the community — that run the same checks (sudo rules, SUID/SGID, capabilities, cron, writable paths, kernel version, and dozens more) in one pass and highlight likely-exploitable results by colour. These tools are a starting point for triage, not a replacement for manually verifying every finding before acting on it — automated scripts produce false positives, and blindly executing a suggested exploit against a live system without understanding what it does is how authorised engagements go wrong.

The pattern these figures point to holds inside a single host just as much as across an organisation: most exploitable weaknesses trace back to configuration and permission decisions, not novel code-level flaws — which is exactly why enumeration discipline outperforms jumping straight to an exploit.

Distribution of Privilege Escalation Vectors

Based on common findings across authorised Linux pentest engagements, misconfiguration-driven vectors dominate over kernel-level exploits:

Defence: Closing Each Vector Before It's Found

Enumeration findings map directly onto remediation actions, and most of them cost nothing but administrative time.

1. Enforce least privilege in sudoers. Restrict entries to the exact binary and arguments required, remove blanket NOPASSWD grants, and never allow sudo access to interpreters, editors, or find/awk-style utilities that can shell out.
2. Audit SUID/SGID bits regularly. Most systems ship with more SUID binaries than they actually need. Run find / -perm -4000 on a schedule and strip the bit from anything not in active, justified use.
3. Lock down cron job ownership and paths. Scripts referenced by root-scheduled jobs should be owned by root, writable only by root, and referenced with absolute paths — never relative paths that depend on an unlocked PATH variable.
4. Review capability grants like you review sudoers. getcap -r / should be part of the same audit cadence as SUID checks; capabilities are just as dangerous and far less visible.
5. Patch on a fixed cadence, not reactively. Kernel and package patching should follow a defined schedule aligned to vendor advisories, not wait for an incident to trigger it.
6. Monitor for enumeration behaviour itself. Bursts of find, getcap, or sudoers-file access from a single session, especially from a low-privilege account, are a detectable signature worth alerting on before escalation succeeds.

Where an External VAPT Adds Structure

An internal sysadmin running this checklist occasionally is good practice, but a structured, independent VAPT engagement — combining this same enumeration methodology with manual verification and business-context risk prioritisation, delivered with a CERT-In empanelled partner where regulatory submission is required — catches drift between audits: the SUID bit added during a rushed deployment, the cron job scripted by a departed engineer, the sudoers line nobody remembers approving. Automated, continuous scanning closes the gap between point-in-time internal reviews and what an attacker actually finds on the day they try.

Platforms like Bachao.AI build this kind of host-level and application-level enumeration into an ongoing VAPT pipeline, so Indian SMB teams get privilege-escalation-grade visibility without needing a dedicated Linux security engineer running manual sudo and SUID audits every month. Dhisattva AI Pvt Ltd built the platform around the reality that most Indian SMBs run production Linux infrastructure without anyone formally responsible for auditing it.

Next Steps

Privilege escalation enumeration is a discipline, not a one-off checklist — misconfigurations reappear every time a new service is deployed, a script is edited, or a package is upgraded. Run this checklist on your own authorised infrastructure on a fixed schedule, and treat every SUID bit, sudoers line, and cron job as something that needs a documented reason to exist.

Want visibility into which Linux misconfigurations are actually exploitable in your environment? Get a free VAPT scan, or browse the Bachao.AI blog for more hands-on security methodology. If your infrastructure processes personal data under India's privacy law, also review our DPDP compliance guide.