Establish Linux state and choose an escalation candidate
Needs: A working command channel and accurate effective identity, group, mount and process context
Shell commands
Decisive output: current identity/groups, OS/kernel/architecture, network position, root-owned activity, mounts and exact sudo rules.
# Baseline
hostname; id; groups
uname -a; cat /etc/os-release; getconf LONG_BIT
pwd; umask; env
ip addr; ip route; ss -lntup; ss -lxnp
ps auxf
mount; findmnt; lsblk; df -hT
sudo -n -l 2>&1
sudo -l
# Baseline
getent passwd
awk -F: '$3 == 0 || $7 !~ /(nologin|false)$/ {print $1,$3,$4,$6,$7}' /etc/passwd
# Baseline
id; whoami; groups
hostname; pwd
ip addr; ip route
Verify → Record effective UID/groups, host/namespace and the exact candidate permission; re-check identity after every claimed escalation.
If it fails → Missing tools or permission-denied inventory is partial visibility. Use built-ins and inspect concrete application paths rather than claiming no escalation path exists. More detail ↓
Explanation & examples
Establish Linux state and choose an escalation candidate
- USE WHEN
- A new Linux foothold or an identity/privilege change
- STARTING ACCESS
- A verified Linux foothold with a known effective UID, groups and filesystem context
- RESULT
- An evidence-ranked escalation queue and a verified current privilege state
Recognize the clue
At a new shell collect effective IDs/groups, current mounts, root-owned activity and exact sudo rules before choosing a technique.
id
findmnt
ps auxww
sudo -l
uid=USER_ID(APP_USER) groups=APP_GROUP
(root) NOPASSWD: /usr/bin/find
root ... /bin/sh /OPT_PATH/backup.shMeans: The sudo rule and privileged backup consumer open different candidate families; neither should be replaced by an automatic kernel choice.
Confirm: For each candidate establish exact permitted operation/object, run-as identity and trigger.
- After validation
- A candidate's complete permission/consumer chain is validated: choose that specific method.
- Ruled out in this context
- A highlighted process belongs to the same low user: reject its assumed privilege gain.
- Still inconclusive
- Permission-denied inventory is incomplete visibility; use known application paths and supported built-ins.
Troubleshooting: Missing tools or permission-denied inventory is partial visibility. Use built-ins and inspect concrete application paths rather than claiming no escalation path exists.
Additional prerequisite checks
hostname
id
uname -a
cat /etc/os-release
findmnt
sudo -l
Decisive output: current identity/groups, OS/kernel/architecture, network position, root-owned activity, mounts and exact sudo rules.
Priority: credentials/sudo → root-consumed writable objects → SUID/capabilities → privileged groups/mounts/local services → PATH/libraries/wildcards → software/kernel.
After root, re-enumerate newly readable credentials, services, listeners, mounts and routes. Capture the exact command, decisive output and state transition required by the objective; keep target details and proof material private.
Why it works
Privileges belong to effective identity and execution context, not a username string. A container root UID can differ from host root; a new identity changes readable files and available controls.
Worked example · hypothetical
Observation: a shell runs as an application account. Test: collect identity, sudo rules and root-owned activity. Illustrative output: one permitted interpreter and a writable backup directory. Interpretation: validate those specific consumers before selecting a kernel exploit.
New identity, privilege, host or route? Re-enumerate → All topic tasks →