3.4 Privilege Escalation Concepts
Key Takeaways
- Vertical privilege escalation moves to higher rights (user to admin/root); horizontal escalation moves sideways to another user's resources at the same level
- Common conceptual vectors include misconfiguration, weak permissions, unpatched OS/kernel flaws, insecure service or library loading, credential reuse, and token abuse
- On Windows, DLL hijacking, unquoted service paths, and access-token impersonation are classic vectors; on Linux, misconfigured SUID binaries, weak sudo rules, and writable cron jobs are classic
- Tools like WinPEAS, LinPEAS, and PowerUp enumerate escalation paths, but CEH tests the vector category and its defense, not exploit code
- Least privilege, hardened configurations and ACLs, prompt patching, and credential isolation are the core defenses
From Foothold to Control
An initial foothold is usually low-privilege. Privilege escalation is how an attacker turns that limited access into administrative or root control so they can read protected data, install persistence, and pivot. The CEH wants you to classify escalation and name the defensive principle — not to write exploits.
Vertical vs. Horizontal
- Vertical privilege escalation (privilege elevation) gains higher privileges than the current account — a standard user becoming local administrator or root. This is the classic case the exam emphasizes.
- Horizontal privilege escalation stays at the same privilege level but accesses another peer's data or session — for example, one ordinary user reading another ordinary user's records by manipulating an identifier. No new rights are gained, but confidentiality is still broken.
Memory hook: vertical = climb up the privilege ladder; horizontal = walk into the room next door.
How Attackers Find a Path
Before escalating, an attacker enumerates the host for misconfigurations. CEH names automated enumeration helpers — WinPEAS and PowerUp on Windows, LinPEAS and LinEnum on Linux — that surface writable services, weak permissions, stored credentials, and missing patches. The defensive mirror is to assume attackers will find these and to remove the misconfigurations before they do.
Common Escalation Vector Categories (Conceptual)
The CEH groups escalation into recognizable categories rather than specific payloads. Several differ by operating system:
Windows-Centric Vectors
- DLL hijacking — also called DLL search-order or DLL preloading abuse: a privileged application loads a library by name, and the system resolves an attacker-supplied library from an earlier, writable path, so the attacker's code runs with the application's privileges. The root cause is a trust and configuration problem (untrusted search path); the fix is controlling load paths and directory permissions.
- Unquoted service paths — a service path with spaces and no quotes lets Windows try to execute an attacker-placed binary earlier in the path.
- Token / access-token abuse — impersonating a more-privileged security token already present on the host (e.g., SeImpersonate-style abuse) to act as a higher identity.
- Weak service permissions — a low user who can reconfigure a service running as SYSTEM.
Linux-Centric Vectors
- Misconfigured SUID/SGID binaries — a program that runs as its owner (often root); abusing a vulnerable SUID-root binary yields root.
- Weak sudo rules — overly broad
sudoentries (e.g., NOPASSWD on a binary that can spawn a shell). - Writable cron jobs / scripts — a root cron job pointing at an attacker-writable file.
Cross-Platform Vectors
- Unpatched OS / kernel flaws — a defect that crosses a privilege boundary; remediated by patching.
- Weak or stored credentials — readable secrets in scripts, config files, or memory; reused admin passwords across hosts enable escalation by reuse.
Categories at a Glance
| Vector Category | Root Cause | Core Defense |
|---|---|---|
| Misconfiguration / weak permissions | Excess rights granted | Least privilege, permission hardening |
| Unpatched OS / kernel flaw | Missing patch | Timely patch management |
| DLL hijacking / unquoted path | Untrusted search path | Control load paths, quote/secure service paths |
| SUID / sudo / cron misconfig (Linux) | Over-permissioned binary/job | Audit SUID, tighten sudoers, lock cron |
| Stored/reused credentials | Secrets exposed/reused | Secret management, unique admin creds |
| Token / context abuse | Privileged context reachable | Credential isolation, restrict privileges |
Defenses: Least Privilege First
Every escalation defense reduces to a few principles the exam loves:
- Principle of least privilege — accounts, services, and processes get only the minimum rights required, so a compromised low account stays low. This is the single most-tested escalation defense.
- Harden configurations and ACLs — remove excess permissions, restrict who can write to executable/library/service/task locations, quote service paths, audit SUID binaries, and run services as constrained accounts rather than SYSTEM or root.
- Patch promptly — OS and kernel privilege bugs are remediated by vendor patches; an aggressive patch cycle closes the kernel-flaw vector.
- Isolate and rotate credentials — protect credential stores, use unique local administrator passwords per host (e.g., a managed-password solution), and avoid embedding secrets in scripts. Unique local-admin passwords also break the credential-reuse path that pass-the-hash relies on.
- Restrict privileged tokens and rights — limit who holds impersonation and debug privileges; enable platform protections that isolate credentials in memory.
- Monitor for anomalous elevation — alert on unexpected administrator/root activity, new privileged-group membership, and unusual service or task changes.
Why This Matters in the Chain
Privilege escalation is the hinge of the whole system-hacking chain. Without it, an attacker is stuck as a limited user — they cannot read protected secrets, install a kernel-mode rootkit, or reliably clear security logs (which usually requires administrative rights). Deny escalation and you cap the blast radius of any single compromise, which is exactly why defense in depth pairs strong perimeter controls with rigorous internal least privilege.
Quick Reference: Vector to Defense
For the exam, be able to snap any escalation scenario onto its defense:
- World-writable directory in a service's load path → secure directory ACLs and least privilege.
- Unpatched kernel local-exploit → timely patch management.
- NOPASSWD sudo on a shell-spawning binary → tighten the sudoers policy.
- Plaintext admin password in a deployment script → secret management and credential rotation.
- Reused local-administrator password across hosts → unique per-host admin passwords (a managed-password solution).
Notice the pattern: almost every escalation fix is either remove excess privilege, patch the flaw, or protect the credential. When a CEH question presents an escalation technique and asks for the best mitigation, the answer is rarely a flashy product — it is the boring, durable control (least privilege, hardening, patching, credential isolation) that removes the underlying root cause. Detective controls that alert on anomalous elevation are the backstop for the cases prevention misses, completing the defense-in-depth answer the exam expects.
A standard user on a workstation manipulates a record identifier in a web request and views another standard user's account data. No additional system rights are obtained. Which type of privilege escalation is this?
On a Linux host, which misconfiguration is a classic local privilege-escalation vector to root?
Conceptually, what makes DLL hijacking possible, and what is the corresponding defense category?