Common Privilege‑Escalation Vulnerabilities in Penetration Testing

Privilege escalation bridges the gap between obtaining a low‑privilege foothold and fully controlling a target system. Most initial compromises yield ordinary user rights, so exploiting escalation flaws is essential for complete system takeover.

1. Privilege‑Escalation Basics

Escalation upgrades a low‑privilege account (e.g., Windows user, Linux www‑data, nobody) to the highest system authority (Windows Administrator/SYSTEM, Linux root) by abusing configuration errors, software bugs, or permission‑management oversights.

Escalation vulnerabilities are classified by trigger scenario: local privilege‑escalation (LPE) and remote privilege‑escalation (RPE). In practice, LPE dominates because many remote exploits (e.g., MS17‑010) are already patched, while LPE often stems from lingering misconfigurations.

2. Windows Privilege‑Escalation Techniques

2.1 Service Permission Misconfiguration

Most Windows LPE bugs (>60%) involve services whose executable paths are writable by "Everyone". An attacker replaces the service binary, causing the service to run the malicious file with SYSTEM rights.

Impact: Affects all Windows versions where the vulnerable service exists.

Exploitation Steps (authorized testing only):

List services and their executable paths: sc queryex type= service state= all | findstr "NAME PATH" (or use AccessChk).

Identify services where the path is writable by the current user.

Replace the executable with a malicious binary that adds an admin account.

Restart the service ( sc restart <em>ServiceName</em>) or wait for automatic restart.

After restart, the payload runs as SYSTEM, completing escalation.

Defence: Restrict write permissions on service binaries to Administrator/SYSTEM, run services under low‑privilege accounts, and lock down service paths.

2.2 Registry Key Hijacking

Critical startup keys (e.g., HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, RunOnce, Winlogon) are read by the system at boot or login. If a normal user can write to these keys, they can inject a malicious executable that runs with SYSTEM rights.

Impact: All Windows systems; more common on older, poorly hardened installations.

Exploitation Steps:

Query key permissions:

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /s

(or use regini).

If writable, add a malicious value:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v Test /t REG_SZ /d "C:\temp\priv.exe"

.

Reboot or wait for user login; the payload executes as SYSTEM.

Clean up the added value after escalation.

Defence: Limit write access on these keys to Administrator/SYSTEM, audit key changes, and disable unused startup entries.

2.3 Kernel Exploits

Two kernel‑level LPEs are highlighted:

CVE‑2021‑1732 (Win32k local escalation). Exploits a callback flaw to achieve arbitrary kernel write and gain SYSTEM.

CVE‑2025‑24076 (Windows 11 DLL hijacking in the "Mobile Devices" feature). Replaces CrossDevice.Streaming.Source.dll within %PROGRAMDATA%\CrossDevice, achieving SYSTEM in a 300 ms window.

Both require confirming the target lacks the relevant patch (e.g., KB5000802 for CVE‑2021‑1732) and then uploading a version‑matched exploit before triggering the vulnerable component.

Defence: Apply all security patches promptly, disable unnecessary features (e.g., Mobile Devices), and employ EDR to monitor abnormal DLL loads.

2.4 Generic DLL Hijacking

When an application loads a DLL without an absolute path, Windows searches the current directory, System32, then PATH directories. If a user‑writable directory appears earlier in the search order, a malicious DLL with the same name can be loaded with the application's privileges.

Exploitation Steps:

Identify high‑privilege software that loads DLLs without absolute paths.

Verify the search path (current directory or PATH) is writable by the user.

Place a malicious DLL matching the target name.

Restart the software (or wait for automatic restart) to trigger loading.

Defence: Developers should load DLLs using absolute paths, enforce digital signatures, and restrict write access to executable directories and PATH entries.

3. Linux Privilege‑Escalation Techniques

3.1 SUID/SGID Abuse

SUID/SGID files run with the owner’s privileges. Misconfigured binaries (e.g., find, cp, bash, /usr/bin/env) that are owned by root and have the SUID bit allow a normal user to execute commands as root.

Exploitation Steps:

List SUID files: find / -perm -u=s -type f 2>/dev/null.

Select a usable file (e.g., bash).

Execute a root shell: /bin/bash -p or find / -name test -exec /bin/bash \;.

Verify with whoami.

Optionally use automation tools like AutoSUID to speed up discovery.

Defence: Remove unnecessary SUID bits, restrict ownership to root, and audit SUID files regularly.

3.2 Sudo Misconfiguration

Improper /etc/sudoers entries (e.g., user ALL=(ALL) NOPASSWD: ALL or allowing execution of high‑risk commands) let a user obtain root without a password.

Exploitation Steps (Scenario 1 – password‑less sudo):

List allowed commands: sudo -l.

If /bin/bash is permitted without a password, run sudo /bin/bash.

Confirm root with whoami.

Scenario 2 demonstrates exploiting a vulnerable sudo version (CVE‑2025‑32463) via the --chroot option to load a malicious shared library.

Defence: Limit sudo rights to the minimum required, set the file mode to 440, and keep sudo updated (≥ 1.9.17p1).

3.3 Kernel Exploits – Dirty Pipe (CVE‑2022‑0847)

Dirty Pipe abuses an uninitialized flag in the pipe buffer, allowing arbitrary writes to read‑only files without privileged syscalls. By overwriting /etc/passwd, an attacker can add a root‑UID entry.

Exploitation Steps:

Check kernel version: uname -r (affected 5.8‑5.16.11, etc.).

Upload a compatible exploit binary.

Run the exploit; it injects a root user into /etc/passwd.

Switch to the new user with su user to obtain root.

Delete the temporary user and restore /etc/passwd.

Defence: Update kernels, restrict write access to /etc/passwd, and enable kernel audit for pipe‑related syscalls.

3.4 Cron Abuse

Misconfigured cron jobs that run as root but reference scripts writable by normal users enable privilege escalation.

Exploitation Steps:

List cron jobs: crontab -l and cat /etc/crontab.

Find a root‑owned job whose script is user‑writable.

Append a payload (e.g., echo "hack::0:0::/:/bin/bash" >> /etc/passwd) to the script.

Wait for the scheduled execution; the payload runs as root.

Clean the script after escalation.

Defence: Restrict script permissions to root only, use absolute paths in cron commands, and prune unnecessary cron entries.

3.5 Other Common LPEs

/etc/passwd writable: If the file is world‑writable (e.g., mode 666), a user can append a UID 0 entry and log in as root.

Docker escape: Containers run with --privileged or with host directories mounted allow the attacker to mount the host filesystem and modify /etc/passwd directly.

Defence: Secure file permissions, avoid privileged containers, and limit host directory mounts.

4. Core Defensive Strategies

Patch systems and software promptly to close known LPE bugs.

Enforce least‑privilege configurations for services, registries, DLL directories, SUID files, sudoers, and cron scripts.

Enable comprehensive audit logging for high‑risk actions (service changes, registry writes, sudo usage, file modifications).

Disable unnecessary services and features (e.g., Windows Mobile Devices, unused cron jobs).

Educate administrators on secure configuration practices and the dangers of weak passwords.

5. Conclusion

The surveyed privilege‑escalation flaws fall into two categories: configuration‑based (service permissions, sudo, cron, registry, DLL search paths) which are highly prevalent and low‑effort to exploit, and software/kernel bugs (Windows kernel CVEs, Linux Dirty Pipe, DLL hijacking) that require specific exploits but can be equally impactful. Proper hardening, timely patching, and vigilant auditing are essential to mitigate these risks.

Source: HACK之道